OK - one last update for now..
This problem is reproducible using the sample ProducerTool and ConsumerTool
that come with AMQ.
Just set the producer to produce 10000 messages and set the consumer to
listen on a different queue (say TOOL.DEFAULT.ROUTED).
Then add the simple camel route:
<route>
<from uri="activemq:TOOL.DEFAULT?cacheLevelName=CACHE_CONSUMER"/>
<to uri="activemq:TOOL.DEFAULT.ROUTED?cacheLevelName=CACHE_CONSUMER"/>
</route>
Some of the stack traces (not all) talk about the JmsTemplates in spring
(but the stack traces are to do with the deadletterchannel. Attached is a
log file from a failing run of AMQ in case there's something subtle in
there... http://www.nabble.com/file/p16175377/activemq.log activemq.log
I'd appreciate any further advice or recommendations.
>From my original post - I was also wondering if I can use an "in memory"
connection to the queue instead of the activemq component. Is it possible
to mix and match the components used to access a queue in this way, so that
my camel routes (which are in the same vm as the machine) could use
vm/seda/direct style components and my remote clients can use activemq
components as they currently do?
Thanks,
-Dominic
DominicTulley wrote:
>
> I've managed to build the latest camel from svn as well now and run the
> two together.
>
> Sending messages at around 100-200/s I see the number of time_Wait sockets
> reach around 2000 pretty quickly (roughly in the time it takes to send
> that many messages). At this point amq starts to report some errors
> (socket closed) and shortly after, when time_wait socket count reaches
> around 3500, things really break, with "address already in use" errors
> from amq.
>
> If we throttle throughput to be less than 2000 messages per two minutes
> then the TIME_WAIT sockets will disappear promptly enough for the system
> not to crumble - but we don't really want to have to put throttling in
> place and 2000 in two minutes doesn't sound like a lot of messages.
>
> Would it be useful to provide a test case at this point? I'm pretty sure
> this problem will be reproducible just by taking the sample producer and
> consumer code from the AMQ distro and changing the config to have a Camel
> route in the middle...
>
> Thanks,
>
> -Dominic
>
>
> DominicTulley wrote:
>>
>> I grabbed the lastest AMQ 5.1 from svn this morning and built that.
>> It includes spring 2.5.1 so I thought that would be another way forward.
>> However, it hasn't helped.
>> I'm currently trying to get a current camel build (the latest revision in
>> svn doesn't build for some reason so I'm working backwards trying to find
>> a current revision that does).
>>
>> -Dominic
>>
>
>
--
View this message in context:
http://www.nabble.com/Getting-lots-of-TIME_WAIT-sockets-tp16119896s22882p16175377.html
Sent from the Camel - Users mailing list archive at Nabble.com.
