After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 324816 - Alarm Tray eats CPU
Alarm Tray eats CPU
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Calendar
2.6.x
Other Linux
: Normal normal
: ---
Assigned To: Chakravarthi
Evolution QA team
Depends on:
Blocks: 327508 327510
 
 
Reported: 2005-12-22 15:52 UTC by Ali Akcaagac
Modified: 2013-09-13 00:57 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Illustration (524.95 KB, image/png)
2005-12-22 15:53 UTC, Ali Akcaagac 		Details

Description Ali Akcaagac 2005-12-22 15:52:58 UTC 
Jo, look at this cool picture (attachment) and see how much bandwidth it consumes. I am happy that evolution-alarm takes so much care for my dates but I really don't intend buying a separate computer for it :)
Comment 1 Ali Akcaagac 2005-12-22 15:53:50 UTC 
Created attachment 56304 [details]
Illustration
Comment 2 Harish Krishnaswamy 2005-12-23 04:08:10 UTC 
evolution-alarm-notify strives to be in sync with gconf - too often and steals more than a fair share of CPU cycles. Confirming this.
Comment 3 William Lovaton 2005-12-23 18:15:53 UTC 
Yes, I'm seeing this too.

I'm running Fedora Rawhide (FC5) updated to 23 Dec 2005, using evolution-2.5.3-1 on a VMWare 5.5.1 setup.

evolution-alarm-notify works fine until I change something in the preferences, that's when it starts to consume 100% of the CPU along with gconfd-2, killing e-a-n solves the problem.

Harish, is this going to be fixed for the next release? or do you need more info?
Comment 4 Chakravarthi 2006-01-05 11:49:53 UTC 
will look into this asap
Comment 5 Chenthill P 2006-01-12 18:15:51 UTC 
chakravarthi has sent a patch to the list. Will review and commit it asap.
Comment 6 Chakravarthi 2006-01-16 10:23:21 UTC 
problem was due to cyclic call backs of gconf update calling esourcelist update and vice-versa. Committed the approved patch. Closing the bug as fixed.