Aha I just tried it out by myself both on Java 6 & Java 7 of Oracle JRE and
the right option being still supported is:

   -XX:+HeapDumpOnOutOfMemoryError

And not:

   -XX:+HeapDiagnosticsOnOutOfMemoryError

which used to be for the Oracle JRockit JVM.

Babak


flavio.magacho wrote
> Thank you Vahdat, we will check this out!
> 
> Flavio Magacho
> Gerente de Desenvolvimento
> Diretoria de Tecnologia da Informação
>   M4U
> +55 (21) 2546-4050 ▪ Ramal: 4082
> +55 (21) 8889-1572
>  Antes de imprimir, pense em sua responsabilidade e compromisso com o
> Meio Ambiente.
> O conteúdo desta mensagem é confidencial e pode ser privilegiado. É vedada
> a sua cópia ou divulgação.
> The contents of this message are confidential and may be privileged.
> Copying or disclosing is prohibited.
> 
> 
> -----Original Message-----
> From: Babak Vahdat [mailto:

> babak.vahdat@

> ] 
> Sent: terça-feira, 20 de agosto de 2013 15:32
> To: 

> [email protected]

> Subject: RE: Load test on camel-netty
> 
> If Oracle/Sun JDK is in use then maybe ask for a heap dump as the
> OutOfMemoryError happens:
> 
> http://docs.oracle.com/cd/E15289_01/doc.40/e15062/optionxx.htm#BABBBEAJ
> 
> Then you could analyze the dump (e.g. using http://www.eclipse.org/mat/)
> to see where that huge memory consumption or the leak (if any) comes from.
> 
> Babak
> 
> 
> flavio.magacho wrote
>> Claus,
>> Thanks for your answer, we have done that and nothing changes.
>> 
>> 
>> Flavio Magacho
>> Gerente de Desenvolvimento
>> Diretoria de Tecnologia da Informação
>>   M4U
>> +55 (21) 2546-4050 ▪ Ramal: 4082
>> +55 (21) 8889-1572
>> þ Antes de imprimir, pense em sua responsabilidade e compromisso com o 
>> Meio Ambiente.
>> O conteúdo desta mensagem é confidencial e pode ser privilegiado. É 
>> vedada a sua cópia ou divulgação.
>> The contents of this message are confidential and may be privileged.
>> Copying or disclosing is prohibited.
>> 
>> 
>> -----Original Message-----
>> From: Claus Ibsen [mailto:
> 
>> claus.ibsen@
> 
>> ]
>> Sent: terça-feira, 20 de agosto de 2013 12:00
>> To: 
> 
>> [email protected]
> 
>> Subject: Re: Load test on camel-netty
>> 
>> I would suggest to remove the 100 thread pool sizes as the out of the 
>> box settings from Netty is better. Netty is asynchronous and it 
>> creates thread pools based on the number of CPU cores etc.
>> 
>> Netty creates the threads up-front so having 100+ threads take up some 
>> unnecessary memory.
>> 
>> 
>> On Tue, Aug 13, 2013 at 5:02 PM, Flavio Magacho - M4U <
> 
>> [email protected]
> 
>>> wrote:
>> 
>>> Hi, ****
>>>
>>> I'm expecting some problems while running a load test on camel-netty
>>> component.****
>>>
>>> ** **
>>>
>>> This is the route configuration:****
>>>
>>> 
>> 
> <route id="rtRead">
>> ****
>>>
>>>                 
>> 
> <from
>>
>>
>>  
>> uri="netty:tcp://pos-tcp-server.host:9000?decoder=#myDecoder&amp;encod
>>> er=#myEncoder&amp;sync=true&amp;reuseAddress=true&amp;synchronous=fal
>>> s e&amp;workerCount=100&amp;maximumPoolSize=100”/>
>>> ****
>>>
>>>                 
>> 
> <log message="Lendo ${body}" />
>> ****
>>>
>>>                 
>> 
> <to uri="ejb:local/GatewayBean?method=process" />
>> ****
>>>
>>> 
>> 
> </route>
>> ****
>>>
>>> ** **
>>>
>>> After some test cycles, we receive some exceptions like this:****
>>>
>>> 2013-08-13 11:25:33,398 WARNING
>>> [org.jboss.netty.channel.DefaultChannelPipeline] [New I/O  worker 
>>> #32] An exception was thrown by a user handler while handling an 
>>> exception event
>>> ([id: 0x8c7d41bd, /10.10.0.28:53469 => /10.11.234.38:9000] EXCEPTION:
>>> java.lang.OutOfMemoryError: unable to create new native thread)****
>>>
>>> java.lang.OutOfMemoryError: unable to create new native thread****
>>>
>>>         at java.lang.Thread.start0(Native Method)****
>>>
>>>         at java.lang.Thread.start(Thread.java:640)****
>>>
>>>         at
>>> java.util.concurrent.ThreadPoolExecutor.addIfUnderCorePoolSize(Thread
>>> P
>>> oolExecutor.java:703)
>>> ****
>>>
>>>         at
>>> java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.ja
>>> v
>>> a:652)
>>> ****
>>>
>>>         at
>>> org.jboss.netty.handler.execution.MemoryAwareThreadPoolExecutor.doUno
>>> r
>>> deredExecute(MemoryAwareThreadPoolExecutor.java:452)
>>> ****
>>>
>>>         at
>>> org.jboss.netty.handler.execution.OrderedMemoryAwareThreadPoolExecuto
>>> r
>>> $ChildExecutor.execute(OrderedMemoryAwareThreadPoolExecutor.java:292)
>>> ****
>>>
>>>         at
>>> org.jboss.netty.handler.execution.OrderedMemoryAwareThreadPoolExecuto
>>> r
>>> .doExecute(OrderedMemoryAwareThreadPoolExecutor.java:242)
>>> ****
>>>
>>>         at
>>> org.jboss.netty.handler.execution.MemoryAwareThreadPoolExecutor.execu
>>> t
>>> e(MemoryAwareThreadPoolExecutor.java:437)
>>> ****
>>>
>>>         at
>>> org.jboss.netty.handler.execution.ExecutionHandler.handleUpstream(Exe
>>> c
>>> utionHandler.java:172)
>>> ****
>>>
>>>         at
>>> org.jboss.netty.channel.Channels.fireExceptionCaught(Channels.java:53
>>> 3
>>> )***
>>> *
>>>
>>>         at
>>> org.jboss.netty.channel.Channels$7.run(Channels.java:507)****
>>>
>>>         at
>>> org.jboss.netty.channel.socket.ChannelRunnableWrapper.run(ChannelRunn
>>> a
>>> bleWrapper.java:41)
>>> ****
>>>
>>>         at
>>> org.jboss.netty.channel.socket.nio.AbstractNioWorker.processEventQueu
>>> e
>>> (AbstractNioWorker.java:453)
>>> ****
>>>
>>>         at
>>> org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioW
>>> o
>>> rker.java:330)
>>> ****
>>>
>>>         at
>>> org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:35)**
>>> *
>>> *
>>>
>>>         at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExec
>>> u
>>> tor.java:886)
>>> ****
>>>
>>>         at
>>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.
>>> java:908)
>>> ****
>>>
>>>         at java.lang.Thread.run(Thread.java:662)****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> It sounds strange, our test case has only 5 simultaneous opened
>>> connections.****
>>>
>>> For me we are heaving some leak of threads or we are having some 
>>> problems to close the SocketChannel correctly.****
>>>
>>> ** **
>>>
>>> Thanks,****
>>>
>>> *Flavio Magacho*
>>>
>>> *Gerente de Desenvolvimento*
>>>
>>> Diretoria de Tecnologia da Informação****
>>>
>>> [image: cid:[email protected]]  *M4U*
>>> +55 (21) 2546-4050 ▪ Ramal: 4082****
>>>
>>> +55 (21) 8889-1572****
>>>
>>> *þ** *Antes de imprimir, pense em sua responsabilidade e compromisso 
>>> com o Meio Ambiente.****
>>>
>>> *O conteúdo desta mensagem é confidencial e pode ser privilegiado. 
>>> **É vedada a sua cópia ou divulgação.*
>>>
>>> *The contents of this message are confidential and may be privileged.
>>> Copying or disclosing is prohibited.*****
>>>
>>> ** **
>>>
>> 
>> 
>> 
>> --
>> Claus Ibsen
>> -----------------
>> Red Hat, Inc.
>> Email: 
> 
>> cibsen@
> 
>> Twitter: davsclaus
>> Blog: http://davsclaus.com
>> Author of Camel in Action: http://www.manning.com/ibsen
> 
> 
> 
> 
> 
> --
> View this message in context:
> http://camel.465427.n5.nabble.com/Load-test-on-camel-netty-tp5737221p5737618.html
> Sent from the Camel - Users mailing list archive at Nabble.com.





--
View this message in context: 
http://camel.465427.n5.nabble.com/Load-test-on-camel-netty-tp5737221p5737642.html
Sent from the Camel - Users mailing list archive at Nabble.com.

Reply via email to