[Tickets #12837] Re: Imap_Client: Leaking IMAP socket on error

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/12837
------------------------------------------------------------------------------
  Ticket             | 12837
  Updated By         | Michael Slusarz <slusarz at horde.org>
  Summary            | Imap_Client: Leaking IMAP socket on error
  Queue              | Horde Framework Packages
  Version            | Git master
  Type               | Bug
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


Michael Slusarz <slusarz at horde.org> (2013-11-18 15:50) wrote:

> I've just quickly hacked together the test script to check if it  
> really allocates a socket to the IMAP server when an exception is  
> thrown. listMailboxes() was added to do something on the socket.
> (I had to "reverse diagnose" the issue since I just saw the server  
> ran out of sockets.)
>
> It seems to me the PHP gc does not clean up the $imap object when  
> it's still inside the loop.

That's correct.  Why would it?  The $imap object is successfully  
created.  It's not until the listMailboxes call is run that the  
exception is thrown.  But all code/variables before that in the try  
block isn't backed-out.  Thus, $imap still exists after the  
listMailboxes call fails.

If you want to explicitly check whether the $imap object can actually  
connect to the server, you need to manually call $imap->login().

> I'm not sure how I can see what part of horde actually caused the  
> problem on a productive box, ActiveSync was not in use and still  
> something got stuck in an endless loop. We have an unlimited  
> maximum_execution_time and I now changed it to 43200 seconds. That  
> should be way enough.

That isn't desirable.  If something is not finishing in 30 seconds,  
then there is something wrong with the script.  Bumping the max  
execution time isn't going to help.

> I'll check the Kolab code if it properly reuses the Imap_Client  
> object, that's a good hint.

My guess is that this is the issue.  Or else, an Exception is not  
being handled correctly somewhere.

Within a self-contained piece of code - say the Kolab library - you  
only need a single IMAP object that can be shared between all code.