[MNT-10934] Bug in OpenCMIS causing memory leak Created: 15-Mar-14  Updated: 31-Aug-16  Resolved: 30-May-14

Status: Closed
Project: Service Packs and Hot Fixes
Component/s: CMIS, ZZ_Archive
Affects Version/s: 4.1.3
Fix Version/s: 4.1.9

Type: Service Pack Request
Reporter: Pavel Lungu (Inactive) Assignee: Closed Bugs (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 days, 30 minutes
Original Estimate: Not Specified
Environment:

Version: 4.1.3
Database: Oracle
App Server: Tomcat
Mobile Version: Not Applicable
OS: Ubuntu
Workdesk Version: 4.1.1.1


Attachments: Text File frozen-threads-wpcq9.txt     HTML File fullpayload    
Issue Links:
Cloners
is cloned by MNT-11596 CLONE - Bug in OpenCMIS causing memor... Closed
Duplicate
Bug Priority:
Category 1
ACT Numbers:

00151276

Build Location: http://releases.alfresco.com/Enterprise%204.1/4.1.9/build-00036/

 Description   

Customer reports that due to apparent bug in OpenCMIS there system becomes unresponsive.

Reviewing memory utilization with JConsole and/or YourKit profiler shows huge amounts of memory being allocated and de-allocated in a short period of time and a lot of time is spent garbage collecting. So much time in fact that the server is unresponsive.

There are many threads that are frozen and look like this (note they are not deadlocked):

http-127.0.0.1-8080-1 <--- Frozen for at least 1m 48 sec
com.ctc.wstx.sr.NsInputElementStack.push(String, String)
com.ctc.wstx.sr.BasicStreamReader.handleStartElem(char)
com.ctc.wstx.sr.BasicStreamReader.nextFromTree()
com.ctc.wstx.sr.BasicStreamReader.next()
org.apache.chemistry.opencmis.server.impl.atompub.AtomEntryParser.next(XMLStreamReader)
org.apache.chemistry.opencmis.server.impl.atompub.AtomEntryParser.skip(XMLStreamReader)
org.apache.chemistry.opencmis.server.impl.atompub.AtomEntryParser.parseCmisContent(XMLStreamReader)
org.apache.chemistry.opencmis.server.impl.atompub.AtomEntryParser.parseEntry(XMLStreamReader)
org.apache.chemistry.opencmis.server.impl.atompub.AtomEntryParser.parse(InputStream)
org.apache.chemistry.opencmis.server.impl.atompub.ObjectService.create(CallContext, CmisService, String, HttpServletRequest, HttpServletResponse)
sun.reflect.GeneratedMethodAccessor1253.invoke(Object, Object[])
sun.reflect.DelegatingMethodAccessorImpl.invoke(Object, Object[])
java.lang.reflect.Method.invoke(Object, Object[])
org.apache.chemistry.opencmis.server.shared.Dispatcher.dispatch(String, String, CallContext, CmisService, String, HttpServletRequest, HttpServletResponse)
org.apache.chemistry.opencmis.server.impl.atompub.CmisAtomPubServlet.dispatch(CallContext, HttpServletRequest, HttpServletResponse)
org.apache.chemistry.opencmis.server.impl.atompub.CmisAtomPubServlet.service(HttpServletRequest, HttpServletResponse)
javax.servlet.http.HttpServlet.service(ServletRequest, ServletResponse)



 Comments   
Comment by Scott Ashcraft [ 21-Mar-14 ]

Latest comment from customer:

I am now able to reproduce the issue on command in my development environment. I have a much better understanding of what is triggering the issue, although there is still more debugging to sort out all of the bugs involved. Sigh.

See the other ticket I referenced yesterday: 00151812, basically when I drag and drop a file with some unicode characters in the name into workdesk 4.1.1.1, The unicode characters are getting munged. This was not repeatable with stock 4.1.1.1 so I have to figure that out.

What ends up happening is that workdesk creates a content stream to pass to chemistry this includes the file and the filename. Rather than using the cmis:name property it uses the invalid name that came through the html5 uploader. This name includes a carriage return in the middle! It is invalid to have any control characters (ascii less than 0x20) in an xml document.

Workdesk (OwCMISContentFactory.createContentStream) does not filter this, chemistry (AtomEntryWriter) does not filter this, woodstox does not filter this, it does throw an exception (this appears to be BaseStreamWriter from webservices-rt-2.0.jar, but I'm still investigating.)

The chemistry 0.8 client in workdesk both opens a connection to send an atompub document to alfresco and fails throwing the exception described in the referenced workdesk ticket, thus it does not fully produce the output document.

I'm not yet clear if the looping over atom:entry is in the client or the server. From a cursory look it appears to be in the server and not the client. So that is the next thing I need to figure out.

Comment by Derek Hulley [X] (Inactive) [ 31-Aug-16 ]

The component originally used was not a supported, recognisable system component with an associated component owner. Either the component never existed (it was fictional) or it has reached end-of-life.
The issues will be closed. Reopen and assign to an existing system component if necessary. Use labels appropriately.

Generated at Sun Mar 07 18:40:28 GMT 2021 using Jira 7.13.15#713015-sha1:7c5ddd2c3e1709974ae9c48c17df8edd3919fe2c.