There is a CXF property 'thread.local.request.context' that you can set to true when instantiating the client that will give each thread its own unique request context. This should eliminate your client side concurrency issues.
On Wed, Mar 11, 2009 at 10:47 AM, Cornel Masson <[email protected]> wrote: > 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 > ______________________________________________________________________ >
