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
