On 13/11/12 14:25, Gege wrote:
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
AsyncResponse.setTimeout maps quite well to the underlying provider's
context.suspend(). As I said, AsyncResponse.setTimeout can be called
repeatedly from the application code (TimeoutHandler) until the data is
actually available. Also, the legacy Jetty Continuation provider manages
repeated suspends with no problems.
I've added JAXRSContinationsTest and JAXRSContinationsServlet3Test in
systests/jaxrs tests, they are supposed to run the same tests, but at
the moment a test involving multiple setTimeout/suspends is disabled for
JAXRSContinationsServlet3Test, I'll play more with this test a bit later.
I wonder, are we talking about the bug in Servlet3 context ?
Sergey
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
