Connection Timed Out
Locked
 
|
I have a Teapot application running under Linux and nginx. From time to time, I get the following error: ConnectionTimedOut: Data receive timed out. Otherwise, the Teapot application works fine, even with this error message. Can anyone tell me what or where it's timing out, and how can I change the timeout value? Thanks. |
|
|
On Wed, 28 Aug 2019 at 03:12, Richard Kenneth Eng <[hidden email]> wrote:
I'm not familiar with Teapot, but a screen snapshot might help. Hopefully someone else has some ideas. cheers -ben |
|
|
I did a bit of research on the web and I discovered that nginx can be
unreliable due to default or inappropriate settings for certain timeout values. Currently, I'm testing a possible fix: set /keepalive_timeout/ to 90, rather than the default 65. So far, it seems to work, but I need further testing. Ben Coman wrote > On Wed, 28 Aug 2019 at 03:12, Richard Kenneth Eng < > horrido.hobbies@ > > > wrote: > >> I have a Teapot application running under Linux and nginx. From time to >> time, I get the following error: *ConnectionTimedOut: Data receive timed >> out.* >> >> Otherwise, the Teapot application works fine, even with this error >> message. >> >> Can anyone tell me what or where it's timing out, and how can I change >> the >> timeout value? >> > > I'm not familiar with Teapot, but a screen snapshot might help. > Hopefully someone else has some ideas. > > cheers -ben -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
|
|
This didn't fix the issue. It's not a matter of adjusting timeout values.
However, I believe I've resolved the matter, more or less. You see, I think the problem is with Gmail... My Teapot application is using ZdcSecureSMTPClient>>sendUsingGmailAccount:password:to:message:. For whatever reason, Gmail is taking to long to respond. In the main thread, timeout causes the network to report a timeout error to the web browser. It seems that the Pharo application cannot capture this. But if I fork a process to do the sendUsingGmailAccount function, Pharo does capture this...a debug window opens with the timeout error message. The debug window tells me that it's timing out on waiting for data on the socket. Fortunately, the debug window does not prevent the Pharo application from continuing normally. So I can live with this. The alternative is to NOT use Gmail as a SMTP relay and *manually* send emails to my recipients. However, this would be extremely tedious and error-prone. I'll play it by ear. If the timeouts and debug windows prove to be problematic, I can fall back on manual emailing. Such is life in the world of networking. horrido wrote > I did a bit of research on the web and I discovered that nginx can be > unreliable due to default or inappropriate settings for certain timeout > values. Currently, I'm testing a possible fix: set /keepalive_timeout/ to > 90, rather than the default 65. So far, it seems to work, but I need > further > testing. > > > > Ben Coman wrote >> On Wed, 28 Aug 2019 at 03:12, Richard Kenneth Eng < > >> horrido.hobbies@ > >> > >> wrote: >> >>> I have a Teapot application running under Linux and nginx. From time to >>> time, I get the following error: *ConnectionTimedOut: Data receive timed >>> out.* >>> >>> Otherwise, the Teapot application works fine, even with this error >>> message. >>> >>> Can anyone tell me what or where it's timing out, and how can I change >>> the >>> timeout value? >>> >> >> I'm not familiar with Teapot, but a screen snapshot might help. >> Hopefully someone else has some ideas. >> >> cheers -ben > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
|
Have you tried manually opening up the gmail account you are sending from in
the browser and looking for anything funny? I have had similar issues where the gmail was needing a security prompt/response. I wrote a service to send mails asynchronously (in case the gmail connection was down and generally to give a speedy UI response) using the ZdcSecureSMTPClient, which is working like a charm. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
Re: Connection Timed Out
|
|
> On 3 Sep 2019, at 00:54, Jeff Gray <[hidden email]> wrote: > > Have you tried manually opening up the gmail account you are sending from in > the browser and looking for anything funny? I have had similar issues where > the gmail was needing a security prompt/response. > I wrote a service to send mails asynchronously (in case the gmail connection > was down and generally to give a speedy UI response) using the > ZdcSecureSMTPClient, which is working like a charm. If possible, it would be interesting for the community to learn about this. Especially dealing with success/failure is important once you operate asynchronously. |
Re: Connection Timed Out
|
|
In reply to this post by horrido
> On 1 Sep 2019, at 23:06, horrido <[hidden email]> wrote: > > This didn't fix the issue. It's not a matter of adjusting timeout values. > > However, I believe I've resolved the matter, more or less. You see, I think > the problem is with Gmail... > > My Teapot application is using > ZdcSecureSMTPClient>>sendUsingGmailAccount:password:to:message:. For > whatever reason, Gmail is taking to long to respond. > > In the main thread, timeout causes the network to report a timeout error to > the web browser. It seems that the Pharo application cannot capture this. Of course you can deal with it, if you want to. An HTTP server handling a request should do so fairly quickly, else clients will become unhappy. The client might automatically give up and close the connection. Doing a (possibly) long running operation while handling a request is, like you noticed yourself, dangerous. A Zn HTTP Server (like the one used by Teapot) can operate in 2 modes: in debug mode and in production mode. In debug mode an unexpected error while handling a request will result in a debugger. In production mode, that same exception will result in an HTTP 500 Server error with the exception printString. Production mode is the default. > But if I fork a process to do the sendUsingGmailAccount function, Pharo does > capture this...a debug window opens with the timeout error message. The > debug window tells me that it's timing out on waiting for data on the > socket. > > Fortunately, the debug window does not prevent the Pharo application from > continuing normally. So I can live with this. > > The alternative is to NOT use Gmail as a SMTP relay and *manually* send > emails to my recipients. However, this would be extremely tedious and > error-prone. > > I'll play it by ear. If the timeouts and debug windows prove to be > problematic, I can fall back on manual emailing. Such is life in the world > of networking. > > > > horrido wrote >> I did a bit of research on the web and I discovered that nginx can be >> unreliable due to default or inappropriate settings for certain timeout >> values. Currently, I'm testing a possible fix: set /keepalive_timeout/ to >> 90, rather than the default 65. So far, it seems to work, but I need >> further >> testing. >> >> >> >> Ben Coman wrote >>> On Wed, 28 Aug 2019 at 03:12, Richard Kenneth Eng < >> >>> horrido.hobbies@ >> >>> > >>> wrote: >>> >>>> I have a Teapot application running under Linux and nginx. From time to >>>> time, I get the following error: *ConnectionTimedOut: Data receive timed >>>> out.* >>>> >>>> Otherwise, the Teapot application works fine, even with this error >>>> message. >>>> >>>> Can anyone tell me what or where it's timing out, and how can I change >>>> the >>>> timeout value? >>>> >>> >>> I'm not familiar with Teapot, but a screen snapshot might help. >>> Hopefully someone else has some ideas. >>> >>> cheers -ben >> >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > |
|
|
Since JRMPC opens for registration in three days, I can't afford to screw
around with the web server at this late date. Had I known about this issue earlier in the year (say, May or June), I could've dealt with it then. All I'm looking for is a workaround, a duct tape solution. Sven Van Caekenberghe-2 wrote >> On 1 Sep 2019, at 23:06, horrido < > horrido.hobbies@ > > wrote: >> >> This didn't fix the issue. It's not a matter of adjusting timeout values. >> >> However, I believe I've resolved the matter, more or less. You see, I >> think >> the problem is with Gmail... >> >> My Teapot application is using >> ZdcSecureSMTPClient>>sendUsingGmailAccount:password:to:message:. For >> whatever reason, Gmail is taking to long to respond. >> >> In the main thread, timeout causes the network to report a timeout error >> to >> the web browser. It seems that the Pharo application cannot capture this. > > Of course you can deal with it, if you want to. > > An HTTP server handling a request should do so fairly quickly, else > clients will become unhappy. The client might automatically give up and > close the connection. > > Doing a (possibly) long running operation while handling a request is, > like you noticed yourself, dangerous. > > A Zn HTTP Server (like the one used by Teapot) can operate in 2 modes: in > debug mode and in production mode. In debug mode an unexpected error while > handling a request will result in a debugger. In production mode, that > same exception will result in an HTTP 500 Server error with the exception > printString. Production mode is the default. > >> But if I fork a process to do the sendUsingGmailAccount function, Pharo >> does >> capture this...a debug window opens with the timeout error message. The >> debug window tells me that it's timing out on waiting for data on the >> socket. >> >> Fortunately, the debug window does not prevent the Pharo application from >> continuing normally. So I can live with this. >> >> The alternative is to NOT use Gmail as a SMTP relay and *manually* send >> emails to my recipients. However, this would be extremely tedious and >> error-prone. >> >> I'll play it by ear. If the timeouts and debug windows prove to be >> problematic, I can fall back on manual emailing. Such is life in the >> world >> of networking. >> >> >> >> horrido wrote >>> I did a bit of research on the web and I discovered that nginx can be >>> unreliable due to default or inappropriate settings for certain timeout >>> values. Currently, I'm testing a possible fix: set /keepalive_timeout/ >>> to >>> 90, rather than the default 65. So far, it seems to work, but I need >>> further >>> testing. >>> >>> >>> >>> Ben Coman wrote >>>> On Wed, 28 Aug 2019 at 03:12, Richard Kenneth Eng < >>> >>>> horrido.hobbies@ >>> >>>> > >>>> wrote: >>>> >>>>> I have a Teapot application running under Linux and nginx. From time >>>>> to >>>>> time, I get the following error: *ConnectionTimedOut: Data receive >>>>> timed >>>>> out.* >>>>> >>>>> Otherwise, the Teapot application works fine, even with this error >>>>> message. >>>>> >>>>> Can anyone tell me what or where it's timing out, and how can I change >>>>> the >>>>> timeout value? >>>>> >>>> >>>> I'm not familiar with Teapot, but a screen snapshot might help. >>>> Hopefully someone else has some ideas. >>>> >>>> cheers -ben >>> >>> >>> >>> >>> >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> >> >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >> -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
|
|
My code creates a mail message and adds it to a collection.
Then in a forked process I read the collection of messages one by one and attempt to send them. It uses a timer to wait and try again, stopping only when the message collection is empty. I can share my code (it's far from enterprise strength) but I have no idea whether it will help in your case. It doesn't do anything funky - it just uses the standard methods from ZdcSecureSMTPClient. The only time that fails for me is when there's something wrong with the account/credentials. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |