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?<br>
<br><div class="gmail_quote">On Thu, Mar 14, 2013 at 6:12 PM, Ken Treis <span dir="ltr"><<a href="mailto:ken@miriamtech.com" target="_blank">ken@miriamtech.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
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.<br>
<br>
We've fixed in our home-grown Zinc streaming adaptor by adding the following line just before we retry:<br>
<br>
> aRequestContext consumer initializeWith: aRequestContext request url path copy<br>
<br>
<br>
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.<br>
<br>
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.<br>
<br>
Thoughts?<br>
<br>
--<br>
Ken Treis<br>
Miriam Technologies, Inc.<br>
<br>
_______________________________________________<br>
seaside-dev mailing list<br>
<a href="mailto:seaside-dev@lists.squeakfoundation.org">seaside-dev@lists.squeakfoundation.org</a><br>
<a href="http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev" target="_blank">http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev</a><br>
</blockquote></div><br>