Further investigation led to find this one, by setting the log to DEBUG. This
happens when a new message is about to be received:
2007-04-23 18:16:05,966 [ActiveMQ Transport: tcp:///127.0.0.1:54165] DEBUG
org.apache.activemq.broker.region.AbstractRegion - Removing consumer:
ID:magellan-15043-1177347682999-1:9:-1:1
2007-04-23 18:16:05,967 [ActiveMQ Transport: tcp:///127.0.0.1:54165] DEBUG
org.apache.activemq.broker.TransportConnection - Stopping connection:
/127.0.0.1:54165
2007-04-23 18:16:05,968 [ActiveMQ Transport: tcp:///127.0.0.1:54165] DEBUG
org.apache.activemq.broker.TransportConnection - Could not stop transport:
java.lang.ClassCastException:
org.apache.activemq.transport.InactivityMonitor$1
java.lang.ClassCastException:
org.apache.activemq.transport.InactivityMonitor$1
at
edu.emory.mathcs.backport.java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.compareTo(ScheduledThreadPoolExecutor.java:189)
at
edu.emory.mathcs.backport.java.util.PriorityQueue.remove(PriorityQueue.java:507)
at
edu.emory.mathcs.backport.java.util.concurrent.DelayQueue.remove(DelayQueue.java:379)
...
2007-04-23 18:16:05,969 [ActiveMQ Transport Server: tcp://localhost:6002]
DEBUG org.apache.activemq.transport.WireFormatNegotiator - Sending:
WireFormatInfo { version=2, properties={TightEncodingEnabled=true,
CacheSize=1024, TcpNoDelayEnabled=true, SizePrefixDisabled=false,
StackTraceEnabled=true, MaxInactivityDuration=30000, CacheEnabled=true},
magic=[A,c,t,i,v,e,M,Q]}
2007-04-23 18:16:05,970 [ActiveMQ Transport: tcp:///127.0.0.1:54166] DEBUG
org.apache.activemq.transport.WireFormatNegotiator - Received WireFormat:
WireFormatInfo { version=2, properties={TightEncodingEnabled=true,
CacheSize=1024, TcpNoDelayEnabled=true, SizePrefixDisabled=false,
StackTraceEnabled=true, MaxInactivityDuration=30000, CacheEnabled=true},
magic=[A,c,t,i,v,e,M,Q]}
2007-04-23 18:16:05,970 [ActiveMQ Transport: tcp:///127.0.0.1:54166] DEBUG
org.apache.activemq.transport.WireFormatNegotiator - tcp:///127.0.0.1:54166
before negotiation: OpenWireFormat{version=2, cacheEnabled=false,
stackTraceEnabled=false, tightEncodingEnabled=false,
sizePrefixDisabled=false}
2007-04-23 18:16:05,970 [ActiveMQ Transport: tcp:///127.0.0.1:54166] DEBUG
org.apache.activemq.transport.WireFormatNegotiator - tcp:///127.0.0.1:54166
after negotiation: OpenWireFormat{version=2, cacheEnabled=true,
stackTraceEnabled=true, tightEncodingEnabled=true, sizePrefixDisabled=false}
2007-04-23 18:16:05,970 [ActiveMQ Transport: tcp:///127.0.0.1:54166] DEBUG
org.apache.activemq.broker.TransportConnection - Setting up new connection:
[EMAIL PROTECTED]
2007-04-23 18:16:06,011 [ActiveMQ Transport: tcp:///127.0.0.1:54166] DEBUG
org.apache.activemq.broker.region.AbstractRegion - Adding consumer:
ID:magellan-15043-1177347682999-1:10:-1:1
So, for some reason, the old connection to the server cannot be closed
because of that ClassCastException (might this be due to an
InactivityMonitor instance being transferred with the message, and then
being tried to be deserialized with a different classloader, as the producer
and consumer are in 2 different webapps inside the same container?), and
then another connection is created. Eventually, no more connections will be
available.
Why is the connection being tried to be closed in the first place, instead
of being reused? Can this be avoided by setting
wireFormat.maxInactivityDuration=0 in the broker? What would be the impact
of doing this?
Thanks!
Alex.
James.Strachan wrote:
>
> On 4/17/07, Ale Sarco <[EMAIL PROTECTED]> wrote:
>>
>> Hi James,
>>
>> Using ActiveMQ 4.1.1 with Spring I experienced this "unable to create new
>> native thread" exception in one of my production servers last night. The
>> thing is that server does not has a large messaging traffic, it just send
>> 2
>> or 3 messages every couple of minutes to another webapp running in the
>> same
>> Tomcat, and this is only for 2 hours a day, and there were plenty of
>> memory
>> available on the heap for that VM.
>> I agree that is probably related to the file descriptors that you
>> mentioned,
>> because when I tried to log in to that server via SSH I got an error
>> about
>> something like "insufficient resources". Only when I restarted the webapp
>> I
>> was able to login again.
>> Now, what file descriptors is this about? Is a (logical) file created
>> somewhere every time a message is sent? If so, how do I avoid this
>> problem,
>> I guess they should be reused or something?
>
> File descriptors are often used for various things in the OS; files,
> sockets, sometimes threads etc. ActiveMQ does not create a file or
> socket per message :).
>
> BTW how do things look in jconsole; do you have lots of connections on
> your broker? I wonder if you are not closing connections after they
> have been used (you are really meant to only use a small number of
> connections and lots of sessions).
> http://activemq.apache.org/how-do-i-use-jms-efficiently.html
>
> Just up the file descriptors setting on your OS and it should fix this
>
>
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
>
--
View this message in context:
http://www.nabble.com/3.1-broker-OutofMemoryError-%3A-unable-to-create-new-native-thread-tf3527977s2354.html#a10145361
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
