On 1/31/11 5:15 PM, Martin B. Smith wrote: > Hello all, > > We're seeing an issue during a network event where tcp connections > cached in IMAP proxy, after becoming no longer valid, simply hang for > the user. It looks like this is actually expected given the current > code... are other folks dealing with this when their IMAP server's > dispatched address fails over to another node? > > Does anyone have other solutions? I haven't caught it fast enough to > just bounce the proxy & clear it out.
I may not exactly understand what you're describing, so my advice may not be useful to you. It sounds like what you're saying is that any existing connections end up sitting in a blocking read() call on the server socket descriptor because due to the type of network event, the read never completes. If this is the case, it might be mildly helpful if you enable send_tcp_keepalives since in this case any read should eventually return an error when the keepalive packet fails to send. HTH, Dave ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ----- squirrelmail-imapproxy mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-imapproxy@lists.sourceforge.net List archives: http://news.gmane.org/gmane.mail.squirrelmail.imapproxy List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-imapproxy