I have created a bug in the CXF JIRA project @ https://issues.apache.org/jira/browse/CXF-2706 with test case attached...
Cheers Mustafa -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: Tuesday, 9 March 2010 10:56 PM To: [email protected] Subject: Re: CXF not detecting dead client when processing multipart msgs Ok I have determined this to exist in the most recent version of cxf aswell and have a test to proove this. It occurs when the end boundary of a multipart MSG is missing, the while loop runs continuously waiting for data from the client. Even though the socket has closed cxf doesn't seem to detect this, specifically the MimeBodyPartInputStream. I will submit this as a bug. On 09/03/2010, at 4:16 PM, "Mustafa Sezgin" <[email protected]> wrote: > 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... >
