On Dec 09, 2008 at 12:07, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Andrei Pelinescu-Onciul schrieb:
[crossposting since this is of general interest]
On Nov 12, 2008 at 00:30, Klaus Darilion klaus.mailinglists@pernau.at wrote:
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
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)?
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).
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