WS Addressing asynchronous transport and NullPointerException with Apache
tomcat (threading problem ?)
-------------------------------------------------------------------------------------------------------
Key: CXF-2545
URL: https://issues.apache.org/jira/browse/CXF-2545
Project: CXF
Issue Type: Bug
Components: WS-* Components
Environment: System:
2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux
Java:
java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) 64-Bit Server VM (build 14.2-b01, mixed mode)
Apache CXF 2.2.3 (not in version list)
ServiceMix 3.3.1 with pachted CXF-BC component
Apache Tomcat 6.0.20 and 6.0.14
Reporter: Christian Connert
Hi,
I've the problem, that for one of my services the following
java.lang.NullPointerException occurs:
WARNUNG: Interceptor has thrown exception, unwinding now
java.lang.NullPointerException
at
org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:735)
at
org.apache.coyote.http11.InternalInputBuffer$InputStreamInputBuffer.doRead(InternalInputBuffer.java:781)
at
org.apache.coyote.http11.InternalInputBuffer.doRead(InternalInputBuffer.java:708)
at org.apache.coyote.Request.doRead(Request.java:428)
at
org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:304)
at org.apache.tomcat.util.buf.ByteChunk.substract(ByteChunk.java:405)
at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:327)
at
org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:162)
at com.ctc.wstx.io.UTF8Reader.loadMore(UTF8Reader.java:365)
at com.ctc.wstx.io.UTF8Reader.read(UTF8Reader.java:110)
at com.ctc.wstx.io.MergedReader.read(MergedReader.java:101)
at com.ctc.wstx.io.ReaderSource.readInto(ReaderSource.java:84)
at
com.ctc.wstx.io.BranchingReaderSource.readInto(BranchingReaderSource.java:57)
at com.ctc.wstx.sr.StreamScanner.loadMore(StreamScanner.java:992)
at
com.ctc.wstx.sr.BasicStreamReader.readTextSecondary(BasicStreamReader.java:4626)
at
com.ctc.wstx.sr.BasicStreamReader.readCoalescedText(BasicStreamReader.java:4124)
at
com.ctc.wstx.sr.BasicStreamReader.finishToken(BasicStreamReader.java:3699)
at
com.ctc.wstx.sr.BasicStreamReader.safeFinishToken(BasicStreamReader.java:3647)
at com.ctc.wstx.sr.BasicStreamReader.getText(BasicStreamReader.java:809)
at
org.apache.cxf.staxutils.DepthXMLStreamReader.getText(DepthXMLStreamReader.java:160)
at
org.apache.cxf.staxutils.StaxUtils.readDocElements(StaxUtils.java:818)
at org.apache.cxf.staxutils.StaxUtils.startElement(StaxUtils.java:767)
at
org.apache.cxf.staxutils.StaxUtils.readDocElements(StaxUtils.java:804)
at org.apache.cxf.staxutils.StaxUtils.startElement(StaxUtils.java:767)
at
org.apache.cxf.staxutils.StaxUtils.readDocElements(StaxUtils.java:804)
at org.apache.cxf.staxutils.StaxUtils.startElement(StaxUtils.java:767)
at
org.apache.cxf.staxutils.StaxUtils.readDocElements(StaxUtils.java:804)
at org.apache.cxf.staxutils.StaxUtils.startElement(StaxUtils.java:767)
at
org.apache.cxf.staxutils.StaxUtils.readDocElements(StaxUtils.java:804)
at
org.apache.servicemix.cxfbc.interceptors.JbiInWsdl1Interceptor.getBodyElement(JbiInWsdl1Interceptor.java:351)
at
org.apache.servicemix.cxfbc.interceptors.JbiInWsdl1Interceptor.handleMessage(JbiInWsdl1Interceptor.java:96)
at
org.apache.servicemix.cxfbc.interceptors.JbiInWsdl1Interceptor.handleMessage(JbiInWsdl1Interceptor.java:59)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:236)
at
org.apache.cxf.phase.PhaseInterceptorChain.resume(PhaseInterceptorChain.java:210)
at
org.apache.cxf.ws.addressing.ContextUtils$1.run(ContextUtils.java:414)
at
org.apache.cxf.workqueue.AutomaticWorkQueueImpl$2.run(AutomaticWorkQueueImpl.java:243)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)
It seems that Apache Tomcat recycles the InputStream of the request and thus
closes the underlying InputStream.
I tested it with Tomcat 6.0.20 and 6.0.14 and have the same problem.
The strange thing is that it only occurs with one of my services and even there
not constantly. Thus I'm not sure if it's a problem with CXF or with Tomcat 6.
Adding an extra interceptor (before the StaxInInterceptor), which copies the
data of the InputStream to a ByteArrayInputStream solves the problem.
Could it be, that if WS Addressing with async. transport is used that the
servlet container closes the resources before the InterceptorChain is resumed
(line 414 ContextUtils)?
Greetings
Christian
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
