Jerome, even though setCommitted(false) gets called, there still the usual processing of handle() in the entire restlet chain (the Finder, delegating to the UniformResource, etc.). Within these routines, the return values from various callbacks are handled. Stuff that happens there on the response can override work being done in another thread. The response is thread safe, but it's still not the intended result.
I don't have a test case right now, but it would be easy to produce: simply call setCommitted(false) in a ServerResource annotated @Get implementation, and immediately move processing to a thread, where commit() is eventually called. The worker handler thread would overlap with the work done in the regular Restlet handling thread and you would get weird statuses and response entities. The reason I suggest an exception (and I share Tim's unease with it) is that it's a way to stop the handling chain in the regular thread, so that only the new handler thread would have free reign on the response. But it doesn't have to be an exception. Another solution would be for ServerResource, UniformResource and Finder to be refactored specifically to handle the committed=false case. I worry, though, that future work or custom implementations would not handle the case properly. -Tal On Sun, Jul 11, 2010 at 9:00 PM, Jerome Louvel <jerome.lou...@noelios.com>wrote: > Hi Tal and Tim, > > > > There is a way to signal an asynchronous response on a per-call basis, > calling Response#setCommitted(false). > > > > Then, if you call Response#commit() before the initial request thread > reaches back the connector, this should work fine as well. I’m not sure yet > how it could get ‘corrupted’. Do you have a precise scenario? > > > > Note that the NIO version of the asynchronous internal connector has been > moved to version 2.1. This feature should indeed be considered as preview > feature for 2.0. > > > > Best regards, > Jerome Louvel > -- > Restlet ~ Founder and Technical Lead ~ http://www.restlet.org > Noelios Technologies ~ http://www.noelios.com > > > > > > > > > > > > *De :* tpeie...@gmail.com [mailto:tpeie...@gmail.com] *De la part de* Tim > Peierls > *Envoyé :* vendredi 18 juin 2010 13:51 > > *À :* discuss@restlet.tigris.org > *Objet :* Re: Status of Asynchronous Support > > > > I never saw a response to this, but it does seem like a problem. > > > > I don't love the idea of a special exception used purely to handle control > flow, but I can't think of anything better off-hand. > > > > --tim > > On Sat, May 22, 2010 at 8:05 PM, Tal Liron <tal.li...@threecrickets.com> > wrote: > > Hi Jerome, > > > > 2. There is a TaskService associated to your application that you could > > leverage. It separates threads usage from tasks to process (such as > > committing responses). > > I've tried this, but there is a concurrency problem with this pattern in > ServerResource -- > > If I set autoCommiting to false during a ServerResource.get() and put my > task on a separate thread pool, then my own task might try to update the > response at the same time as the upper parts of the call stack > (Finder.handle(), for example) also try to update the response according > to my return value from get(). Both threads might be doing it at the > same time, and the response ends up corrupted (no concurrency > exceptions, but it's mismatched status/entity, for example). > > What would be the correct way to defer a response from within a > ServerResource? > > My thought is that there should be a way to return from get() while > signaling to the rest of the call stack that I am handling the response. > A null won't work, because it internally signifies an unavailable > entity. Perhaps a new kind of ResourceException? > DefferedResponseResourceException? > > -Tal > > ------------------------------------------------------ > > http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2612147 > > > ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2632674
