I've committed a test (into the master, 2.11.x and 2.10.x branches) forcing 20 *simultaneous* client calls without any success to reproduce your problem:
http://git-wip-us.apache.org/repos/asf/camel/diff/2601e560 Babak Babak Vahdat wrote > Any chance to test on the latest version of the 2.10.x branch as 2.10.2 is > about 10 months old, or maybe even 2.11.1 which relies on a newer Netty > version. > > Babak > > Am 14.08.13 21:20 schrieb "Flavio Magacho - M4U" unter > < > [email protected] > >: > >>Vahdat, >>We have already tested with the default value of the maximumPoolSize >>option, and we got the same problem. The version 2.10.2. >> >>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: quarta-feira, 14 de agosto de 2013 06:08 >>To: > [email protected] >>Subject: Re: Load test on camel-netty >> >>Hi >> >>The maximumPoolSize option is *actually* the value for the corePoolSize >>of the ThreadPool being in charge, which is set to 100 in your case (the >>option naming seems a bit misleading to me). Can you try with smaller >>values for this option to see if you can still reproduce the problem. >> >>Other than that depending on which Camel version you make use of the >>Netty OrderedThreadPoolExecutor is *not* in use, see >>https://issues.apache.org/jira/browse/CAMEL-5689 which could cause >>OutOfMemoryError, search for OutOfMemoryError here: >> >>http://netty.io/3.6/api/org/jboss/netty/handler/execution/ExecutionHandler >>.html >> >>Babak >> >> >>flavio.magacho 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&encod >>> er=#myEncoder&sync=true&reuseAddress=true&synchronous=fals >>> e&workerCount=100&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(ThreadPool >>>Executor.java:703) >>> at >>> >>>java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:6 >>>52) >>> at >>> >>>org.jboss.netty.handler.execution.MemoryAwareThreadPoolExecutor.doUnorder >>>edExecute(MemoryAwareThreadPoolExecutor.java:452) >>> at >>> >>>org.jboss.netty.handler.execution.OrderedMemoryAwareThreadPoolExecutor$Ch >>>ildExecutor.execute(OrderedMemoryAwareThreadPoolExecutor.java:292) >>> at >>> >>>org.jboss.netty.handler.execution.OrderedMemoryAwareThreadPoolExecutor.do >>>Execute(OrderedMemoryAwareThreadPoolExecutor.java:242) >>> at >>> >>>org.jboss.netty.handler.execution.MemoryAwareThreadPoolExecutor.execute(M >>>emoryAwareThreadPoolExecutor.java:437) >>> at >>> >>>org.jboss.netty.handler.execution.ExecutionHandler.handleUpstream(Executi >>>onHandler.java:172) >>> at >>> org.jboss.netty.channel.Channels.fireExceptionCaught(Channels.java:533) >>> at org.jboss.netty.channel.Channels$7.run(Channels.java:507) >>> at >>> >>>org.jboss.netty.channel.socket.ChannelRunnableWrapper.run(ChannelRunnable >>>Wrapper.java:41) >>> at >>> >>>org.jboss.netty.channel.socket.nio.AbstractNioWorker.processEventQueue(Ab >>>stractNioWorker.java:453) >>> at >>> >>>org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorke >>>r.java:330) >>> at >>> org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:35) >>> at >>> >>>java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor >>>.java:886) >>> at >>> >>>java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.jav >>>a: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 >>> [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. >> >> >> >> >> >>-- >>View this message in context: >>http://camel.465427.n5.nabble.com/Load-test-on-camel-netty-tp5737221p57372 >>37.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-tp5737221p5737279.html Sent from the Camel - Users mailing list archive at Nabble.com.
