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.
