Fix is now committed. Dan
On Thu June 18 2009 11:24:06 am Daniel Kulp wrote: > On Thu June 18 2009 2:35:01 am Hannes Schubert wrote: > > Hi Dan, > > > > thank you, the hint to JETTY-536 does explain it all. But from my > > perspective it does not make sense to keep the Continuation object after > > the > > > > service call succeeded. This is what Mario implemented in his workaround: > > >> do this to prevent usage of cpu resources for requests that are > > >> expired anyway. > > >> > > >> However I just saw that in the trunk there's a method isExpired on the > > >> Continuation, so I'll just use that. And I just set >the object to > > >> null as soon as I processed the request, so that doesn't hinder me. > > > > I tried to do similar things by checking isPending() and isResumed() in > > case of isNew() is false. However, by working on with that continuation > > object I got com.ctc.wstx.exc.WstxEOFException. So the only workaround I > > see is to invoke each service call in its own client thread, as long as I > > do not have the option to dismiss the (Jetty's) continuation object, e.g. > > by calling (CXFs) continuation reset method. > > That's because CXF internally is assuming the isNew is true for the > request, not connection, just like you did. I have a fix for that that > I'm running tests with now. > > I think the other workaround is to turn keep-alives off. I believe in > Jetty, it's on a per-connection basis so if the keep-alives are off, a new > connection is made and a new continuation is created. I could be wrong > though. :-) > > Dan > > > Best regards > > Hannes > > > > dkulp wrote: > > > On Wed June 17 2009 4:33:05 pm Daniel Kulp wrote: > > >> This looks to be a bug. Not sure yet if it's in Jetty or in the CXF > > >> wrapper. Still kind of digging. > > > > > > Just found http://jira.codehaus.org/browse/JETTY-536 > > > > > > Thus, "isNew()" behavior isn't quite what we expected. Thus, there > > > definitely are some bugs in CXF here. > > > > > > Dan > > > > > > -- > > > Daniel Kulp > > > [email protected] > > > http://www.dankulp.com/blog -- Daniel Kulp [email protected] http://www.dankulp.com/blog
