Hi Daniel, Thanks for your reply!
On Wed, Apr 21, 2010 at 3:33 PM, Daniel Kulp <[email protected]> wrote: > Sergey and I have chatted off and on about some of this, but never really had > time to put it to paper or start working on it. > > Currently, at the transport level, we support the continuations which, if the > transport supports it, allows the service to suspend the processing on the > request thread and pick it up later. Thus, for long running processes, the > servant can push it onto a workqueue or something and more or less suspend > things and resume later. It IS a bit complicated. :-( Also, not all > transport support it. Only JMS and HTTP if using the embedded Jetty. HTTPs > doesn't work (no continuation support for https with Jetty6, haven't checked > jetty 7 yet) and not the servlet version either. (new 3.0 servlet spec would > allow it. We haven't updated to the 3.0 version for our servlet yet). > > We've talked about adding a @UseAyncMethod(timeout = "###") annotation or > similar to let the runtime know to use the async method sigs instead of the > normal one and layer that on top of the continuations. That would simplify > things a lot. Just haven't gotten around to implementing it. That said, if > layered on the continuations, it would have the same transport restrictions. Thanks for the explanation. What bothers me a bit, is that you are very implementation centric (continuations, Servlets 3.0). But what about the asynchrony support in the JSR spec? What about compatibility with other JAX-WS implementations? > If you'd like to help out in this area, I'd be happy to provide pointers. :-) Well, I'm afraid I cannot spend any time on these issues. Basically, I'm the user of JAX-WS, not its implementor ;-) To be frank, I looked at the CXF JAX-WS implementation as a fallback solution. Many of our projects are based on Glassfish and therefore we used Metro. But after hitting certain limitations in Metro, when it comes to the server-side asynchrony (and also client-side asynchrony), I thought that may be another JAX-WS implementation can do it better. So, I started looking into CXF. But it turns out that the situation with CXF is not much better, if not worse in this regard ;-) Why I'm wondering about are two things: 1) Why there is no co-operation into bringing up server-side asynchrony issues at the JSR level? Or at least working on a cross-implementation interoperability or reuse of "user-space" code developed by JAX-WS users, when they want to use the server-side asynchrony support. It would be very nice, if the same code can be run on Metro, CXF, Axis and other JAX-WS implementations. Today we have to write JAX-WS implementation specific code. 2) Why asynchrony support is so low on the JAX-WS implementors agenda? I discovered massive problems in Metro and CXF when it comes to this topic (both client-side and server-side). Does it mean that there are other ways for achieving high-performance and scalable (e.g. able to support thousands of simultaneous requests) server-side WS processing? Or does it mean that there is not real interest in scaling WS processing that high? Were any JAX-WS frameworks used AT ALL for such kinds of scalable processing? If so, do you have any references and performance figures? Or are these frameworks good only for mostly low- or medium-load scenarios? Or may be I just expect too much from SOAP stacks and something else should be used instead for really high-performance scenarios, e.g. JMS, REST, ESBs (non SOAP based ;-) etc? Thanks in advance for any feedback!
