cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: My XFire/CXF saga
Date Wed, 11 Mar 2009 21:17:58 GMT
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
dkulp@apache.org
http://www.dankulp.com/blog

Mime
View raw message