No, not really, it's more of a discussion about a specific behavior. Concerning the bug itself: for now i'll be running on my dirty hack or with your fixed classes (that would be better ^_^_) and i'll be able to remove it with the next CXF release.
Concerning the behaviour. I still think that, even if could be done using suspend, the jax-rs 2.0 did not mean for a timeout-ed message to be re-suspended. I wonder if the "suspend" notion isn't specific to CXF's continuations. Servlet 3 's "AsyncContext" only knows of a "timeout", no suspend. So i'm not really sure it's possible to implement Continuation's "suspend" over Servlet 3 's AsyncContext. http://docs.oracle.com/javaee/6/api/javax/servlet/AsyncContext.html And while reading the jax-rs 2.0 concerning timeouts: (7.2.1 Timeouts and Callbacks) the example shows that the timeoutHandler is meant to "resume" with a timeout-specific-answer. So i'd guess that's what it's made for (so, i'd say no re-suspend). 2012/11/13 Sergey Beryozkin <[email protected]>: > 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 >>> > >
