On Thu Mar 18 18:12:52 2010, NINE wrote:
Show quoted text> > I could see this leaving extra open connections on the IMAP
> > server until it realizes the client went away but maybe I'm missing
> > something?
>
> That's exactly what I was trying to say. The IMAP server had these
> open connections till they timed out. If you open a connection for
> every single action in the webmail app, these can stress any
> mail_max_userip_connections setting...
>
> Thanks for fixing :)
I finally had a chance to dig into this a little. It appears the
documentation has been wrong since perhaps 2.2.2 or earlier. There has
been no automatic LOGOUT on DESTROY for a very long time from what I can
tell. In rfc2683 section 3.1.2 (Severed connections) I see:
" ... The client should send a LOGOUT command ... there isn't universal
agreement here. Some contend that sending the LOGOUT and waiting for the
two responses (untagged BYE and tagged OK) is wasteful and unnecessary, and
that the client can simply close the socket. ..."
This current behavior avoids the potentially wasteful/unnecessary requests
and I believe the current behavior should not change for two reasons: 1)
implementation history (despite contradictory documentation) 2) efficiency.
Certainly the documentation should be corrected to match actual behavior
that has been around for a long time.
I did a brief test (one w/SSL, one without) and when a Mail::IMAPClient
object goes out of scope the connection is implicitly close() and that
close was seen by my test dovecot server immediately.
I am not sure of the details of your tests/use-case but I did peek at the
CiderWebmail code. Perhaps you are doing something different and thus
seeing different behavior? If you can provide evidence that you think
provides a convincing argument to change the current behavior I'm willing
to listen. Are you sure CiderWebmail isn't keeping that "stashed"
imapclient object around for a long time (e.g. until a session times out or
expires)?
I get the feeling that perhaps you're dealing with a CiderWebmail bug and
not a Mail::IMAPClient bug... but I didn't dig to deep so perhaps I'm off-
base here.
If you're looking for options/workarounds:
* make your own class using Mail::IMAPClient as a base class and provide
your own DESTROY method that does what you want
* call LOGOUT explicitly before destroying/undef-ing the object
* be sure no objects are getting cached / kept alive in your current code
If you feel that something more than a documentation fix is called for here
please speak up!
