Hi
I write this not as a flame, but as honest feedback, in the hope that
there are perhaps solutions to some of these problems...
We are replacing our core system with a solution that uses SOAP to talk
to a gSOAP server. We were recommended XFire (this was before CXF
existed), since it was supposed to be lean, mean and really fast, and
much easier to use than the mainstream Java SOAP offerings. I only had
to build a SOAP client - no server - and used the standard
Aegis/JAX-WS/JAXB setup.
Everything went fine through development and testing, until the first
day in production: suddenly there were spurious SOAP errors. We had to
roll back. Further investigation pointed to the XFire SOAP client not
being *thread-safe* (the Test Dept's tests did not have high enough
concurrency, hence the production embarassment). It looked like XFire
(or a sub-module) was garbling some SOAP request (see example below: it
looks like two threads are writing to the same output stream??):
<soap:Body xmmllnnss::nnss11==""uurrnn::sshhaazzaamm--ccoomm...
After much googling and fiddling I got no result, so I decided that the
best way forward was to replace XFire. Hoping that CXF would have fixed
all such problems, I ported to it. Hmm. Firstly, I couldn't generate the
Java classes because of a NullPointer in wsdl2java (seen posts on forum,
but unable to fix - XFire generated fine from same WSDL). I then tried
various manual options from the CXF docs, e.g. using a <jaxws:client>, a
more manual JaxWsProxy, etc., but a nasty 'feature' kept tripping me up:
if a method name ends in "Async", CXF assumes it is using *async* SOAP
semantics. Is this in the SOAP standard? It so happens that two of our
methods end in "Async", but require normal handling. I finally had to
side-step the abstractions and hand-craft something around the CXF
Client directly. Great: so far so good.
Now for the acid test: our new, aggressive mult-threaded test suite.
Boom! Same sort of problems as XFire. I made a list of the kind of
errors we're seeing under load (see end of message). As far as I'm aware
we don't see any of these errors in single-threaded tests. I estimated
that it would be easier to wrap CXF in a thread-safe facade, than to
replace it, so I implemented a pool of CXF Clients. That reduced the
error frequency, but didn't eliminate it. Up against the wall by this
stage, with Management looming, I implemented a *retry* mechanism, i.e.
if CXF throws a org.apache.cxf.binding.soap.SoapFault or
org.apache.cxf.interceptor.Fault, and the error looks like something
transient, wait a while and retry. With the pool of CXF clients, and 1
retry on SOAP error, all our requests now finally succeed.
So: what now? My workarounds are just that: workarounds to get a first
version running in production. I wouldn't want to leave it like that.
So, the question is:
1. Am I stupid or did I miss something fundamental about CXF (this is my
1st SOAP project, so I'm no SOAP expert), or...
2. Are there significant thread-safety issues in CXF?
Any comments are welcome :)
Thanks
Cornel
SOAP errors
--------------
org.apache.cxf.binding.soap.SoapFault: Validation constraint violation:
tag name or namespace mismatch in element <RetriveRecognitionAsyncRequest>
org.apache.cxf.binding.soap.SoapFault: Validation constraint violation:
tag name or namespace mismatch in element <soap:Body<soap:Envelope>)
org.apache.cxf.binding.soap.SoapFault: Method 'soap:Envelope' not
implemented: method name or namespace not recognized
org.apache.cxf.binding.soap.SoapFault: Method '' not implemented: method
name or namespace not recognized
org.apache.cxf.binding.soap.SoapFault: Error writing to XMLStreamWriter
java.lang.IllegalStateException: Already connected
org.apache.cxf.interceptor.Fault: Marshalling Error: Can't set streaming
mode: already connected
org.apache.cxf.interceptor.Fault: Response was of unexpected text/html
ContentType. Incoming portion of HTML stream: <html><body>...
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
