failing RSS DataSource import locks mailbox

[deepblue]

Hi all,

one of our users is complaining, that he can not access his mailbox "sometimes". It seems, that a dead RSS Feed he subscribed to, causes that problem (I am not 100% certain though). Logfile says:

2010-07-06 17:08:58,771 INFO  [ScheduledTask-3] [name=mail@domain.de;mid=475;ds=RSS-119213;] HttpMethodDirector - Retrying request
2010-07-06 17:12:07,777 INFO  [ScheduledTask-3] [name=mail@domain.de;mid=475;ds=RSS-119213;] HttpMethodDirector - I/O exception (java.net.ConnectException) caught when processing request: Connection timed out

and later:

2010-07-06 17:12:07,777 INFO  [ScheduledTask-3] [name=mail@domain.de;mid=475;ds=RSS-119213;] HttpMethodDirector - Retrying request
2010-07-06 17:15:16,853 INFO  [ScheduledTask-3] [name=mail@domain.de;mid=475;ds=RSS-119213;] datasource - Import completed for data source 'RSS-119213'
2010-07-06 17:15:16,853 WARN  [ScheduledTask-3] [name=mail@domain.de;mid=475;ds=RSS-119213;] datasource - Scheduled DataSource import failed.

The user can not access the mailbox through Zimbra Webinterface during the (unsuccessful) DataSource import. When I try to access the mailbox through zmmailbox I receive:

ERROR: remote.TIMEOUT (https://server:7071/service/admin/soap/) (cause: java.net.SocketTimeoutException Read timed out)

For now, I deleted the RSS feed. I will know by tomorrow, if that solved the problem. But I think this could cause severe Problems to many users and it is hard to debug...

Does someone else see these Problems on ZCS 6.0.7?

Regards
Thomas

[fyd]

Hi Thomas, I get the same symptoms with one of my mailbox servers, after long hours of scratching logs and digging deep I found "HttpMethodDirector - I/O exception" in mailbox logs.

I stumbled upon this thread, so if you found something out please get back to me. What is the relevance of HttpMethodDirector - I/O exception and how is it spiking the load, mailbox server to go gaga! Mailbox log is below

--------------
2010-10-18 12:15:44,060 INFO [btpool0-48427://xxx.xxx.xxx/service/soap/BatchRequest] [name=domain.com;mid=1016;ip=xxxx;ua=ZimbraWebClien t - FF3.0 (Mac)/6.0.7_GA_2473.RHEL5_64;] HttpMethodDirector - I/O exception (org.apache.commons.httpclient.NoHttpResponseExcep tion) caught when processing request: The server xxxx.xxxx.xxxx failed to respond
2010-10-18 12:15:44,060 INFO [btpool0-48427://xxxx.xxx.xx/service/soap/BatchRequest] [name=xxxxxx;mid=1016;ip=xxxx;ua=ZimbraWebClient - FF3.0 (Mac)/6.0.7_GA_2473.RHEL5_64;] HttpMethodDirector - Retrying request
2010-10-18 12:15:44,083 WARN [btpool0-48565://xxxx.xx.xxx/service/soap/BatchRequest] [name=xxxx.xx;mid=1006;ip=xxxxxxx;ua=ZimbraWebClien t - SAF3 (Mac)/6.0.7_GA_2473.RHEL5_64;] index - Unable to (com.zimbra.common.service.ServiceException: error while proxying request to target server: Timeout waiting for connection
---------------

'HttpMethodDirector - I/O exception (org.apache.commons.httpclient.NoHttpResponseExcep tion) caught when processing request: The server xxxx.xxxx.xxxx failed to respond'

This is why my server din respond. In between this whole thing is because my proxy server was unable to complete the request from its peer (request was disconnected from mailbox server)

[deepblue]

Originally Posted by fyd

'HttpMethodDirector - I/O exception (org.apache.commons.httpclient.NoHttpResponseExcep tion) caught when processing request: The server xxxx.xxxx.xxxx failed to respond'

This is why my server din respond. In between this whole thing is because my proxy server was unable to complete the request from its peer (request was disconnected from mailbox server)

Hmm. I did not see a complete "lock up" of the server. Just the user that subscribed to "dead" RSS feeds could not login during the failing import of the feed. The only workaround I found was to delete the RSS feed....

Regards
Thomas

[fyd]

one of our users is complaining, that he can not access his mailbox "sometimes"

The situation was similar, mailboxes were slow to respond, web client hung up.

Server wasn't locked up but mailbox for users were very slow due to load spiking. And just confirming here if the log entries are related.

And hey, thanks for writing.