From: Russell Fulton <r.fulton@...>
Date: 2006-01-27T04:22:15+09:00
Subject: disconnect   net/imap -- need to talk with developer


Hi Folks,
         I guess my real question is "who looks after the IMAP module?". 
I've found what appears to be a bug.  I've been beating my head against 
this one all week and am finally getting a handle on what is going on 
after exploring several dead ends (you all know the senario ;)

The root of my woes are that imap::disconnect can (and frequenly does) 
hang leaving the thread locked up.

I have managed to mitigate this by adding timeout code to disconnect 
(see below).  This seems to solve the immediate problem but does not 
address the root cause.  I can now reproduce this fairly consistently 
and would be happy to work with the developers to fix this properly.

here is my modified disconnect:

    # Disconnects from the server.
    def disconnect
      @sock.shutdown unless @usessl
      if ! @receiver_thread.join( 10 ) then
	@receiver_thread.kill
      end
      @sock.close
    end

All I've done is add the timeout to the join call and the kill if it 
returns
nil (i.e. the join timed out).

One thing I have established is that this bug is *not* related to SSL, 
the same calls hang regardless of whether or not I'm using SSL.  I've 
checked the server logs and there is nothing unusual logged for the hung 
sessions.

In all cases where disconnect fails the following sequence happens:

     imap = Net::IMAP.new(host, usessl ? 993 : 143, usessl)
     imap.login( user, pass)
   rescue Net::IMAP::NoResponseError
     imap.disconnect

i.e. the login fails and then imap.disconnect *sometimes* hangs.
If I don't call disconnect then I bleed sockets (not surprisingly).

It would seem that some accounts hang consistently while others don't, 
very strange (but good from a debugging point of view).

BTW if anyone want to get in touch with me about this I suggest you 
email me at r.fulton@auckland.ac.nz as this is Friday here and we have a 
long weekend and I'll be away for three day.

Cheers, Russell




-- 
Posted via http://www.ruby-forum.com/.