Hi All,
CXF 3.3.3, Spring Boot 2.1.9, new mailing list user, first post...
org.apache.cxf.wsdl.interceptors.DocLiteralInInterceptor.validatePart(DocLiteralInInterceptor.java:281)
is throwing an exception while receiving an INBOUND message at my
endpoint. This only happens occasionally, and only when a JAX-WS
client is sending an OUTBOUND message on a different thread at the
same time.
The Endpoint and Client use the classes that are generated from the
same WSDL using cxf-codegen-plugin (we send the same messages in and
out, receiving and sending to multiple partners) and the client is set
up with client.setThreadLocalRequestContext(true).
A pattern is showing in the logs where whilst a Client is sending out
a message of type IdentifyRequest on one thread the endpoint receives
a message of type IdentifyResponse on a Tomcat handler thread and
fails because it expected a IdentifyRequest (this is an asynchronous
message pattern, hence the *Request/Response naming).
org.apache.cxf.interceptor.Fault: Unexpected element
{http://xyz}IdentifyResponse found. Expected
{http://xyz}IdentifyRequest
This is then immediately backed up by a NPE:
java.lang.NullPointerException: null
at
org.apache.cxf.interceptor.OutFaultChainInitiatorObserver.addToChain(OutFaultChainInitiatorObserver.java:60)
at
org.apache.cxf.interceptor.OutFaultChainInitiatorObserver.initializeInterceptors(OutFaultChainInitiatorObserver.java:55)
at
org.apache.cxf.interceptor.AbstractFaultChainInitiatorObserver.onMessage(AbstractFaultChainInitiatorObserver.java:108)
at
org.apache.cxf.phase.PhaseInterceptorChain.wrapExceptionAsFault(PhaseInterceptorChain.java:374)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:332)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:121)
at
org.apache.cxf.transport.http.AbstractHTTPDestination.invoke(AbstractHTTPDestination.java:267)
at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:234)
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:208)
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:160)
at
org.apache.cxf.transport.servlet.CXFNonSpringServlet.invoke(CXFNonSpringServlet.java:216)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:301)
at
org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:220)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:648)
I have traced back all the WS-Addressing headers and SOAP actions for
both operations, etc and they are correct.
So my only guess at this stage is that there is some sort of context
or class sharing going on internally with the CXF generated code
between the Endpoint and the Client. Is this possible? Even when the
client is set up with a thread-local context?
My endpoint is created like this:
@Bean
public Endpoint identifyEndpoint() {
Identify identifyPort = new IdentifyPortImpl();
EndpointImpl endpoint = new EndpointImpl(bus, identifyPort,
javax.xml.ws.soap.SOAPBinding.SOAP12HTTP_BINDING);
endpoint.setWsdlLocation("classpath:/IdentifyService.wsdl");
endpoint.setServiceName(IdentifyService.SERVICE);
endpoint.setEndpointName(IdentifyService.IdentifyPort);
endpoint.getFeatures().add(new LoggingFeature());
endpoint.getFeatures().add(new WSAddressingFeature());
endpoint.getProperties().put(Message.SCHEMA_VALIDATION_ENABLED, true);
endpoint.publish("/v1/identify");
return endpoint;
}
This didn't occur (as far as I know) until we upgraded from 3.1.10 to
3.3.3. Are there any other properties I should be setting?
NOTE: As usual, this is only happening in Production whilst under
load. As such I cannot simply upgrade to 3.3.5 and/or reproduce it in
test at this stage. I'm looking for a "configuration" change that I
could sneak through as a hotfix if it's a known issue.
Thanks,
Mark
