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

* Your Email Address
* Spam protection	Enter the letters below: .___.. .___. __ .__. \| \| _/ / `\| \| \| \|___./__.\__.\|__\|
Comment	>> 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.
Attachment
Watch this ticket

Saved Queries