I found the cause: I had DEBUG level for logging. DeliveryChannelImpl.doSend is logging MessageExchangeImpl. Xerces was creating lots of arrays of int. I am enclosing stack trace from netbeans profiler: http://www.nabble.com/file/5170/logging_message.png
When I increased logging level (to WARN) then the problem dissapeared. I wonder why it didn't happen in ST flow - doSend method is also called in this flow? Maybe in ST flow doSend method is called much less freqently? However, I still have problems: Jsr181ExchangeProcessor.doProcess sets XMLstreamReader to message. Creating xmlstreamreader allocates lots of arrays of char's and they were not garbage collected (live objects are equal to totally allocated). I am enclosing stack trace from netbeans profiler: http://www.nabble.com/file/5171/create_xml_stream_reader.png Again, why this problem does not occur in ST flow? In ST flow doProcess method is also called. To recapitulate: I am using SM3.0. ActiveMQ is embedded in SM. I have 64M memory (for testing purpose). Problems occurs when I use Seda flow - ST flow does not reports such problems. Here is my scenario: - I have a webservice (therefore you can see Jsr181 classes on the stack) that is accessible via http connector - webservice validates xml (sends message to validate component) and then sends xml to jms (via message exchange mechanism). After around 1000 WS calls I get outofmemoryerror. Please advise gnodet wrote: > > Given your figures, I agree with your conclusion that it seems > there is a memory leak in SEDA flow :( > Could you raise a JIRA and attach the configuration you used > so that we can reproduce the problem ? > > On 10/4/06, Michal <[EMAIL PROTECTED]> wrote: >> >> Hi, >> >> I was sending lots of messages to activemq queue via servicemix using >> sendSync method - there were no cunsumers connected to the queue. After >> some >> time I run out of memory. >> >> Here are the details: >> >> a) servicemix 3.0 M2, activemq (in seperate process), sedaflow - out of >> memory >> b) servicemix 3.0 M2, activemq (in seperate process), stflow - out of >> memory >> c) servicemix 3.0, activemq (in seperate process), sedaflow - out of >> memory >> d) servicemix 3.0, activemq (in seperate process), stflow - NO PROBLEM >> e) servicemix 3.0, activemq (embedded broker, persistent=true, >> memorymanagerlimit), sedaflow - out of memory >> f) servicemix 3.0, activemq (embedded broker, persistent=true, >> memorymanagerlimit), stflow - NO PROBLEM >> >> Conclusion: >> >> - there is a memory leak in M2 - indeed, I have seen som bugfix in 3.0 >> release so I used new version >> - sedaflow eats up memory - memory leak? >> >> Is there really a memory leak in SedaFlow? Or maybe I need to configure >> it >> properly? >> Is StFlow recommended for production? >> >> >> Please advise. >> Michal >> >> >> >> >> >> >> -- >> View this message in context: >> http://www.nabble.com/SedaFlow---OutOfMemoryError-tf2382645.html#a6640548 >> Sent from the ServiceMix - User mailing list archive at Nabble.com. >> >> > > > -- > Cheers, > Guillaume Nodet > > -- View this message in context: http://www.nabble.com/SedaFlow---OutOfMemoryError-tf2382645s12049.html#a8096425 Sent from the ServiceMix - User mailing list archive at Nabble.com.
