#491 Failure to reconnect to Exchange after switching networks

[Roel van de Kraats]

Outside my company network owa is unreachable, and DavMail (of course) fails to connect. But often when I switch to the company network DavMail still fails to connect. Restarting Thunderbird doesn't help. 'Slightly' changing the OWA URL setting in DavMail (to force a reconnect) doesn't help. Only restarting DavMail helps.

Mickael, I'll mail you a log file.

BR,
Roel

[Mjasnik]

Hi, this occurs to me as well. I hate restarting DavMail every time I connect to other network and come back to corporate network.
I have tried setting timeouts in DavMail and Thunderbird to noavail, it seems that once DavMail initiates connection to server it can't close it and it just hangs.
Please fix the issue.

[Roel van de Kraats]

It seems that since version 4.3.0 DavMail also becomes quite busy in this situation and the log file grows quite rapidly. Mickael, I'll mail you such a log file.

[Mickael Guessant]

Tor the record:
the infinite loop is a Lightning bug, see https://bugzilla.mozilla.org/show_bug.cgi?id=874654 for a fix

[Mjasnik]

Hi!

This is not just calendar, it's IMAP/LDAP as well. Just seconds ago, I went to corporate LAN from home and davmail was hung, it could not reconnect to corporate email.
I tried to gracefully exit using right click on icon and exit, but that didn't work, it seems that davmail is hung. I kill it, that was the only way. Restarting it helped, it started working.
Maybe there has to be some timeout set in somewhere in java code for these types of network changing, quick look at source code didn't gave me the idea where though...
If needed, I can send any logs (with emails/servers obfuscated), but to be it seems just a matter of timeout of some sort of connection.

I use Ubuntu 12.04, tried Oracle Java 6 and 7, TB 17.0.6, Lighting 1.9.1 (with your patch applied). Using standard settings, method: EWS. Tried limiting IMAP cached connections to 0, tried adding email hostname to /etc/hosts. All these didn't made a change.

regards
Mjasnik

[Mickael Guessant]

Ok, we have two issues:
- high CPU usage => infinite loop in Lightning
- failure to reconnect => need more info

Do you have -Dsun.net.inetaddr.ttl=60 in davmail launch script ?
=> this is needed to avoid DNS results cache

[Mjasnik]

Hi!

Thanks for quick answer.
Commandline from ps -ef:
java -Xmx512M -Dsun.net.inetaddr.ttl=60 -cp /usr/share/davmail/davmail.jar:/usr/share/java/swt.jar::/usr/share/davmail/lib/activation-1.1.1.jar:/usr/share/davmail/lib/commons-codec-1.3.jar:/usr/share/davmail/lib/commons-collections-3.1.jar:/usr/share/davmail/lib/commons-httpclient-3.1.jar:/usr/share/davmail/lib/commons-logging-1.0.4.jar:/usr/share/davmail/lib/htmlcleaner-2.2.jar:/usr/share/davmail/lib/jackrabbit-webdav-2.4.3.jar:/usr/share/davmail/lib/jcharset-1.3.jar:/usr/share/davmail/lib/jcifs-1.3.14.jar:/usr/share/davmail/lib/jdom-1.0.jar:/usr/share/davmail/lib/junit-3.8.1.jar:/usr/share/davmail/lib/log4j-1.2.16.jar:/usr/share/davmail/lib/mail-1.4.3.jar:/usr/share/davmail/lib/slf4j-api-1.3.1.jar:/usr/share/davmail/lib/slf4j-log4j12-1.3.1.jar:/usr/share/davmail/lib/stax2-api-3.1.1.jar:/usr/share/davmail/lib/stax-api-1.0.1.jar:/usr/share/davmail/lib/woodstox-core-asl-4.1.2.jar:/usr/share/davmail/lib/xercesImpl-2.8.1.jar davmail.DavGateway

regards
Mjasnik

[Mickael Guessant]

Looks good, can you please :
- start DavMail
- check message or access Caldav url in a browser
- switch off network
- check again => DavMail should switch to offline mode
- switch on network
- check again => DavMail should switch to online mode

Please send me the davmail.log file

[Mjasnik]

Hi!

I'll try that, but most likely that will work.
What I'll be doing addionally is this: connect to VPN (where email server is accessible) refresh my inbox, turn off VPN or connect to other VPN (email server disapears), refresh inbox again and wait some time, then swich on correct VPN and refresh inbox.
I think second test is what this bug is about and that hangs for sure.

regards
Mjasnik

[Mjasnik]

Hi!

I suppose You're not interested in successful cases.
I made some tests, and tbh I was not able to hang it on purpose :( I'll restart davmail and when it eventually hangs, I'll get log files and send them to you. Log files maybe contain information which I'm not able to make wildly public, can I send that to email to you? (which one?)

regards
Mjasnik

[Mickael Guessant]

Le 12/06/2013 21:29, Mjasnik a écrit :

I suppose You're not interested in successful cases.
=> Well, obviously those would not help much...

I made some tests, and tbh I was not able to hang it on purpose :(
I'll restart davmail and when it eventually hangs, I'll get log files
and send them to you. Log files maybe contain information which I'm
not able to make wildly public, can I send that to email to you?
(which one?)
=> I would need latest davmail.log, you should also check currently open
connections with netstat.

[Roel van de Kraats]

When I encountered this problem again with DavMail 4.3.2-2138, netstat showed that 3 connections were established, through my 2 network interfaces:

Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp6 0 0 192.168.116.151:44075 <server>:https ESTABLISHED 21728/java
tcp6 0 0 134.37.107.251:57410 <server>:https ESTABLISHED 21728/java
tcp6 0 0 134.37.107.251:36039 <server>:https ESTABLISHED 21728/java

But when I disable my network interfaces (first one, then the other), the connections stay in this state, whereas all other connections (from other applications) go to a FIN_WAIT1 or CLOSE_WAIT state.

The log files doesn't show any changes.

[Roel van de Kraats]

.. Then when I tried to close DavMail, it was hanging, and I had to kill it explicitly. See davmail.log.hanghup.

[Mickael Guessant]

Ok, could you please try to set SO timeout in DavGatewayHttpClientFacade:

    public static void createMultiThreadedHttpConnectionManager(HttpClient httpClient) {
        MultiThreadedHttpConnectionManager connectionManager = new MultiThreadedHttpConnectionManager();
        connectionManager.getParams().setDefaultMaxConnectionsPerHost(100);
        connectionManager.getParams().setConnectionTimeout(10000);
        connectionManager.getParams().setSoTimeout(60000);
        synchronized (LOCK) {
            httpConnectionManagerThread.addConnectionManager(connectionManager);
        }
        httpClient.setHttpConnectionManager(connectionManager);
    }

[Roel van de Kraats]

Thanks for the suggestion. I'm running this version now. But since this issue only occurs occasionally, I'm not sure when I can say that the issue has been fixed. But of course I'll check whether this SoTimeout gives any (unexpected) problems by itself.

[Mjasnik]

I'll apply the thing as well. If anything will show up, I'll report back.

P.S. Dunno what changed or is this even related but it seems at least that 4.3.3 is more stable at connection changes.

[Roel van de Kraats]

After testing with the SoTimeout change for 2 weeks, I haven't seen any connection problems any more (and no side effects as well), so I think the problem is fixed. Thanks again, Mickael!

[Mickael Guessant]

Fixed by setting SO timeout to two minutes in connection manager

[Mickael Guessant]

released in 4.3.4