Bug 739319

Summary:	evolution-mapi calendar fails to reconnect after going offline (with OpenVPN)
Product:	[Fedora] Fedora	Reporter:	Derek Atkins <warlord>
Component:	evolution-mapi	Assignee:	Matthew Barnes <mbarnes>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	15	CC:	mbarnes, mcrha
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-09-19 09:03:34 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Derek Atkins 2011-09-17 15:52:17 UTC

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):

evolution-mapi-3.0.2-2.fc15.x86_64
evolution-data-server-devel-3.0.2-1.fc15.x86_64
evolution-exchange-3.0.2-1.fc15.x86_64
evolution-help-3.0.2-3.fc15.noarch
evolution-NetworkManager-3.0.2-3.fc15.x86_64
evolution-3.0.2-3.fc15.x86_64
evolution-data-server-3.0.2-1.fc15.x86_64

How reproducible:

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).

Actual results:

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.

Expected results:

The MAPI Calendar should re-connect to the MAPI server after going offline. Also, the e-calendar-factory should die when evolution quits.

Additional info:

Comment 1 Milan Crha 2011-09-19 09:03:34 UTC

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 ***

Comment 2 Derek Atkins 2011-09-19 13:34:49 UTC

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.

Comment 3 Milan Crha 2011-09-19 13:45:48 UTC

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.

Comment 4 Derek Atkins 2011-09-19 14:46:53 UTC

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.

Comment 5 Matthew Barnes 2011-09-19 14:57:27 UTC

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.