[sldev] [ANN] certified http development

[Erik Anderson]

On 9/19/07, Ryan Williams <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...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070919/2d8c0de4/attachment.htm