Daniel, thanks for this very elaborative explanation! On Thu, Apr 22, 2010 at 4:33 PM, Daniel Kulp <[email protected]> wrote: > On Wednesday 21 April 2010 10:35:12 am Roman Levenstein wrote: >> > 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? > > Well, that would require updates and enhancements to the JAX-WS spec. :-)
Yes. This may be the case. But even if support for asynchrony would not be part of the standard (yet), having a "de facto" standard supported by major Java SOAP stacks would be a big advantage for developers and make their life easier. > More in a sec... > > >> 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? > > Well, when producing the JAX-WS spec, everything presented in the spec must be > "doable" using the standard technologies and normal deployment environments. > In the case of JAX-WS, the "normal" environment is to have the services > deployed in a war with some sort of Servlet frontend. (btw: the TCK runs by > deploying wars in tomcat) Thus, any requirements of the spec MUST be > implementable on that technology. This is a very interesting comment. I'm not part of the JSR standardization team and was not aware of this requirement. This explains a lot of limitations present in some specifications. > However, the Async stuff you describe is NOT implementable on a Servlet 2.x > container. When the servlet container calls the servlet, when the servlet > returns, it assumes it has completed and will flush the response (and close > the connection if no keep-alive). Thus, there is no way for the servlet > container to "wait" for a response via a Future object without consuming the > request thread. It's just not possible. That is one main reason it's not > addressed as part of the JAX-WS spec as it would not be implementable on > current technology. I see. > In glassfish, Metro doesn't use a servlet and can hook into the HTTP stack > furthur down and thus it works there. However, if you deploy the same Async > service as a war into tomcat, the async stuff would no longer work. This is sad, that the least capable of all modern app. servers should be taken as a common platform ;-( > Basically, for any async stuff to work, there HAS to be support from the > underlying transport for it to even be possible. With Servlet 2.x, there > isn't support for it. With servlet 3.x, there is some support. Maybe a > future version of the spec would add support now that Servlet 3.x is final. > I don't really know. I hope so. With all the movement towards AJAX, Comet, long-lived HTTP connections, ARP and recently WebSockets, it would be nice to have a spec that is more up-to-date. BTW, usage of servlets as a basis has different kinds of limitations: - The facts that it uses one thread per request approach means that it most likely does not scale to serve let's say 50000 or 100000 simultaneous requests, because Java just does not support that many threads. Of course, requests can be queued in this case. - If request processing takes longer, because all threads are occupied and wait for results of the IO (e.g. DB query or invocation of another external WS) , then no new requests can be processed, even though the CPU load is almost 0 and all threads are just waiting for IO results. This of course does not contribute to a great scalability. >> 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? > > See above. A spec must be implementable or it's a pretty useless spec. > >> 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? > > JMS? JMS is a good solution, no doubts. But this is not very Web friendly, so to say. First of all, it is a Java-only solution. Then it may problems with firewalls. And invoking it from Web 2.0 apps is not so easy and straight forward, AFAIK. The scalability of JMS is eventually also not so scalable, at least when used inside a JavaEE server. Standalone JMS-based apps probably have better performance. BTW, I experimented a bit recently with a few JMS implementations (usual OSS suspects). I got up-to 11000 requests per sec on a commodity hardware (4 GB RAM, Dual Core). This is of course a way better than what I get with JAX-WS on the same hardware: around 350 processed invocations/sec. But for our apps we need a much better performance. > Seriously, I think a semi-normal way of handling such stuff would involve > either using more of a polling method or callback where a client would start a > long running process and either pass a reference to receive a callback when > complete or get back some sort of process ID that it could then invoke another > "getResult(id)" method later to see if it's done and get the result. > > I guess it requires thinking of it more from a messaging standpoint instead of > a request/reply standpoint, even on the client side. In principle, I agree with you. I'd even say that for the systems that are completely under your control, this would be a right way to go. But it is important that clients should be aware of this architectural choice. Now, if you have only legacy clients supporing only the old fashioned WS invocations and written without callback or polling in mind? Or if those client are all third-party and you cannot force them to use this architectural pattern? In such cases, having a better scalability transparently on the server-side is almost the only solution. >> 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? > > Well, REST in Java would have much of the same problems. If it's implemented > via a servlet type thing, same issue. Likewise for ESB if only dealing with > HTTP. JMS is possibly the right solution or using a ESB along with JMS. If you are under JavaEE constraints, yes - you are right. But recently many frameworks based on NIO or AIO were developed (netty, etc). They can scale up to hundreds of thousands incoming requests. There are also new languages like Scala, Clojure, Groovy or frameworks like Kilim or JetLang. Almost all of them are not JavaEE based and even ditch it, avoiding many of JavaEE limitations (control over multi-threading, one thread per request model, etc), and yet they are using Java or JVM. Solutions developed using such languages and frameworks also need ways for using Web Services, be it SOAP or REST. And they do not limit SOAP stacks via artificial constraints like JavaEE (no explicit thread mgmt, etc) and may require improved support for scalability, asynchrony, light-weight threads and other alternatives like actors, etc. I'm a strong believer that some important and big JSRs (like JAX-WS, JAX-RS), or at least WS stacks should try to liberate themselves from the idea of being purely JavaEE based. The future may be somewhere else (see above). And it is probably better for WS stacks to be part of that future by means of supporting it, instead of just stating that they are non JavaEE and therefore not part of the standard. I think, this attitude may result in a situation, where many of those new technologies due to the lack of support would introduce their own solutions. Eventually these solutions would not be WS based at all, thus eliminating the overall need for WS as such or significantely reducing its popularity... Just my 2 cents ;-)
