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. Im 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/> http://www.restlet.org Noelios Technologies ~ <http://www.noelios.com/> http://www.noelios.com De : [email protected] [mailto:[email protected]] De la part de Tim Peierls Envoyé : vendredi 18 juin 2010 13:51 À : [email protected] 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 <[email protected]> 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 <http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2612 147> &dsMessageId=2612147 ------------------------------------------------------ http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2632021
