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