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
