> On 1 Sep 2019, at 23:06, horrido <horrido.hobb...@gmail.com> 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
>
