Re: [Imaplib2-devel] imaplib2 might hang

[Piers L. <pi...@ja...>]

Hi,

Seems a reasonable supposition to me.

Have you tried testing it by setting a timeout using the optional timeout argument to IMAP4()? (The default is no timeout.)

Piers Lauder

On Thu, 28 Jul 2016 23:42:33 -0400, Chris Coleman wrote:
  > 
  > I totally agree with your idea of making timeouts shorter Nicolas.
  > 
  > There are many requests to the server, such as the example you give, the 
  > imap server should return with the welcome message without needing to 
  > process any data, essentially it's static text.  For this, it would seem 
  > reasonable to have the imaplib2 client timeout in 5-10 seconds max.
  > 
  > For other requests involving actual mail data, the timeout should be longer.
  > 
  > 
  > 
  > On 7/28/2016 11:21 PM, Nicolas Sebrecht wrote:
  > >    Hi Piers,
  > >
  > > I've done debug sessions to understand why offlineimap can hang. It
  > > appears one of our thread might hang waiting for imaplib2 which never
  > > returns a value.
  > >
  > > This happens when I reach the (undocumented) maximum number of
  > > connections to my IMAP server. I guess they limit connections based on
  > > the public IP or similar. It looks like IMAP servers "handle" this case
  > > in quite different ways.
  > >
  > > I believe that Gmail drops a previously existing connection.
  > >
  > > imap.laposte.net will hold the connection without ever returning a
  > > welcome message. This sucks hard but I wonder other servers have similar
  > > behaviour.
  > >
  > > Hence, imaplib2 is blocked at line 396 in __init__:
  > >
  > >    self.welcome = self._request_push(name='welcome', tag='continuation').get_response(...)
  > >
  > > I wonder if imaplib2 should not assume a response within the global
  > > threading.TIMEOUT_MAX range which is "very" long (considered infinite).
  > > I know that socket.setdefaulttimeout() can handle this, too. We
  > > currently allow the users to configure a value for this. However, both
  > > are expected large enough to avoid reaching the timeout while it should
  > > not.
  > >
  > > IOW, I think some very special cases at decisive steps might use a short
  > > timeout while waiting for a response. The above line 396 falls into this
  > > case. We know that the time required for a welcome message is definetly
  > > shorter than for downloading/fetching a mail. So, we might like to add a
  > > "max_timeout" argument to get_response() at line 191. By using short
  > > timeouts when applicable, we would avoid hangs or long waits.
  > >
  > >
  > > Also, I wonder that waiting for the welcome message might not be the
  > > only one case. Some IMAP servers might behave in a similar way for other
  > > limits: e.g. at authentication time to limit connections in a
  > > per-account basis.
  > >
  > > Thoughts?
  > >
  > 
  > --
  > Chris Coleman
  > Espace LLC
  > 860-576-9526
  > 
  > 
  > ------------------------------------------------------------------------------
  > _______________________________________________
  > Imaplib2-devel mailing list
  > Ima...@li...
  > https://lists.sourceforge.net/lists/listinfo/imaplib2-devel