[Seaside-dev] Initial Request Failure on Retry

[Julian Fitzell]

Abstractly—and I admit I haven't gone to look at the code—I don't see a
problem with having #reset on WAPathConsumer, since as you say it is
stream-like. But wouldn't it be simpler just to create a new request
context when you retry?

On Thu, Mar 14, 2013 at 6:12 PM, Ken Treis <ken at miriamtech.com> wrote:

> We have build something using the Seaside-Rest add-on, and everything
> works beautifully in GemStone until a transaction conflict triggers a retry
> -- at which point we get a 404 rather than the expected response.
>
> We tracked the issue down to the WAPathConsumer, which keeps track of the
> path (destructively) as the request is being resolved. Its state isn't
> being reset before the request is retried, so subsequent requests are
> effectively tried against a different path.
>
> We've fixed in our home-grown Zinc streaming adaptor by adding the
> following line just before we retry:
>
> > aRequestContext consumer initializeWith: aRequestContext request url
> path copy
>
>
> This is admittedly a dreadful encapsulation violation. Ideally, maybe we'd
> implement something like #reset on WARequestContext. There is some other
> internal state (like `handlers`) that should probably be reset too, though
> I think in practice the use of #ensure: in #push:during: empties out the
> handlers collection before handling is retried.
>
> Alternately, we could perhaps make WAPathConsumer non-destructive and
> implement #reset there. It already acts a bit like a stream, so a #reset
> method would not be too out of place there.
>
> Thoughts?
>
> --
> Ken Treis
> Miriam Technologies, Inc.
>
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20130315/d4c83b4f/attachment.htm