Hi all,
We currently have come across a problem in CXF 2.2.2 that I suspect is a
bug.
Over the last week we detected continuous CPU usage on our production
instances. Upon investigating the Thread dumps, we found 3 processor
threads stuck in a continuous loop, with one specifically that started
processing on the 26th of February and is still waiting for data from the
client, though I suspect the client endpoint is long gone.
All these threads are ones which are processing incoming multipart
requests, likely ones which are badly constructed thus causing CXF to
enter into these continuous loops. However I would have assumed that CXF
would have detected a dead client within a week and ceased waiting for
input from the user J
A sample stack trace can be seen below. I have highlighted in bold the
area of the stacktrace that is consistent across all of the processor
threads.
at java.lang.System.arraycopy(Native Method)
at
java.io.PushbackInputStream.read(PushbackInputStream.java:163)
at
org.apache.cxf.attachment.MimeBodyPartInputStream.read(MimeBodyPartInputSt
ream.java:74)
at java.io.InputStream.read(InputStream.java:85)
at
org.apache.cxf.attachment.DelegatingInputStream.read(DelegatingInputStream
.java:77)
at org.apache.cxf.helpers.IOUtils.copy(IOUtils.java:112)
at org.apache.cxf.helpers.IOUtils.copy(IOUtils.java:75)
at
org.apache.cxf.attachment.AttachmentDataSource.<init>(AttachmentDataSource
.java:39)
at
org.apache.cxf.attachment.AttachmentUtil.createAttachment(AttachmentUtil.j
ava:168)
at
org.apache.cxf.jaxrs.ext.MessageContextImpl.createAttachments(MessageConte
xtImpl.java:135)
at
org.apache.cxf.jaxrs.ext.MessageContextImpl.get(MessageContextImpl.java:58
)
at
org.apache.cxf.jaxrs.impl.tl.ThreadLocalMessageContext.get(ThreadLocalMess
ageContext.java:38)
at
org.apache.cxf.jaxrs.utils.multipart.AttachmentUtils.getMultipartBody(Atta
chmentUtils.java:81)
at
org.apache.cxf.jaxrs.utils.multipart.AttachmentUtils.getAttachments(Attach
mentUtils.java:86)
at
org.apache.cxf.jaxrs.provider.MultipartProvider.readFrom(MultipartProvider
.java:76)
at
org.apache.cxf.jaxrs.utils.JAXRSUtils.readFromMessageBody(JAXRSUtils.java:
827)
at
org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameter(JAXRSUtils.java:470
)
at
org.apache.cxf.jaxrs.utils.JAXRSUtils.processParameters(JAXRSUtils.java:43
5)
at
org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.processRequest(JAXRSIn
Interceptor.java:194)
at
org.apache.cxf.jaxrs.interceptor.JAXRSInInterceptor.handleMessage(JAXRSInI
nterceptor.java:65)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorCha
in.java:236)
- locked <0x00002aaae3f00288> (a
org.apache.cxf.phase.PhaseInterceptorChain)
at
org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiation
Observer.java:89)
at
org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestinat
ion.java:99)
at
org.apache.cxf.transport.servlet.ServletController.invokeDestination(Servl
etController.java:368)
at
org.apache.cxf.transport.servlet.ServletController.invoke(ServletControlle
r.java:146)
at
org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServ
let.java:163)
at
org.apache.cxf.transport.servlet.AbstractCXFServlet.doPost(AbstractCXFServ
let.java:141)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicati
onFilterChain.java:269)
Im going to further investigate this and possibly come up with a test case
for it (I suspect its a boundary issue), however I just wanted to see if
this was a known issue and a fix maybe available in a more recent
release...? If so then it might be time for the upgradatron to come into
action...
