[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         | Thomas Jarosch <thomas.jarosch at intra2net.com>
  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             |
------------------------------------------------------------------------------


Thomas Jarosch <thomas.jarosch at intra2net.com> (2014-01-13 08:45) 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().

oh well, I thought the exception would be handled in the same
way a C++ exception would be handled. In that case the $imap
object would have been destroyed upon leaving the try/catch block.
Guess that was a wrong assumption ;)

>> 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.

doing large imports of 5.000+ events via CSV sometimes takes a few minutes
and I certainly ran into timeouts. The Kolab backend is a lot slower than
the SQL backend during first imports. I had to increase the max_input_time
and max_execution_time to work around this.

>> 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.

yep, exactly. I've seen you did some changes to the code
to improve the situation. I've not tested them yet, I'm still
in the process of upgrading to cyrus 2.4 (and thus having a CONDSTORE server).

Feel free to close this issue. Thanks!
Thomas