On Wed March 11 2009 6:47:21 am Cornel Masson wrote: > 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.
Hmm... OK. That would be a bug. Any chance of logging a JIRA and attaching a small test case? Is this a code generation problem? (aka: if wsdl method ends in Async, it generate wrong) Or a runtime issue? Both? > 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: Quick question: what XML Stax parser are you using? I HAVE heard of this type of issue with the earlier versions of Sun's stax parser. Never heard of it with woodstox though. > 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? Not that I'm aware of. I've done fairly massive multi-threaded tests in Suns performance labs on 32core niagra boxes and never saw anything like that before. Dan > 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 > ______________________________________________________________________ -- Daniel Kulp [email protected] http://www.dankulp.com/blog
