I didn't see that one ^_^ I agree with your disagreement :-) I have some ideas on how to do it properly then. I'll play with that later after work. I'll keep you updated if i find a solution.
2012/11/13 Sergey Beryozkin <[email protected]>: > On 13/11/12 15:59, Gege wrote: >> >> 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). >> > > According to > http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/container/TimeoutHandler.html, > > one of the things the handler may choose to do is: > > "extend the suspend period by setting a new suspend time-out" > > So I disagree with your conclusion > > > Sergey > >> >> >> 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 >>>>> >>> >>> > >
