The probem with this approach is that you leave the burden to the user
to maintain two different piece of codes.
One that will support synchronous invocations and another one that
will support asynchronous invocations.
Well, I'd argue this burden will be negligible compared to the complexity a user would face when writing an asynchronous code in the
first place.
Having a 2 liner code branch is not a big deal at all IMHO. A user would have to check for null anyway, right ? So this check will
fit naturally
Cheers, Sergey
On Fri, Nov 14, 2008 at 11:57 AM, Sergey Beryozkin
<[EMAIL PROTECTED]> wrote:
this may be an option but i'd rather prefer users sticking to this pattern
as suggested by Dan earlier on for transports like Corba or non-Servlet
3/not Jetty-aware HTTP ones :
WebServiceContext context;
public String greetMe(String arg) {
ContinuationSupport contSupport = (ContinuationSupport)
context.get(ContinuationSupport.class.getName());
if (contSupport == null) {
//continuations not supported, must wait
return jmsGreeter.greetMe(arg);
}
....
}
In other words if a transport is not 'natively' async or can not handle
suspended requests like Jetty/servlet3 aware HTTP transport can, then we
won't even provide any ContinuationSupport wrappers...
Cheers, Sergey
We may want the continuation support to work in both case. This is
the case in jetty, and we may want to mimic the same kind of behavior
in case some transports do not support continuations.
In such a case, the continuation simply blocks and waits for a call to
resume(), in which case, the thread is unlocked and the processing is
resumed.
On Thu, Nov 13, 2008 at 12:06 PM, Sergey Beryozkin
<[EMAIL PROTECTED]> wrote:
I've added a simple HTTPS test and with HTTPS we have no luck at the
moment,
CxfJettySslSocketConnector extends Jetty SslSocketConnector and calling
continuation.suspend(timeout) simply blocks the calling thread.
I've checked the archives and I believe at a time
SslSelectChannelConnector[1] was considered unstable so instead a
blocking
SslSocketConnector was picked up.
Any thoughts on what would it take to upgrade CxfJettySslSocketConnector
to
use SslSelectChannelConnector ?
Thanks, Segey
[1]
http://www.mortbay.org/jetty/jetty-6/apidocs/org/mortbay/jetty/security/SslSelectChannelConnector.html
Question : how will SMX CXF Binding Component interact with (Jetty)
continuations when dealing with CXF-originated invocations ? The
Continuation wrappers will be available through an internal CXF input
Message and through JAXWS WebServiceContext (or JAXRS one later on) -
will
CXF BC be able to get hold of such wrappers ? If yes then I guess we
have
no problems at all ?
Yes, I think so, get continuation from cxf message
(org.apache.cxf.message.Message) is fine for CxfBcConsumer.
super.
I've just copied the relevant code only to sandbox as I didn't manage to
create a branch :
https://svn.apache.org/repos/asf/cxf/sandbox/2.2.x-continuations
Some comments. You can see in :
1. The wrapper interfaces for ContinuationSupport and Continuation in
https://svn.apache.org/repos/asf/cxf/sandbox/2.2.x-continuations/api/src/main/java/org/apache/cxf/continuations
2. How PhaseInterceptorChain deals with suspended exceptions in
https://svn.apache.org/repos/asf/cxf/sandbox/2.2.x-continuations/api/src/main/java/org/apache/cxf/phase/PhaseInterceptorChain.java
3. How AbstractInvoker deals with suspended exceptions in
https://svn.apache.org/repos/asf/cxf/sandbox/2.2.x-continuations/rt/core/src/main/java/org/apache/cxf/service/invoker/AbstractInvoker.java
4. How ChainInitiatorObserver deals with resuming an invocation chain in
https://svn.apache.org/repos/asf/cxf/sandbox/2.2.x-continuations/rt/core/src/main/java/org/apache/cxf/transport/ChainInitiationObserver.java
5. Jetty-specific continuation wrappers in
https://svn.apache.org/repos/asf/cxf/sandbox/2.2.x-continuations/rt/transports/http-jetty/src/main/java/org/apache/cxf/transport/http_jetty/continuations
6. How JettyDestination deals with continuations :
https://svn.apache.org/repos/asf/cxf/sandbox/2.2.x-continuations/rt/transports/http-jetty/src/main/java/org/apache/cxf/transport/http_jetty/JettyHTTPDestination.java
7. System tests :
https://svn.apache.org/repos/asf/cxf/sandbox/2.2.x-continuations/systests/src/test/java/org/apache/cxf/systest/jaxws/continuations
See the server code on how the test code interacts with continuations
through wrappers :
https://svn.apache.org/repos/asf/cxf/sandbox/2.2.x-continuations/systests/src/test/java/org/apache/cxf/systest/jaxws/continuations/HelloImplWithWrapppedContinuation.java
and how it does so directly
https://svn.apache.org/repos/asf/cxf/sandbox/2.2.x-continuations/systests/src/test/java/org/apache/cxf/systest/jaxws/continuations/HelloImplWithContinuation.java
check
https://svn.apache.org/repos/asf/cxf/sandbox/2.2.x-continuations/systests/src/test/java/org/apache/cxf/systest/jaxws/continuations/jetty-engine.xml
on how a jetty engine on a specific port can be told to ignore
continuations which are supported by default if true is set or that
attribute is omitted (not used in the test though)
Ok - you can now see it it so shoot :-) Comments are welcome
Sergey
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
