Description of problem:
I use OpenVPN to access my work system. I use Evolution (and Evo-Mapi) to connect to my work email, calendar, and address book. When I start up Evo (after the VPN is up) everything works great until I restart the VPN (either because it timed out and died or I suspended and moved to a different location). After I bring up the VPN again and set Evo to online mode again I can still contact email but the calendar fails. This failure continues until I exit Evolution and manually kill the e-calendar-factory process and then restart Evo. If I restart Evo without manually killing the e-cal-factory then I will still not be able to connect to the MAPI calendar.
Version-Release number of selected component (if applicable):
It is mostly reproducible. Sometimes it does take me a day or two before I see it. Other times I can reproduce it almost immediately.
Steps to Reproduce:
1. Bring up VPN
2. Start Evo, switch screens around to make sure it connects to Calendar
3. Put Evo into Offline Mode
4. Stop VPN
5. Change to another IP Address
6. Restart VPN
7. Put Evo back into Online Mode
8. Try to create or edit a MAPI calendar entry
Note that in step #5 (changing IP address), I think the key is that you just need to wait long enough for the calendar TCP connection to time out, or do something that would force a TCP RST (like an IP Address change).
A crash in the evolution-data-server, and then a MAPI Error:
Failed to fetch changes from a server: OpenFolder: MAPI error MAPI_E_CALL_FAILED (0x80004005) occurred
At this point I cannot enter any new items in the MAPI calendar, nor can I edit any existing items. This state will continue until I quit evolution, manually kill the e-calendar-factory, and then restart evolution.
The MAPI Calendar should re-connect to the MAPI server after going offline. Also, the e-calendar-factory should die when evolution quits.
Thanks for a bug report. There is an opened upstream bug, which is created from bug #558651, thus I'm marking this as a duplicate of it.
With respect of:
> Also, the e-calendar-factory should die when evolution quits.
The calendar factory does quit, after 10 seconds delay if nothing is using it. If there left any connections to it, then it doesn't stop and is kept running.
*** This bug has been marked as a duplicate of bug 558651 ***
Okay, so how do I tell what's connected to it? It does not seem to be dying on its own after Evo exits, even if I wait 10-15 seconds before I retry.
I do not know except of some deeper debugging lower in the factory code. Similar situation can happen when evolution is closed, but it doesn't properly free all ECalClient-s it had opened. It's not only about evolution itself, basically any process which is using the calendar factory and is not disposing created ECalClient-s can make the factory feel it's in use. Other process which can have opened connections to the factory is the evolution-alarm-notify process.
I'm happy to try to help test for you, but the fact remains that the calendar factory doesn't die, even after I kill Evo. And evo-mapi calendar will not work until the calendar factory restarts. So this is still a major issue, IMHO, and possibly different than the "wont reconnect" issue.
The calendar factory probably doesn't terminate because the GNOME Shell calendar is using it. E-D-S services are not just there to serve Evolution.