Rob, While doing some performance tests on Servicemix I had the same kind of issue where I ran out of memory with the SEDA queue logging OutOfMemoryError. In this test I only used the standard JBI components ex. File,EIP(splitter/aggregator)etc
I could get rid of the issues by controlling (thread pools)the following parameters in servicemix.properties --------------------------------------------------------------- servicemix.corePoolSize = 2 servicemix.maximumPoolSize = 4 servicemix.queueSize = 256 --------------------------------------------------------------- Ofcourse these setting will depend upon the kind of environment you are testing with (available memory,CPUs etc) You can also have fine-grained thread-pool control as mentioned in the documentation, http://incubator.apache.org/servicemix/thread-pools.html Regards, Rabi Mishra, http://rabisblog.blogspot.com/ c++; /* this makes c bigger but returns the old value */ -----Original Message----- From: Gert Vanthienen [mailto:[EMAIL PROTECTED] Sent: Monday, July 02, 2007 4:23 PM To: [email protected] Subject: Re: Out of Memory Error Rob, I'm not sure that you can even have multiple heap spaces in a single JVM process, so I suppose this could be caused by your own binding component. You should try to figure out if your application has a memory leak somewhere (check if memory usage is increasing steadily at runtime) or if your processing is just very memory-intensive (exceeding the amount that is available)? Gert Rob de Jong wrote: > Hello, > > During a test of a deployment, ServiceMix returned an OutOfMemoryError. > The deployment uses a custom made Binding Component, and my first > assumption would be that this Binding Component is flooding the memory; > there is some pretty load-heavy processing going on in there. > > Yet, when viewing the stack trace (added further on), I did notice that > it is one of the Seda Queues that logs the exception, and it references > to a failed InOut message send from the custom BC to a LW XSLT > transformer. > > Now I wonder in what wat I can get certainty concerning which > component/Queue is causing these problems. Do the Binding Components in > ServiceMix use the same Java heap space as the Seda queues (or other > parts of smx for that matter)? If so, a flooding of the memory from a > binding component can result in any arbitrary part of smx to run into > the memory error first, as the available memory of all components is > equally reduced. > > Cheers, > Rob de Jong > > > The stack trace I'm given is as follows: > ERROR - SedaQueue - > org.apache.servicemix.jbi.nmr.flow.seda > [EMAIL PROTECTED] got error processing InOut[ > id: ID:urbi-22-4265-1183321973531-7:48464 > status: Active > role: provider > service: {http://www.vrom.nl/wkpb/wsdl/wkpb0102.wsdl}AKR2WKPB > endpoint: AKR2WKPB > in: <?xml version="1.0" > encoding="UTF-8"?><voegPerceelToe><PERCEEL><ID_OBJECT> > HLM03AD07026G0000</ID_OBJECT><KADASTRALE_GEMEENTECODE_ALG>HLM03</KADASTR > ALE_GEME > ENTECODE_ALG><OBJECTINDEXLETTER_ALG>G</OBJECTINDEXLETTER_ALG><SECTIE_ALG > >> AD</SEC >> > TIE_ALG><PERCEELNUMMER_ALG>07026</PERCEELNUMMER_ALG><OBJECTINDEXNUMMER_A > LG>0000< > /OBJECTINDEXNUMMER_ALG><ID_OBJECT>HLM03AD07026G0000</ID_OBJECT><OBJECTIN > DEXLETTE > R_ALG>G</OBJECTINDEXLETTER_ALG><CBS_CODE>0512</CBS_CODE><SEQNR>31</SEQNR > >> </PERCE >> > EL><MSG_ZENDER>AKR</MSG_ZENDER><MSG_ONTVANGER>Obterra</MSG_ONTVANGER><MS > G_REFERE > NTIENUMMER>28937</MSG_REFERENTIENUMMER><MSG_TIJDSTIP>20070702043350578</ > MSG_TIJD > STIP></voegPerceelToe> > ] > java.lang.OutOfMemoryError: Java heap space > at org.apache.xpath.VariableStack.reset(VariableStack.java:137) > at > org.apache.xalan.transformer.TransformerImpl.reset(TransformerImpl.ja > va:507) > at > org.apache.xalan.transformer.TransformerImpl.transformNode(Transforme > rImpl.java:1436) > at > org.apache.xalan.transformer.TransformerImpl.transform(TransformerImp > l.java:709) > at > org.apache.xalan.transformer.TransformerImpl.transform(TransformerImp > l.java:1284) > at > org.apache.xalan.transformer.TransformerImpl.transform(TransformerImp > l.java:1262) > at > org.apache.servicemix.components.xslt.XsltComponent.transformContent( > XsltComponent.java:175) > at > org.apache.servicemix.components.xslt.XsltComponent.transform(XsltCom > ponent.java:154) > at > org.apache.servicemix.components.util.TransformComponentSupport.onMes > sageExchange(TransformComponentSupport.java:66) > at > org.apache.servicemix.jbi.messaging.DeliveryChannelImpl.processInBoun > d(DeliveryChannelImpl.java:593) > at > org.apache.servicemix.jbi.nmr.flow.AbstractFlow.doRouting(AbstractFlo > w.java:174) > at > org.apache.servicemix.jbi.nmr.flow.seda.SedaFlow.doRouting(SedaFlow.j > ava:176) > at > org.apache.servicemix.jbi.nmr.flow.seda.SedaQueue$1.run(SedaQueue.jav > a:134) > at > edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Wor > ker.runTask(ThreadPoolExecutor.java:665) > at > edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Wor > ker.run(ThreadPoolExecutor.java:690) > at java.lang.Thread.run(Thread.java:619) > > > The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com
