Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <022301c935db$666254c0$e002050a@IONAGLOBAL.COM>
From: "Sergey Beryozkin" <sergey.beryozkin@progress.com>
To: <cxf-dev@incubator.apache.org>
Subject: Jetty Continuations in CXF
Date: Fri, 24 Oct 2008 14:21:15 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0220_01C935E3.C5FB2A30"

------=_NextPart_000_0220_01C935E3.C5FB2A30
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi

I'd like to continue the discussion on how to handle Jetty =
continuations[1] in CXF[2] here.

In short the requirement is for CXF to be able to handle the application =
code (ServiceMix JBI consumers served by ServiceMix CXF BindingComponent =
in this case) doing explicit continuations.

Ex. CXF receives a request on a Jetty thread, creates an exchange and =
sends it further along to the consumer. Consumer is about to do some =
work so it spawns some activity or checks for some event and then does =
continuation.suspend(). This results in a specific Runtime exception =
being thrown.=20

The challenge is how to 'suspend' the interception chain, let this =
exception propagate down to the Jetty stack so that it can free the =
thread and put this pending request in its internal queue, and then =
resume it when a consumer code decides to do continuation.resume().

See [3] for a more detailed description of the issues.

Dan, here're some comments :

1. "something would need to be done to allow the "suspend" exception =
thing to propogate up,=20
but without taking a jetty dependency into the core."

I guess the basic thing we can do is to check the class name of the =
exception (like exception.getClass().equals("JettyException")), and if =
it matches the expected name then we can wrap up this exception in a =
SuspendedFault exception, to be recognized by the rest of CXF runtime

2. Now, if the above can be figured out, the next problem arises: when=20
the "trigger" to wake up the continuation occurs

I think we can can do in JettyDestination omething similar to what is =
done in SMX. When getting a SuspendedFault exception, we can extract =
from it the original continuation instance or else we can do =
ContinuationSupport.getContinuation(request) which should return us the =
instance. At this point we can use it as a ket to store the current =
exchange plus all the other info we may need.

When the user/application code does continuation.resume(), the Jetty =
thread will come back and we will use the =
ContinuationSupport.getContinuation(request) to get us the active =
continuation and use it to extract the suspended exchange and proceed =
from there, say we'll call PhaseInterceptorPhase.resume(), etc, =
something along the lines you suggested

=20
3. Basically, to do this "right", we'd need to audit pretty much =
everything to=20
make sure nothing is stored on the stack and is "resumable". Once that =
is=20
done, the rest is relatively easy.=20

Yea - probably can be the quite challenging


Thoughts ?

Cheers, Sergey


[1] http://docs.codehaus.org/display/JETTY/Continuations
[2] https://issues.apache.org/jira/browse/CXF-1835
[3] =
https://issues.apache.org/jira/browse/CXF-1835?focusedCommentId=3D1264236=
1#action_12642361
------=_NextPart_000_0220_01C935E3.C5FB2A30--