Hi Gary,
I don't think there is a JIRA issue. I have just discovered that the
setting I was using for the dedicated task runner was being ignored. I'm
running ActiveMQ as a Windows Service and I just found that there is also a
setting for the dedicated task runner in bin\win32\wrapper.conf. I
Stefan,
is there a jira issue for this, if not can you open one and capture
the problem with a test case. Is it that even with "dedicated task
runner"=false there is a direct correlation between the number of
threads and the number of destinations?
Or is it that the memory usage of a destination i
So this issue doesn't occur in 4.1? I might consider downgrading because I
have no other options at this point.
Thanks,
Stefan
Danilo Tuler wrote:
>
> Hi Stefan,
>
> I'm on the same boat.
> I'm hitting some 4.1 issues, and I'm considering (again) to migrate to
> 5.2.0.
> But this issue is pus
Hi Stefan,
I'm on the same boat.
I'm hitting some 4.1 issues, and I'm considering (again) to migrate to
5.2.0.
But this issue is pushing me back.
Danilo
stefan.moser wrote:
>
> Has there been any progress on this issue? I've just started using
> ActiveMQ and require a large number of topics.
Has there been any progress on this issue? I've just started using ActiveMQ
and require a large number of topics. I am getting the same OOME once it
creates ~1000 topics. I've tried this with v 5.0, 5.1 and 5.2.
Thanks,
Stefan
Danilo Tuler wrote:
>
> Hi Hiram,
>
>
> Hiram Chirino wrote:
>
Hi Hiram,
Hiram Chirino wrote:
>
> Please post a stack trace of all those threads that on the broker side
> when you run this test.
I'm attaching both debug logs from the server and the client.
The OOME stack trace is below.
INFO | jvm 1| 2008/05/22 23:29:01 | java.lang.OutOfMemoryError
Please post a stack trace of all those threads that on the broker side
when you run this test. It would help us tremendously in figuring out
the problem. and BTW I do think it's a problem.
On Thu, May 22, 2008 at 2:40 PM, Danilo Tuler <[EMAIL PROTECTED]> wrote:
>
> Hi Filip,
>
>
> Filip Hanik -
Danilo Tuler wrote:
Hi Filip,
Filip Hanik - Dev Lists wrote:
in the test case provided, the program is trying to create 5000+
connections/sessions, hence that would require 5000 threads, not very
scalable.
No, the program is not creating 5000+ connections/sessions. There is a
single
Hi Filip,
Filip Hanik - Dev Lists wrote:
>
> in the test case provided, the program is trying to create 5000+
> connections/sessions, hence that would require 5000 threads, not very
> scalable.
No, the program is not creating 5000+ connections/sessions. There is a
single connection and sessi
Danilo Tuler wrote:
Hi Filip,
Filip Hanik - Dev Lists wrote:
essentially, it's more of a tuning thingy then a memory leak, if one
needs that many topics/queues, then not running with the dedicated task
runner sounds like the solution,
I didn't understand why you classify this issu
could you post a stack trace of your broker when it's got a alot of
threads allocated? Thx.
On Fri, May 16, 2008 at 3:51 PM, Danilo Tuler <[EMAIL PROTECTED]> wrote:
>
>
>
> Hiram Chirino wrote:
>>
>> I modified your case so that it's a JUnit test and so that it starts
>> an embedded broker.. I di
Hi Filip,
Filip Hanik - Dev Lists wrote:
>
> essentially, it's more of a tuning thingy then a memory leak, if one
> needs that many topics/queues, then not running with the dedicated task
> runner sounds like the solution,
>
I didn't understand why you classify this issue as a "tuning thing
essentially, it's more of a tuning thingy then a memory leak, if one
needs that many topics/queues, then not running with the dedicated task
runner sounds like the solution,
Filip
Filip Hanik - Dev Lists wrote:
so it seems there are two OOME problems
either you hit java heap space error, or
so it seems there are two OOME problems
either you hit java heap space error, or if you have increased your -Xmx
very high, you'll run into OOME caused by not enough mem for the number
of threads it tries to create.
the two errors are directly related to each other, increasing -Xmx (java
hea
that's from trunk ?
On 16 May 2008, at 20:12, Hiram Chirino wrote:
Looks like my memory problems are all related to the kaha HashIndex:
By the time I create 3000 queues, there are about 5000 HashIndex
object allocated. The retained size of those HashIndex objects is
about 187 megs. 163 megs o
Hiram Chirino wrote:
>
> I modified your case so that it's a JUnit test and so that it starts
> an embedded broker.. I did not see the threading problem against the
> trunk, but I did see :
>
> javax.jms.JMSException: Java heap space
>
> If you run my modified test case do you still see the t
BTW you tested this against 5.1 right?
On Fri, May 16, 2008 at 2:29 PM, Danilo Tuler <[EMAIL PROTECTED]> wrote:
>
>
>
> Hiram Chirino wrote:
>>
>> Still it would be nice if you could create a test case that shows the
>> problem and submit it so we can get to the root of the problem.
>>
>
> The att
Looks like my memory problems are all related to the kaha HashIndex:
By the time I create 3000 queues, there are about 5000 HashIndex
object allocated. The retained size of those HashIndex objects is
about 187 megs. 163 megs of that are just byte[]s being held directly
by the HashIndex and the D
I modified your case so that it's a JUnit test and so that it starts
an embedded broker.. I did not see the threading problem against the
trunk, but I did see :
javax.jms.JMSException: Java heap space
at
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.java:49)
Hiram Chirino wrote:
>
> Still it would be nice if you could create a test case that shows the
> problem and submit it so we can get to the root of the problem.
>
The attached code shows the problem.
With UseDedicatedTaskRunner=false it works ok.
http://www.nabble.com/file/p17281318/App.java
Enabling that enables thread pooling. It just increases context
switching a bit.
Still it would be nice if you could create a test case that shows the
problem and submit it so we can get to the root of the problem.
Regards,
Hiram
On Thu, May 15, 2008 at 5:54 PM, Sridhar2008 <[EMAIL PROTECTED]>
Hi Hiram,
We were having similar issue and confirmed the following
(-Dorg.apache.activemq.UseDedicatedTaskRunner=false) works for us.
What are the implications of doing this ?
Thanks
- Sridhar
Hiram Chirino wrote:
>
> Could you try updating your activemq startup script so that instead of:
Could you submit a test case - I've tried to reproduce from your description
- but with no success
cheers,
Rob
--
View this message in context:
http://www.nabble.com/java.lang.OutOfMemoryError%3A-unable-to-create-new-native-thread-on-AMQ-5.0-tp17005441s2354p17257710.html
Sent from the ActiveM
Could you try updating your activemq startup script so that instead of:
ACTIVEMQ_OPTS="-Xmx512M -Dorg.apache.activemq.UseDedicatedTaskRunner=true"
it reads as:
ACTIVEMQ_OPTS="-Xmx512M -Dorg.apache.activemq.UseDedicatedTaskRunner=false"
I think that should help with your thread usage issues.
On T
Hi,
I have this problem too. It happens with AMQ 5.0.0 and 5.1.0. Works fine
with 4.1.1 and 4.1.2.
I can see the number of threads using the windows task manager, and it's not
good :-) +2000 threads.
My client application is a producer, and it sends thousands of messages to
thousands of differen
I'm talking about the mem settings for the JVM that gets the OOME
in the settings below, I would remove the -Xmn flag, and let the JVM
size the new generation itself
Also, lower -Xmx800m, and if there is a heap space OOME problem, that
will occur before the "unable to create new native thread",
Hi again,
here are the full stack traces.
1 - Broker
Loading message broker from: xbean:activemq.xml
INFO BrokerService - Using Persistence Adapter:
AMQPersistenceAdapter(/work/michele/apache-activemq-5.0.0/data/localhost)
INFO BrokerService - ActiveMQ 5.0.0 JM
Hi Jamie,
thanks for your reply. Unfortunately the HeapDumpOnOutOfMemoryError
options works only when the OOME is due to heap space problems, not
when the system is unable to create new threads [1].
Michele
[1] http://java.sun.com/javase/6/webnotes/trouble/TSG-VM/html/
gdaog.html#gbzrr
Filip,
are you talking about the broker or the client? The settings below
are for the broker.
Michele
On 2 May 2008, at 00:20, Filip Hanik - Dev Lists wrote:
-Xms512m -Xmx1024m -Xmn500m
If you can use Java 6, try the following setting:
-XX:+HeapDumpOnOutOfMemoryError
(and -XX:HeapDumpPath if you want the dump to go somewhere specific)
This will give you a heap dump which should help a _lot_ to diagnose
the problem. I'd recommend checking out the Memory Analyzer plugin for
Eclip
On 2 May 2008, at 00:20, Filip Hanik - Dev Lists wrote:
Michele Mazzucco wrote:
Filip,
if you mean on the client side, I have a thread pool configured to
create max 100 threads.
there could still be a thread leak in your application somewhere
No, there's no leak on my client app. It's a
Michele Mazzucco wrote:
Filip,
if you mean on the client side, I have a thread pool configured to
create max 100 threads.
there could still be a thread leak in your application somewhere
about -Xmx, that's the maximum amount of memory. Why are you telling
me that by decreasing that value t
Filip,
if you mean on the client side, I have a thread pool configured to
create max 100 threads.
about -Xmx, that's the maximum amount of memory. Why are you telling
me that by decreasing that value there would be more space for
threads?
Michele
On Thu, May 1, 2008 at 7:50 PM, Filip Hanik - De
when it happens, do a thread dump to make sure you don't have a thread
leak (too many threads)
then lower your -Xmx setting, this will make more room in the JVM for
threads,
Filip
Michele Mazzucco wrote:
Hi all,
I'm facing the following error while using AMQ 5.0
ERROR efaultMessageListene
Hi all,
I'm facing the following error while using AMQ 5.0
ERROR efaultMessageListenerContainer - Setup of JMS message listener
invoker failed - trying to recover
java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.
35 matches
Mail list logo
