Do you use a vm:// activemq broker or a tcp:// one ? Does it change anything ?
On 9/21/07, Gert Vanthienen <[EMAIL PROTECTED]> wrote: > L.S., > > Just yesterday, I have run into the same problem with a customer. A > ServiceMix installation that was working fine just started using > excessive amounts of memory after adding a SA with only two endpoints in > it. I have disabled the JMS/JCA flows for now, which solves the problem > by taking most of the load of ActiveMQ. Does anyone know which ActiveMQ > issue this user was referring to, so I can check if it really solves > this particular problem while I have the opportunity to do so? > > Regards, > > Gert > > ArmenH wrote: > > Any word on when 3.1.2 would be available? > > > > Also, how do we proceed with commercial quality support? > > > > Armen H. > > > > Gert Vanthienen wrote: > > > >> L.S., > >> > >> As soon as there is an ActiveMQ release which contains the bugfix, we > >> can start the process for a 3.1.2 release. I think Bruce and Thomas > >> have already backported some important fixes to be released with 3.1.2 > >> as well... > >> > >> Gert > >> > >> ArmenH wrote: > >> > >>> FYI. > >>> > >>> We did try replacing the ServiceMix ActiveMQ JAR files with the latest > >>> ActiveMQ SNAPSHOT JAR files and the problem was resolved. > >>> > >>> We would be very anxious to get the ServiceMix 3.1.2 release with all the > >>> latest bug fixes as soon as it becomes available. This directly affects > >>> our > >>> trading application. > >>> > >>> Armen H. > >>> > >>> > >>> Gert Vanthienen wrote: > >>> > >>> > >>>> Armen H., > >>>> > >>>> > >>>> We usually don't pick up SNAPSHOT builds in our releases. However, we > >>>> are planning to a 3.1.2 release sometime in the near future, so if > >>>> ActiveMQ has released the patch by then, we can include it at that time. > >>>> Can you already provide me with a reference to a thread on the mailing > >>>> list or a an ActiveMQ JIRA issue to document this issue? > >>>> > >>>> In the meantime, could you try replacing the JAR files for ActiveMQ in > >>>> your installation with a recent build of ActiveMQ to see if it really > >>>> resolves the problems you're experiencing? > >>>> > >>>> > >>>> Gert > >>>> > >>>> ArmenH wrote: > >>>> > >>>> > >>>>> Hi Gert, > >>>>> > >>>>> We're using HTTP BC and JSR 181 SEs. We have custom business logic > >>>>> (very > >>>>> simple) that uses POJOs generated from the JAXB version of the JDK > >>>>> 1.6.0_01. > >>>>> > >>>>> We are also dependent on JDK 1.6 JAX-WS to generate our service > >>>>> interface > >>>>> (WSDL). > >>>>> > >>>>> We will check the number of service endpoints and let you know. > >>>>> > >>>>> By the way, I have another thread on the ActiveMQ forums and other > >>>>> folks > >>>>> have experienced very similar issues with ActiveMQ as that causes the > >>>>> heap > >>>>> overflow. > >>>>> > >>>>> The fix for this issue was put on July 24 but it's unclear which > >>>>> version > >>>>> it > >>>>> will end up in and also more importantly when would ServiceMix pick up > >>>>> the > >>>>> latest 4.1.x SNAPSHOT from ActiveMQ. > >>>>> > >>>>> Armen H. > >>>>> > >>>>> > >>>>> Gert Vanthienen wrote: > >>>>> > >>>>> > >>>>>> Armen H., > >>>>>> > >>>>>> > >>>>>> What JBI Components (JMS, HTTP, JSR-181, ...) are you using? From > >>>>>> your > >>>>>> description, I assume you at least have a few custom built components > >>>>>> as > >>>>>> well... > >>>>>> > >>>>>> Can you try to use jconsole > >>>>>> (http://incubator.apache.org/servicemix/15-tutorial-using-jmx-to-look-inside-the-esb.html) > >>>>>> to look at the number of service endpoint that are actually > >>>>>> registered? > >>>>>> Also, can you take a look at the number of threads that are in use? > >>>>>> > >>>>>> What version of Java are you using? > >>>>>> > >>>>>> > >>>>>> Gert > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> ArmenH wrote: > >>>>>> > >>>>>> > >>>>>>> Gert, > >>>>>>> > >>>>>>> We use the Windows version for development phase of our services. > >>>>>>> > >>>>>>> We are deploying services by dropping the files in the deploy and > >>>>>>> install > >>>>>>> directories. We don't use JMX for the development phase. > >>>>>>> > >>>>>>> We're using ServiceMix version 3.1 in stand-alone mode. We deploy > >>>>>>> SAs > >>>>>>> as > >>>>>>> well. > >>>>>>> > >>>>>>> Regards, > >>>>>>> Armen H. > >>>>>>> > >>>>>>> > >>>>>>> Gert Vanthienen wrote: > >>>>>>> > >>>>>>> > >>>>>>>> L.S., > >>>>>>>> > >>>>>>>> One of my customers is running ServiceMix on Windows as well, but > >>>>>>>> even > >>>>>>>> with a dozen SA deployed, the memory usage doesn't raise to the > >>>>>>>> amounts > >>>>>>>> you mention here, although there are using several types of services > >>>>>>>> (HTTP, JMS, FTP, File, Saxon, EIP, bean, lwcontainer). > >>>>>>>> > >>>>>>>> What version of ServiceMix and/or Java are you using? Are you using > >>>>>>>> ServiceMix in stand-alone or web application 'mode'? What is the > >>>>>>>> type > >>>>>>>> of > >>>>>>>> service you are trying to deploy? Can you try to check the number > >>>>>>>> of > >>>>>>>> threads that are running with a JMX console? > >>>>>>>> > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> > >>>>>>>> Gert > >>>>>>>> > >>>>>>>> > >>>>>>>> ArmenH wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>>> We have found out that after just one service deployed on Windows > >>>>>>>>> ServiceMix the memory usage jumps to 500 MB and it increases > >>>>>>>>> linearly > >>>>>>>>> after each service deployment until ServiceMix dies with an > >>>>>>>>> OutOfMemoryError. > >>>>>>>>> > >>>>>>>>> We tried increasing the heap size and it helped up to a certain > >>>>>>>>> number > >>>>>>>>> of > >>>>>>>>> services deployed in the container, after that the Error happened > >>>>>>>>> as > >>>>>>>>> expected. > >>>>>>>>> > >>>>>>>>> We used jhatfor heap analysis and found out that the following > >>>>>>>>> instance > >>>>>>>>> usage (after just one service deployment): > >>>>>>>>> > >>>>>>>>> 1673478 instances of class > >>>>>>>>> org.apache.activemq.filter.DestinationMapNode > >>>>>>>>> 3001 instances of class > >>>>>>>>> edu.emory.mathcs.backport.java.util.concurrent.locks.ReentrantLock$NonfairSync > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> This is a critical issue for us. Please advise. > >>>>>>>>> > >>>>>>>>> Regards. > >>>>>>>>> Armen H. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>> > >>>> > >>> > >>> > >> > > > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/