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 > Dan > > On Wed June 17 2009 7:59:30 am Hannes Schubert wrote: > > Hi all, > > > > with several examples I observed that a jetty continuation is bound to > > the client thread, which initiated its instantiation, e.g: > > > > 1. client thread invokes serviceMethod() first time > > > > 2. service impl gets a new continuation instance with state > > new=true,pending=false,resumed=false > > ...something might happen inbetween, the reason why continuations are > > used... > > > > 3. anyhow the continuation's resume() method is called, and thereby the > > service impl is invoked a second time with same continuation instance and > > state new=false,pending=true,resumed=true > > > > 4. client thread get's the result > > > > 5. same client thread submits a second call to the same serviceMethod() > > > > 6. service impl gets the same continuation instance with state > > new=false,pending=false,resumed=false a second time > > > > I tried to handle this state same as if it would be new. Interesting > > thing is that second suspending succeeds, but after second resume a > > com.ctc.wstx.exc.WstxEOFException: "Unexpected EOF in prolog" is thrown. > > However, this does not happen, if step 5 is executed by another thread > > (see > > http://svn.apache.org/repos/asf/cxf/trunk/systests/src/test/java/org/apac > >he /cxf/systest/http_jetty/continuations/). In this case the service impl > > gets a new continuation and all is happy... > > > > So my questions are: what is the idea beyond it? After succeeded service > > submission the client should be forgotten by the server. Why does server > > keep that continuation? Is it a Jetty issue? Or did I forgot something? > > > > Any hints are appreciated! > > > > Best regards > > > > Hannes -- Daniel Kulp [email protected] http://www.dankulp.com/blog
