Closed Bug 457176 Opened 16 years ago Closed 16 years ago

Cacheing feature causes Lightning to hang and then leaves Google calendar extension unusable

Categories

(Calendar :: Provider: GData, defect)

Lightning 0.9
x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 455939

People

(Reporter: mozbugzilla, Unassigned)

Details

I enabled the experimental cacheing feature for one of my Google calendars and then restarted Thunderbird.  After the restart, Thunderbird hung completely.  It now does this whenever the Google calendar provider extension is enabled, rendering it completely unusable.  I can find no way of disabling the experimental cacheing feature, so now can't use the extension.  I can't use the GUI to do this, as Thunderbird hangs.

This was first enabled using the gdata-provider.xpi from http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/latest-mozilla1.8/linux-xpi/ about five days ago and the corresponding lightning nightly.  I've since upgraded to the 0.9 release of Lightning and have tried all the gdata-provider nightlies and the version from addons.mozilla.org (0.5).  Sadly none resolve this problem.
Do you have a really large calendar? If so, then the initial synchronization might take a while (also in case you haven't synced for a week). You could try waiting for a while (i.e start tb before lunch, then leave) so that all events are downloaded.

Otherwise, I'm sorry there is no easy way to disable the cache without starting the app. The "hard way" is to start any application that lets you read sqlite3 databases (sqlite_manager extension from a different profile), open the storage.sdb in the not working profile, go into the calendar_properties table and then find the right disabled preference. If you do not have any local calendars (i.e "On my computer") and are ok with re-adding all remote calendars, you could also just remove the storage.sdb from your profile (or maybe rename first).

What may work is to start thunderbird in offline mode (i.e with -offline commandline option). Then the app should read from the cache instead of from the network. Then you should have a shorter startup time and can maybe disable the cache.
My calendar does span several years, but it's relatively sparsely populated.  I haven't tried leaving it for more than a few minutes after starting Thunderbird so maybe this is the issue.  I guess the cacheing process should really be done in a separate thread.

Thanks for the tips.  I'll try leaving Thunderbird running tonight with the gdata-provider enabled and will report back after the weekend.
Unfortunately, the way javascript works we are quite limited with threads, but we are working on ways to improve the behavior.
Okay, I'm back in business now.  I did try leaving Thunderbird running but with little success.  It did eventually become responsive again, but behaved very strangely.  In the Calendar list pane, all my read-only WCAP calendars were displayed without labels.  I also could not click ANY button in a dialog box that would cause that dialog box to close - the button animated the click, but the dialog never closed.  This happened with the "are you sure you want to stop composing this message" dialog, the reminders dialog (dismiss all), an error dialog and also the Edit Calendar dialog (meaning I again couldn't disable cacheing).  None of these things occurred without the Google Calendar data provider (0.5) installed.

I then tried running Thunderbird in offline mode and disabled the cache that way.  This worked perfectly and my Thunderbird/Lightning setup is now back to normal, with Google Calendar data provider installed and with none of the above problems.

I hope this provides some useful data.  It's been a pain, but I still very much appreciate all the work that's been put into Lightning and the Google Calendar provider.  Thanks for all your hard work!
Found an existing bug, more to happen there (I hope ;-)
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.