11 Dec
2008
11 Dec
'08
11:34 p.m.
On Dec 09, 2008 at 12:07, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote:
Andrei Pelinescu-Onciul schrieb:
It will time out and then jump into the failure route (it doesn't jump
directly on async send failure, it will wait for the transaction timeout).
[crossposting since this is of general interest]
On Nov 12, 2008 at 00:30, Klaus Darilion <klaus.mailinglists(a)pernau.at>
wrote:
Hi Andrei!
I wonder what happen if the asynchronous sending fails (e.g. TCP
connection is lost). Will it jump to failure route (for requests)? Can this also be used for DNS lookups and TCP/TLS
connection setup?
Yes for DNS (see above) and in general for any route-level async
processing
involving tm (e.g. lookup some part of the message in a slow DB and
execute automatically another route when the DB responds).
It cannot be used for TCP/TLS, but it's not needed anyway. In ser TCP
connection setup and TCP send is already asynchronous, at least if
you have tcp_buf_write=yes in ser.cfg (I agree it's not a very well
chosen name :-)). TLS does not support it yet, so if you use TLS What happens if the sending of the response (e.g. 200
ok) fails? Will acc
module account the failed 200 ok?
No, not directly (it has to look for the ACK). On tcp in general is not
possible to say what packet made it to the other side when a connection
is suddenly closed, while still having data in the socket send buffers.
With the async send we could make it a little better and detect _some_
packets that we know for sure we did not send (and callback tm and
fallback or execute the failure route for them), but we cannot tell
anything about all the stuff in the socket send buffers (64k+).
I think this would help only for the async. connect part (where we don't
have any kernel buffering), but for already opened connection that close
due to an error it won't help much.
Andrei