Thread: [Hastymail-devel] Timeout on imap
Brought to you by:
sailfrog,
slushpupie
From: Thierry de M. <th...@if...> - 2012-11-26 14:25:34
|
Hi there, After getting a timeout on one mailbox, I did run some manual connection to the account and found out that Hastymail is always timing out when there is a server error. It looks to me like it doesn't handle the "* BYE" reply and still tries to get more data. Please see below the transaction. Regards, Thierry A003 FETCH 1:* FULL * 1 FETCH (FLAGS (\Seen) INTERNALDATE "24-Nov-2012 08:53:35 +0200" RFC822.SIZE 10060984) * BYE Internal error occurred. Refer to server log for more information. [2012-11-26 15:00:37] Connection closed by foreign host. _______________________________ Thierry de Montaudry Interface Holding (Pty) Ltd +27 (0)79 980 0752 +27 (0)11 628 9800 +33 (0)6 72 12 80 53 |
From: <ja...@ha...> - 2012-11-26 15:50:15
|
Thierry, You are correct. A quick inspection of the code tells me we are not looking for the untagged BYE response and are still reading from the wire looking for a tagged response completion. I will add a bug to the tracker and see what we can do. Thanks for the feedback, Jason Munro ja...@ha... On Mon, 26 Nov 2012 15:06:14 +0100 Thierry de Montaudry <th...@if...> wrote > Hi there, > > After getting a timeout on one mailbox, I did run some manual connection to > the account and found out that Hastymail is always timing out when there is a > server error. It looks to me like it doesn't handle the "* BYE" reply and > still tries to get more data. Please see below the transaction. > > Regards, > > Thierry > > > A003 FETCH 1:* FULL > * 1 FETCH (FLAGS (\Seen) INTERNALDATE "24-Nov-2012 08:53:35 +0200" > RFC822.SIZE 10060984) * BYE Internal error occurred. Refer to server log for > more information. [2012-11-26 15:00:37] Connection closed by foreign host. > > _______________________________ > Thierry de Montaudry > Interface Holding (Pty) Ltd > +27 (0)79 980 0752 > +27 (0)11 628 9800 > +33 (0)6 72 12 80 53 > > > > ----------------------------------------------------------------------------- > - Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > Hastymail-devel mailing list > Has...@li... > https://lists.sourceforge.net/lists/listinfo/hastymail-devel |
From: <ja...@ha...> - 2012-11-26 16:37:12
|
A test fix for this is in SVN rev 2120 and the simple diff below. If you can test this out and see if it helps with the situation that would be great. Otherwise I will try to force an untagged BYE response in Dovecot somehow :) Index: lib/imap_class.php =================================================================== --- lib/imap_class.php (revision 2119) +++ lib/imap_class.php (working copy) @@ -228,6 +228,9 @@ $chunked_result[$c] = $chunks; } } + if (substr(strtoupper($result[$n]), 0, 6) == '* BYE ') { + break; + } } while (substr($result[$n], 0, strlen('A'.$this->command_count)) != 'A'.$this->command_count); $this->responses[] = $result; if ($chunked) { Jason Munro ja...@ha... On Mon, 26 Nov 2012 15:06:14 +0100 Thierry de Montaudry <th...@if...> wrote > Hi there, > > After getting a timeout on one mailbox, I did run some manual connection to > the account and found out that Hastymail is always timing out when there is a > server error. It looks to me like it doesn't handle the "* BYE" reply and > still tries to get more data. Please see below the transaction. > > Regards, > > Thierry > > > A003 FETCH 1:* FULL > * 1 FETCH (FLAGS (\Seen) INTERNALDATE "24-Nov-2012 08:53:35 +0200" > RFC822.SIZE 10060984) * BYE Internal error occurred. Refer to server log for > more information. [2012-11-26 15:00:37] Connection closed by foreign host. > > _______________________________ > Thierry de Montaudry > Interface Holding (Pty) Ltd > +27 (0)79 980 0752 > +27 (0)11 628 9800 > +33 (0)6 72 12 80 53 > > > > ----------------------------------------------------------------------------- > - Monitor your physical, virtual and cloud infrastructure from a single > web console. Get in-depth insight into apps, servers, databases, vmware, > SAP, cloud infrastructure, etc. Download 30-day Free Trial. > Pricing starts from $795 for 25 servers or applications! > http://p.sf.net/sfu/zoho_dev2dev_nov > _______________________________________________ > Hastymail-devel mailing list > Has...@li... > https://lists.sourceforge.net/lists/listinfo/hastymail-devel |
From: Thierry de M. <th...@if...> - 2012-11-27 16:53:17
|
Hi Jason, With this code, it does leave the loop, but it must be trying to read again as the page is still timing out, and I get the following error: PHP Fatal error: Maximum execution time of 30 seconds exceeded in /var/www/html/hastymail2/lib/imap_class.php on line 181 It looks like the is_resource($this->handle) test doesn't detect when the socket is closed, which is normal, as a handle to a closed socket is still a resource. I tried to replace it with the following with success: if(feof($this->handle)) break; I presume the test should be replace all around: "if(!is_resource())" => "if(feof())" Regards, Thierry ________________________________ Thierry de Montaudry Interface Holding (Pty) Ltd +27 (0)79 980 0752 +27 (0)11 628 9800 +33 (0)6 72 12 80 53 On 26 Nov 2012, at 17:10, ja...@ha... wrote: > A test fix for this is in SVN rev 2120 and the simple diff below. If you can > test this out and see if it helps with the situation that would be great. > Otherwise I will try to force an untagged BYE response in Dovecot somehow :) > > Index: lib/imap_class.php > =================================================================== > --- lib/imap_class.php (revision 2119) > +++ lib/imap_class.php (working copy) > @@ -228,6 +228,9 @@ > $chunked_result[$c] = $chunks; > } > } > + if (substr(strtoupper($result[$n]), 0, 6) == '* BYE ') { > + break; > + } > } while (substr($result[$n], 0, strlen('A'.$this->command_count)) != > 'A'.$this->command_count); > $this->responses[] = $result; > if ($chunked) { > > > Jason Munro > ja...@ha... > > On Mon, 26 Nov 2012 15:06:14 +0100 Thierry de Montaudry <th...@if...> > wrote > >> Hi there, >> >> After getting a timeout on one mailbox, I did run some manual connection to >> the account and found out that Hastymail is always timing out when there is a >> server error. It looks to me like it doesn't handle the "* BYE" reply and >> still tries to get more data. Please see below the transaction. >> >> Regards, >> >> Thierry >> >> >> A003 FETCH 1:* FULL >> * 1 FETCH (FLAGS (\Seen) INTERNALDATE "24-Nov-2012 08:53:35 +0200" >> RFC822.SIZE 10060984) * BYE Internal error occurred. Refer to server log for >> more information. [2012-11-26 15:00:37] Connection closed by foreign host. >> >> _______________________________ >> Thierry de Montaudry >> Interface Holding (Pty) Ltd >> +27 (0)79 980 0752 >> +27 (0)11 628 9800 >> +33 (0)6 72 12 80 53 >> >> >> >> ----------------------------------------------------------------------------- >> - Monitor your physical, virtual and cloud infrastructure from a single >> web console. Get in-depth insight into apps, servers, databases, vmware, >> SAP, cloud infrastructure, etc. Download 30-day Free Trial. >> Pricing starts from $795 for 25 servers or applications! >> http://p.sf.net/sfu/zoho_dev2dev_nov >> _______________________________________________ >> Hastymail-devel mailing list >> Has...@li... >> https://lists.sourceforge.net/lists/listinfo/hastymail-devel > > |
From: <ja...@ha...> - 2012-11-27 18:20:59
|
On Tue, 27 Nov 2012 17:52:59 +0100 Thierry de Montaudry <th...@if...> wrote > Hi Jason, > > With this code, it does leave the loop, but it must be trying to read again > as the page is still timing out, and I get the following error: PHP Fatal > error: Maximum execution time of 30 seconds exceeded in > /var/www/html/hastymail2/lib/imap_class.php on line 181 > > It looks like the is_resource($this->handle) test doesn't detect when the > socket is closed, which is normal, as a handle to a closed socket is still a > resource. I tried to replace it with the following with success: > if(feof($this->handle)) break; Interesting. Great find! > I presume the test should be replace all around: "if(!is_resource())" => > "if(feof())" I replaced the is_resource calls in the get_response method as suggested and added another feof check in the fgets method of the IMAP class as well. The remaining is_resource() calls are checking the result of a connection attempt so I think they can be left alone. Updates are in rev 2123. Thanks for the feedback, Jason Munro ja...@ha... |
From: Thierry de M. <th...@if...> - 2012-11-28 09:45:46
|
Hi Jason, Tested and implemented patch 2123. Working fine, and solving the timeout problem (even though we usually don't get this server error). Thanks for sorting it out so fast. Regards, Thierry ________________________________ Thierry de Montaudry Interface Holding (Pty) Ltd +27 (0)79 980 0752 +27 (0)11 628 9800 +33 (0)6 72 12 80 53 On 26 Nov 2012, at 17:10, ja...@ha... wrote: > A test fix for this is in SVN rev 2120 and the simple diff below. If you can > test this out and see if it helps with the situation that would be great. > Otherwise I will try to force an untagged BYE response in Dovecot somehow :) > > Index: lib/imap_class.php > =================================================================== > --- lib/imap_class.php (revision 2119) > +++ lib/imap_class.php (working copy) > @@ -228,6 +228,9 @@ > $chunked_result[$c] = $chunks; > } > } > + if (substr(strtoupper($result[$n]), 0, 6) == '* BYE ') { > + break; > + } > } while (substr($result[$n], 0, strlen('A'.$this->command_count)) != > 'A'.$this->command_count); > $this->responses[] = $result; > if ($chunked) { > > > Jason Munro > ja...@ha... > > On Mon, 26 Nov 2012 15:06:14 +0100 Thierry de Montaudry <th...@if...> > wrote > >> Hi there, >> >> After getting a timeout on one mailbox, I did run some manual connection to >> the account and found out that Hastymail is always timing out when there is a >> server error. It looks to me like it doesn't handle the "* BYE" reply and >> still tries to get more data. Please see below the transaction. >> >> Regards, >> >> Thierry >> >> >> A003 FETCH 1:* FULL >> * 1 FETCH (FLAGS (\Seen) INTERNALDATE "24-Nov-2012 08:53:35 +0200" >> RFC822.SIZE 10060984) * BYE Internal error occurred. Refer to server log for >> more information. [2012-11-26 15:00:37] Connection closed by foreign host. >> >> _______________________________ >> Thierry de Montaudry >> Interface Holding (Pty) Ltd >> +27 (0)79 980 0752 >> +27 (0)11 628 9800 >> +33 (0)6 72 12 80 53 >> >> >> >> ----------------------------------------------------------------------------- >> - Monitor your physical, virtual and cloud infrastructure from a single >> web console. Get in-depth insight into apps, servers, databases, vmware, >> SAP, cloud infrastructure, etc. Download 30-day Free Trial. >> Pricing starts from $795 for 25 servers or applications! >> http://p.sf.net/sfu/zoho_dev2dev_nov >> _______________________________________________ >> Hastymail-devel mailing list >> Has...@li... >> https://lists.sourceforge.net/lists/listinfo/hastymail-devel > > |
From: Thierry de M. <th...@if...> - 2012-11-28 10:48:37
|
Hi Jason, After setting patch 2123 live, I got a lot of the following errors: PHP Warning: feof(): supplied argument is not a valid stream resource in /var/www/html/hastymail2/lib/imap_class.php on line 172 PHP Warning: feof(): supplied argument is not a valid stream resource in /var/www/html/hastymail2/lib/imap_class.php on line 182 I still have to investigate why this is happening, but meanwhile I fixed it with the code below. Regards, Thierry Index: lib/imap_class.php =================================================================== --- lib/imap_class.php (revision 74) +++ lib/imap_class.php (working copy) @@ -169,7 +169,7 @@ $n = -1; do { $n++; - if (feof($this->handle)) { + if (!is_resource($this->handle) || feof($this->handle)) { break; } $result[$n] = $this->fgets($line_length); @@ -179,7 +179,7 @@ break; } while(substr($result[$n], -2) != "\r\n" && substr($result[$n], -1) != "\n") { - if (feof($this->handle)) { + if (!is_resource($this->handle) || feof($this->handle)) { break; } $result[$n] .= $this->fgets($line_length); ________________________________ Thierry de Montaudry Interface Holding (Pty) Ltd +27 (0)79 980 0752 +27 (0)11 628 9800 +33 (0)6 72 12 80 53 On 28 Nov 2012, at 10:45, Thierry de Montaudry <th...@if...> wrote: > Hi Jason, > > Tested and implemented patch 2123. Working fine, and solving the timeout problem (even though we usually don't get this server error). > Thanks for sorting it out so fast. > > Regards, > > Thierry > > ________________________________ > Thierry de Montaudry > Interface Holding (Pty) Ltd > +27 (0)79 980 0752 > +27 (0)11 628 9800 > +33 (0)6 72 12 80 53 > > > On 26 Nov 2012, at 17:10, ja...@ha... wrote: > >> A test fix for this is in SVN rev 2120 and the simple diff below. If you can >> test this out and see if it helps with the situation that would be great. >> Otherwise I will try to force an untagged BYE response in Dovecot somehow :) >> >> Index: lib/imap_class.php >> =================================================================== >> --- lib/imap_class.php (revision 2119) >> +++ lib/imap_class.php (working copy) >> @@ -228,6 +228,9 @@ >> $chunked_result[$c] = $chunks; >> } >> } >> + if (substr(strtoupper($result[$n]), 0, 6) == '* BYE ') { >> + break; >> + } >> } while (substr($result[$n], 0, strlen('A'.$this->command_count)) != >> 'A'.$this->command_count); >> $this->responses[] = $result; >> if ($chunked) { >> >> >> Jason Munro >> ja...@ha... >> >> On Mon, 26 Nov 2012 15:06:14 +0100 Thierry de Montaudry <th...@if...> >> wrote >> >>> Hi there, >>> >>> After getting a timeout on one mailbox, I did run some manual connection to >>> the account and found out that Hastymail is always timing out when there is a >>> server error. It looks to me like it doesn't handle the "* BYE" reply and >>> still tries to get more data. Please see below the transaction. >>> >>> Regards, >>> >>> Thierry >>> >>> >>> A003 FETCH 1:* FULL >>> * 1 FETCH (FLAGS (\Seen) INTERNALDATE "24-Nov-2012 08:53:35 +0200" >>> RFC822.SIZE 10060984) * BYE Internal error occurred. Refer to server log for >>> more information. [2012-11-26 15:00:37] Connection closed by foreign host. >>> >>> _______________________________ >>> Thierry de Montaudry >>> Interface Holding (Pty) Ltd >>> +27 (0)79 980 0752 >>> +27 (0)11 628 9800 >>> +33 (0)6 72 12 80 53 >>> >>> >>> >>> ----------------------------------------------------------------------------- >>> - Monitor your physical, virtual and cloud infrastructure from a single >>> web console. Get in-depth insight into apps, servers, databases, vmware, >>> SAP, cloud infrastructure, etc. Download 30-day Free Trial. >>> Pricing starts from $795 for 25 servers or applications! >>> http://p.sf.net/sfu/zoho_dev2dev_nov >>> _______________________________________________ >>> Hastymail-devel mailing list >>> Has...@li... >>> https://lists.sourceforge.net/lists/listinfo/hastymail-devel >> >> > > > ------------------------------------------------------------------------------ > Keep yourself connected to Go Parallel: > INSIGHTS What's next for parallel hardware, programming and related areas? > Interviews and blogs by thought leaders keep you ahead of the curve. > http://goparallel.sourceforge.net > _______________________________________________ > Hastymail-devel mailing list > Has...@li... > https://lists.sourceforge.net/lists/listinfo/hastymail-devel |
From: <ja...@ha...> - 2012-11-28 14:59:17
|
On Wed, 28 Nov 2012 11:48:20 +0100 Thierry de Montaudry <th...@if...> wrote > Hi Jason, > > After setting patch 2123 live, I got a lot of the following errors: > PHP Warning: feof(): supplied argument is not a valid stream resource in > /var/www/html/hastymail2/lib/imap_class.php on line 172 PHP Warning: feof(): > supplied argument is not a valid stream resource in > /var/www/html/hastymail2/lib/imap_class.php on line 182 > > I still have to investigate why this is happening, but meanwhile I fixed it > with the code below. The changes are added to rev 2125. Thanks! Jason Munro ja...@ha... |