When tou say to handle multiple setTimeout, do you mean: to suspend again the message again after it timeout-ed first ?
I tried updating the timeout value while the thread is still suspended (and not timeout-ed) and it worked. However i quickly gave up on trying to suspend it again because i didn't need such feature. And it seemed "logical", because it is a setTimeout, not a suspend() method. I "feel" that if jax-rs did not give and explicit suspend() method, maybe it's because the life-cycle of the AsyncResponse is simple : created -> suspended (default timeout) [-> update timeout value]* -> resume or created -> suspended (default timeout) [-> update timeout value]* -> timeout -> resume with timeout-content 2012/11/13 Sergey Beryozkin <[email protected]>: > On 12/11/12 18:10, Gege wrote: >> >> I think that in the context of Continuation the "resume-suspend" is >> normal because the continuation method is "suspend(long duration)" >> (=pause). >> >> However the AsyncResponse's method is setTimeout. I understand >> "setTimeout to xx seconds" differently than "pause for xx seconds". >> >> In the first case it's like a xxs pause, so i can understand wanting >> to resume the thread in order to pause it for another additional xx >> seconds. >> >> However in the case of setting a property name "timeout", i do not >> think you should "add" additinal time. Just set the timeout property >> and let the container chose if it was reached or not. I'm comforted in >> this thinking when i see that the timeout in tomcat (and even more in >> jboss) suffers from great imprecision (1s to 10s steps). >> >> I really think that this is a timeout, and not a "pause". The same way >> that once the container timeout-ed a session, you cannot get it back. >> However I didn't read any specs ... it's just the way i "feel" it : >> Continuation and AsyncResponse have the same goal, but are not exactly >> the same ;-) >> > > Thanks for the feedback so far. I've got rid of doing resume() to manage > AsyncResponse.setTimeout() and updated the test which depends on > Servlet3ContinuationProvider to test the default timeout scenario (as per > JAX-RS AsyncResponse rules) - it works OK: > > http://svn.apache.org/viewvc?rev=1408730&view=rev > > >> When testing, did you add some of my fixes like the TimeoutException's >> dirty hack ? If you didn't, i cannot understand how you can get >> timeout events ? > > > This look a hack all right :-). I do not need to use because when the thread > comes in and no AsyncResponse available on the exchange then I know it is > the initial request. Whenever it returns again it is always a timeout unless > it has been resumed by the application. > > The problem which does persist is that Servlet3ContinuationProvider does not > seem to be able to handle multiple AsyncResponse.setTimeout() events, not > sure why at the moment > > Sergey >
