[sldev] [ANN] certified http development

[Ryan Williams]

Erik Anderson wrote:
>
>
> On 9/19/07, *Ryan Williams* <rdw at lindenlab.com 
> <mailto:rdw at lindenlab.com>> wrote:
>
>     > I think the simplest possible solution is just to have the HTTP
>     server
>     > write requests as it reads them to a logfile along with the
>     responses
>     > after they are written. (It probably couldn't store the body,
>     because
>     > that could be of arbitrary size.) If the server crashes, it will
>     read
>     > in the logfile, build the appropriate "I've already done that"
>     > structures based on what it sees, and then delete the logfile,
>     > creating a new one to record all the traffic it successfully
>     handles.
>     > But I haven't been the one who has been thinking through the
>     > implementation details, so this might not work.
>
>
>     I think this is necessary but not sufficient.  I dunno if this is
>     "feature creep", but if you want to perform non-idempotent
>     operations to
>     generate a response, you want said operations to not be run multiple
>     times even in the case where you've only done half of them and haven't
>     written the response to the log before you crash.  Not having this
>     guarantee basically means that the exactly-once messaging guarantee is
>     worthless, because you can call the handler function an arbitrary
>     number
>     of times in the worst case, and that's not really distinguishable
>     from
>     receiving the message multiple times.
>
>
> If you're gonna be using a transaction log to handle your requests, 
> you need to make sure that it's written out and flushed to disk before 
> sending the response, not afterwards.  I know that the local DHCP 
> server I have on my linux box here uses this kind of approach, so this 
> type of solution is not unheard of (every so often it copies out all 
> active entries into a new log file).  Transaction log management does 
> start sounding like something that a database excels at though...
Exactly.  :-)

-RYaN