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(). > > 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 >
Attachment
Watch this ticket

Saved Queries