Non-idempotent retry in ne_begin_request()
Joe Orton
joe at manyfish.co.uk
Mon Jan 4 18:04:41 EST 2010
On Mon, Jan 04, 2010 at 01:57:00PM +0100, Thomas F wrote:
> Hi Joe,
>
> hmm, I'm not convinced yet, see below :-)
>
> Joe Orton schrieb:
> > send_request() knows to only return NE_RETRY if it is using a persistent
> > connection - see the "retry" variable.
> > The logic here ensures that a
> > persistent connection is closed for a non-idempotent request; so
> > send_request() should never return NE_RETRY there.
>
> It won't return NE_RETRY due to timeout (the close-on-non-idempotent-req
> logic prevents that), but it still can NE_RETRY due to server failure,
> which means non-idempotent requests may be silently retried.
Can you spell out exactly where you think NE_RETRY is going to be
returned on server failure for a non-idempotent request on a persistent
connection? For that case:
ne_begin_request():
-> closes the connection for a non-idempotent request on a persistent
connection, before calling send_request()
-> then calls send_request()
send_request():
-> calls open_connection(), which opens a new socket, and clears
sess->persisted
-> "retry" variable set to value of sess->persisted, i.e. zero
-> the RETRY_RET() macro is passed "retry", i.e. zero, so will never
evaluate to NE_RETRY
-> the only places where send_request() or functions it calls should
return NE_RETRY should be wrapped by RETRY_RET
-> ergo, there should be no case where send_request() returns NE_RETRY
Am I missing something?
Regards, Joe
More information about the neon
mailing list