Hi Freeman. You were right: with the latest version I don't get an OutOfMemoryError. With that resolved, I'm still worried about the amount of memory used when I receive a big payload. Do you know if there are any known issues when managing payloads of about 3MB? Is there some kind of maximum recommended size?
Thanks a lot. On Thu, Aug 20, 2009 at 5:51 PM, Sebastian Gomez <[email protected]> wrote: > Hi Freeman. > Thanks for the advice, I'll give it a try and update you with the results. > > > On Thu, Aug 20, 2009 at 2:11 PM, Freeman Fang <[email protected]>wrote: > >> Hi, >> Servicemix 3.3 was released almost one year ago, after that, several >> memory issues of cxf bc get fixed. >> Could you test with the latest released fuse 3.4.0.4 [1](which is based on >> apache servicemix 3.3 but released more recently)? >> >> [1] >> http://repo.open.iona.com/maven2/org/apache/servicemix/apache-servicemix/3.4.0.4-fuse/ >> Freeman >> >> On 2009-8-20, at 下午5:25, Sebastian Gomez wrote: >> >> Hi everyone. >>> I'm using YourKit to monitor the memory usage in my application running >>> on >>> ServiceMix 3.3 because there seems to be some kind of memory leak that >>> finally ends up with a OutOfMemoryError due to the heap space. After >>> removing a few SUs from my SA, I've detected the one that grabs hold of >>> the >>> memory is cxf-bc. Playing around with the thread pools I've seen that if >>> I >>> reduce the number of threads of this component, the memory does not seem >>> to >>> run out. This makes me think that the threads are using up a lot of >>> memory >>> even though their job has already finished. I've run into the same >>> problem >>> using both ODE and EIP separately to control the flows, so I'm leaving it >>> to >>> ServiceMix to mark the exchanges as DONE, so I think it can't be the >>> typical >>> not-marking-the-exchanges-as-done error. >>> >>> To support my idea: >>> I'm consuming two types of messages from a third party WS. The first type >>> is >>> a small message (approximately 2KB), while the second is quite large >>> (approx. 2MB). Both messages contain all their information in the >>> payload, >>> i.e. there are no attachments. If I download lots of the large messages, >>> the >>> heap is quickly used up. But if I download only some large ones (not >>> enough >>> to use up the whole heap, but most of it), and then I download lots of >>> the >>> small ones, the heap is freed. It looks like the threads in the pool used >>> to >>> download large files are being used to download the small ones so they >>> free >>> the memory they where using up for the large files. I'm not sure if this >>> makes sense, but it's what I've noticed using YourKit. >>> >>> I'd appreciate someone telling me if my assumption could be possible. Has >>> someone tried downloading large payloads using cxf-bc? I see in YourKit >>> that >>> lots of Xerces DOM objects are being created, I'm worried that they >>> aren't >>> being freed once the thread has finished its job. Would it be possible to >>> add an interceptor before cxf-bc consumes the message to convert it into >>> a >>> small payload with an attachment? This should prevent the >>> OutOfMemoryError, >>> shouldn't it? >>> >>> Hope someone has read so far and is still willing to help. Thanks in >>> advance. >>> >>> Sebastian Gomez. >>> >> >> >> -- >> Freeman Fang >> ------------------------ >> Open Source SOA: http://fusesource.com >> >> >
