[MNT-10934] Bug in OpenCMIS causing memory leak Created: 15-Mar-14 Updated: 31-Aug-16 Resolved: 30-May-14
|Project:||Service Packs and Hot Fixes|
|Type:||Service Pack Request|
|Reporter:||Pavel Lungu (Inactive)||Assignee:||Closed Bugs (Inactive)|
|Remaining Estimate:||0 minutes|
|Time Spent:||2 days, 30 minutes|
|Original Estimate:||Not Specified|
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
|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 184.108.40.206, The unicode characters are getting munged. This was not repeatable with stock 220.127.116.11 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.