[activemq-user] java.lang.OutOfMemoryError: unable to create new native thread

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[activemq-user] java.lang.OutOfMemoryError: unable to create new native thread

beyond005
I wrote a test program to send and receive message. It work at the
begin. But client block at No. 5674 sending message. And I found the
next exception in serverside. What's the problem? Is it the memory
leak? I use ActiveMQ3.2+Jencks+JmsTemplate to write the test.

Work accepted: javax.resource.spi.work.WorkEvent[source=org.apach
e.geronimo.connector.work.GeronimoWorkManager@4a6cbf]
Exception in thread "TcpTransportChannel:
Socket[addr=localhost:127.0.0.1,port=61616,localport=3310]"
java.lang.OutOfMemoryError: unable to create new native thread
        at java.lang.Thread.start0(Native Method)
        at java.lang.Thread.start(Unknown Source)
        at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.addThread(Unknown
Source)
        at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.execute(Unknown
Source)
        at org.apache.geronimo.connector.work.pool.WorkExecutorPoolImpl.execute(WorkExecutorPoolImpl.java:79)
        at org.apache.geronimo.connector.work.pool.ScheduleWorkExecutor.doExecute(ScheduleWorkExecutor.java:35)
        at org.apache.geronimo.connector.work.GeronimoWorkManager.executeWork(GeronimoWorkManager.java:236)
        at org.apache.geronimo.connector.work.GeronimoWorkManager.scheduleWork(GeronimoWorkManager.java:222)
        at org.activemq.ra.ServerSessionImpl.start(ServerSessionImpl.java:129)
       at org.activemq.ActiveMQConnectionConsumer.dispatchToSession(ActiveMQConnectionConsumer.java:169)
        at org.activemq.ActiveMQConnectionConsumer.dispatch(ActiveMQConnectionConsumer.java:114)
        at org.activemq.ActiveMQConnection.consume(ActiveMQConnection.java:1056)
        at org.activemq.transport.TransportChannelSupport.doConsumePacket(TransportChannelSupport.java:374)
        at org.activemq.transport.TransportChannelSupport.doConsumePacket(TransportChannelSupport.java:368)
        at org.activemq.transport.tcp.TcpTransportChannel.run(TcpTransportChannel.java:315)
        at java.lang.Thread.run(Unknown Source)
Reply | Threaded
Open this post in threaded view
|

Re: [activemq-user] java.lang.OutOfMemoryError: unable to create new native thread

James Strachan-2
FWIW we did fix a memory leak recently in 3.2 which might have  
something to do with it
http://jira.logicblaze.com/jira/browse/AMQ-414

Either that or maybe there just wasn't enough heap for the JVM? Could  
you try increasing the heap size some and seeing if it just delays  
the problem or if you really do have a leak?

You could try using the 3.2.1-SNAPSHOT version which could well fix  
this issue.
http://dist.codehaus.org/activemq/distributions/

On 23 Nov 2005, at 01:52, Beyond005 wrote:

> I wrote a test program to send and receive message. It work at the
> begin. But client block at No. 5674 sending message. And I found the
> next exception in serverside. What's the problem? Is it the memory
> leak? I use ActiveMQ3.2+Jencks+JmsTemplate to write the test.
>
> Work accepted: javax.resource.spi.work.WorkEvent[source=org.apach
> e.geronimo.connector.work.GeronimoWorkManager@4a6cbf]
> Exception in thread "TcpTransportChannel:
> Socket[addr=localhost:127.0.0.1,port=61616,localport=3310]"
> java.lang.OutOfMemoryError: unable to create new native thread
>         at java.lang.Thread.start0(Native Method)
>         at java.lang.Thread.start(Unknown Source)
>         at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.addThread
> (Unknown
> Source)
>         at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.execute
> (Unknown
> Source)
>         at  
> org.apache.geronimo.connector.work.pool.WorkExecutorPoolImpl.execute
> (WorkExecutorPoolImpl.java:79)
>         at  
> org.apache.geronimo.connector.work.pool.ScheduleWorkExecutor.doExecute
> (ScheduleWorkExecutor.java:35)
>         at  
> org.apache.geronimo.connector.work.GeronimoWorkManager.executeWork
> (GeronimoWorkManager.java:236)
>         at  
> org.apache.geronimo.connector.work.GeronimoWorkManager.scheduleWork
> (GeronimoWorkManager.java:222)
>         at org.activemq.ra.ServerSessionImpl.start
> (ServerSessionImpl.java:129)
>        at org.activemq.ActiveMQConnectionConsumer.dispatchToSession
> (ActiveMQConnectionConsumer.java:169)
>         at org.activemq.ActiveMQConnectionConsumer.dispatch
> (ActiveMQConnectionConsumer.java:114)
>         at org.activemq.ActiveMQConnection.consume
> (ActiveMQConnection.java:1056)
>         at  
> org.activemq.transport.TransportChannelSupport.doConsumePacket
> (TransportChannelSupport.java:374)
>         at  
> org.activemq.transport.TransportChannelSupport.doConsumePacket
> (TransportChannelSupport.java:368)
>         at org.activemq.transport.tcp.TcpTransportChannel.run
> (TcpTransportChannel.java:315)
>         at java.lang.Thread.run(Unknown Source)


James
-------
http://radio.weblogs.com/0112098/

Reply | Threaded
Open this post in threaded view
|

Re: [activemq-user] java.lang.OutOfMemoryError: unable to create new native thread

kevan
On 11/23/05, James Strachan <[hidden email]> wrote:

>
> FWIW we did fix a memory leak recently in 3.2 which might have
> something to do with it
> http://jira.logicblaze.com/jira/browse/AMQ-414
>
> Either that or maybe there just wasn't enough heap for the JVM? Could
> you try increasing the heap size some and seeing if it just delays
> the problem or if you really do have a leak?
>
> You could try using the 3.2.1-SNAPSHOT version which could well fix
> this issue.
> http://dist.codehaus.org/activemq/distributions/


Good point. If you are reusing a ManagedConnection many times or creating
many short-lived Sessions on a ManagedConnection, then you are probably
encountering the above problem.

James,
At the time I generated my patch, I took a look at the 4.0 codebase. It
seemed that this would also be a problem there...

--kevan

On 23 Nov 2005, at 01:52, Beyond005 wrote:

> > I wrote a test program to send and receive message. It work at the
> > begin. But client block at No. 5674 sending message. And I found the
> > next exception in serverside. What's the problem? Is it the memory
> > leak? I use ActiveMQ3.2+Jencks+JmsTemplate to write the test.
> >
> > Work accepted: javax.resource.spi.work.WorkEvent[source=org.apach
> > e.geronimo.connector.work.GeronimoWorkManager@4a6cbf]
> > Exception in thread "TcpTransportChannel:
> > Socket[addr=localhost: 127.0.0.1,port=61616,localport=3310]"
> > java.lang.OutOfMemoryError: unable to create new native thread
> >         at java.lang.Thread.start0(Native Method)
> >         at java.lang.Thread.start(Unknown Source)
> >         at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.addThread
> > (Unknown
> > Source)
> >         at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.execute
> > (Unknown
> > Source)
> >         at
> > org.apache.geronimo.connector.work.pool.WorkExecutorPoolImpl.execute
> > (WorkExecutorPoolImpl.java:79)
> >         at
> > org.apache.geronimo.connector.work.pool.ScheduleWorkExecutor.doExecute
> > (ScheduleWorkExecutor.java:35)
> >         at
> > org.apache.geronimo.connector.work.GeronimoWorkManager.executeWork
> > (GeronimoWorkManager.java:236)
> >         at
> > org.apache.geronimo.connector.work.GeronimoWorkManager.scheduleWork
> > (GeronimoWorkManager.java:222)
> >         at org.activemq.ra.ServerSessionImpl.start
> > (ServerSessionImpl.java:129)
> >        at org.activemq.ActiveMQConnectionConsumer.dispatchToSession
> > ( ActiveMQConnectionConsumer.java:169)
> >         at org.activemq.ActiveMQConnectionConsumer.dispatch
> > (ActiveMQConnectionConsumer.java:114)
> >         at org.activemq.ActiveMQConnection.consume
> > (ActiveMQConnection.java :1056)
> >         at
> > org.activemq.transport.TransportChannelSupport.doConsumePacket
> > (TransportChannelSupport.java:374)
> >         at
> > org.activemq.transport.TransportChannelSupport.doConsumePacket
> > (TransportChannelSupport.java:368)
> >         at org.activemq.transport.tcp.TcpTransportChannel.run
> > (TcpTransportChannel.java:315)
> >         at java.lang.Thread.run(Unknown Source)
>
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [activemq-user] java.lang.OutOfMemoryError: unable to create new native thread

James Strachan-2

On 23 Nov 2005, at 14:36, Kevan Miller wrote:

> On 11/23/05, James Strachan <[hidden email]> wrote:
>>
>> FWIW we did fix a memory leak recently in 3.2 which might have
>> something to do with it
>> http://jira.logicblaze.com/jira/browse/AMQ-414
>>
>> Either that or maybe there just wasn't enough heap for the JVM? Could
>> you try increasing the heap size some and seeing if it just delays
>> the problem or if you really do have a leak?
>>
>> You could try using the 3.2.1-SNAPSHOT version which could well fix
>> this issue.
>> http://dist.codehaus.org/activemq/distributions/
>
>
> Good point. If you are reusing a ManagedConnection many times or  
> creating
> many short-lived Sessions on a ManagedConnection, then you are  
> probably
> encountering the above problem.
>
> James,
> At the time I generated my patch, I took a look at the 4.0  
> codebase. It
> seemed that this would also be a problem there...

Really? Fancy submitting a patch :) I took a look at 4.x and saw that  
the ActiveMQSession wasn't registered with the TransactionContext so  
didn't think the problem existed in 4.x though I could have been  
mistaken.

James
-------
http://radio.weblogs.com/0112098/

Reply | Threaded
Open this post in threaded view
|

Re: [activemq-user] java.lang.OutOfMemoryError: unable to create new native thread

beyond005
I have increased the heap in JVM but it doesn't work. And when I use
YourKit to profiler the application. It shown that the
JmsSessionDispatcher thread increase to a big number and cause the
application hang, just like what AMQ-393 described. I also modify the
source code of ActiveMQ3.2 like what AMQ-393 do and rebuild the
core-jar package. It still can't work. The situation still like what I
have mentioned before, the JmsSessionDespatcher thread still increase.
Should other code errors I must fix?

2005/11/23, James Strachan <[hidden email]>:

>
> On 23 Nov 2005, at 14:36, Kevan Miller wrote:
>
> > On 11/23/05, James Strachan <[hidden email]> wrote:
> >>
> >> FWIW we did fix a memory leak recently in 3.2 which might have
> >> something to do with it
> >> http://jira.logicblaze.com/jira/browse/AMQ-414
> >>
> >> Either that or maybe there just wasn't enough heap for the JVM? Could
> >> you try increasing the heap size some and seeing if it just delays
> >> the problem or if you really do have a leak?
> >>
> >> You could try using the 3.2.1-SNAPSHOT version which could well fix
> >> this issue.
> >> http://dist.codehaus.org/activemq/distributions/
> >
> >
> > Good point. If you are reusing a ManagedConnection many times or
> > creating
> > many short-lived Sessions on a ManagedConnection, then you are
> > probably
> > encountering the above problem.
> >
> > James,
> > At the time I generated my patch, I took a look at the 4.0
> > codebase. It
> > seemed that this would also be a problem there...
>
> Really? Fancy submitting a patch :) I took a look at 4.x and saw that
> the ActiveMQSession wasn't registered with the TransactionContext so
> didn't think the problem existed in 4.x though I could have been
> mistaken.
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
>
Reply | Threaded
Open this post in threaded view
|

[activemq-user] cleaing up lapsed client connections

jmatthewpryor
In reply to this post by kevan
When a client fails/dies/quits my server side keeps reporting WARNINGs
like this:

javax.jms.InvalidDestinationException: Destination
TemporaryQueue-{TD{ID:craken-1190-1132803090546-1:0}TD}ID:craken-1190-1132803090546-6:0
is no longer valid because the client ID:craken-1190-1132803090546-1:0
no longer exists
    at
org.activemq.broker.impl.BrokerContainerImpl.checkTempDestinationExistance(BrokerContainerImpl.java:495)
    at
org.activemq.broker.impl.BrokerContainerImpl.sendMessage(BrokerContainerImpl.java:461)
    at
org.activemq.broker.impl.BrokerConnectorImpl.sendMessage(BrokerConnectorImpl.java:281)
    at
org.activemq.broker.impl.BrokerClientImpl.consumeActiveMQMessage(BrokerClientImpl.java:735)
    at
org.activemq.broker.impl.BrokerClientImpl.consume(BrokerClientImpl.java:336)
    at
org.activemq.transport.TransportChannelSupport.doConsumePacket(TransportChannelSupport.java:374)
    at
org.activemq.transport.TransportChannelSupport.doConsumePacket(TransportChannelSupport.java:368)
    at
org.activemq.transport.tcp.TcpTransportChannel.run(TcpTransportChannel.java:315)
    at java.lang.Thread.run(Unknown Source)

What settings determine how long a temporary queue will hang around for?

Thanks,
Matthew
Reply | Threaded
Open this post in threaded view
|

Re: [activemq-user] cleaing up lapsed client connections

James Strachan-2
On 24 Nov 2005, at 03:53, J. Matthew Pryor wrote:

> When a client fails/dies/quits my server side keeps reporting  
> WARNINGs like this:
>
> javax.jms.InvalidDestinationException: Destination TemporaryQueue-
> {TD{ID:craken-1190-1132803090546-1:0}TD}
> ID:craken-1190-1132803090546-6:0 is no longer valid because the  
> client ID:craken-1190-1132803090546-1:0 no longer exists
>    at  
> org.activemq.broker.impl.BrokerContainerImpl.checkTempDestinationExist
> ance(BrokerContainerImpl.java:495)
>    at org.activemq.broker.impl.BrokerContainerImpl.sendMessage
> (BrokerContainerImpl.java:461)
>    at org.activemq.broker.impl.BrokerConnectorImpl.sendMessage
> (BrokerConnectorImpl.java:281)
>    at  
> org.activemq.broker.impl.BrokerClientImpl.consumeActiveMQMessage
> (BrokerClientImpl.java:735)
>    at org.activemq.broker.impl.BrokerClientImpl.consume
> (BrokerClientImpl.java:336)
>    at org.activemq.transport.TransportChannelSupport.doConsumePacket
> (TransportChannelSupport.java:374)
>    at org.activemq.transport.TransportChannelSupport.doConsumePacket
> (TransportChannelSupport.java:368)
>    at org.activemq.transport.tcp.TcpTransportChannel.run
> (TcpTransportChannel.java:315)
>    at java.lang.Thread.run(Unknown Source)
>
> What settings determine how long a temporary queue will hang around  
> for?

Temporary queues last as long as the connection which created it.


James
-------
http://radio.weblogs.com/0112098/

Reply | Threaded
Open this post in threaded view
|

Re: [activemq-user] cleaing up lapsed client connections

chirino
In reply to this post by jmatthewpryor

A temporary queue only lives as long as the client which created it  
remains connected to the server.  This sounds like a normal error,  
perhaps the log verbosity should be reduced to debug.

Regards,
Hiram

On Nov 23, 2005, at 10:53 PM, J. Matthew Pryor wrote:

> When a client fails/dies/quits my server side keeps reporting  
> WARNINGs like this:
>
> javax.jms.InvalidDestinationException: Destination TemporaryQueue-
> {TD{ID:craken-1190-1132803090546-1:0}TD}
> ID:craken-1190-1132803090546-6:0 is no longer valid because the  
> client ID:craken-1190-1132803090546-1:0 no longer exists
>    at  
> org.activemq.broker.impl.BrokerContainerImpl.checkTempDestinationExist
> ance(BrokerContainerImpl.java:495)
>    at org.activemq.broker.impl.BrokerContainerImpl.sendMessage
> (BrokerContainerImpl.java:461)
>    at org.activemq.broker.impl.BrokerConnectorImpl.sendMessage
> (BrokerConnectorImpl.java:281)
>    at  
> org.activemq.broker.impl.BrokerClientImpl.consumeActiveMQMessage
> (BrokerClientImpl.java:735)
>    at org.activemq.broker.impl.BrokerClientImpl.consume
> (BrokerClientImpl.java:336)
>    at org.activemq.transport.TransportChannelSupport.doConsumePacket
> (TransportChannelSupport.java:374)
>    at org.activemq.transport.TransportChannelSupport.doConsumePacket
> (TransportChannelSupport.java:368)
>    at org.activemq.transport.tcp.TcpTransportChannel.run
> (TcpTransportChannel.java:315)
>    at java.lang.Thread.run(Unknown Source)
>
> What settings determine how long a temporary queue will hang around  
> for?
>
> Thanks,
> Matthew
>

Reply | Threaded
Open this post in threaded view
|

Re: [activemq-user] cleaing up lapsed client connections

jmatthewpryor
But the client VM has shutdown, that is why I find the error troubling,
shouldn't the temp queue expire?

Thanks,
Matthew

Hiram Chirino wrote:

>
> A temporary queue only lives as long as the client which created it
> remains connected to the server.  This sounds like a normal error,
> perhaps the log verbosity should be reduced to debug.
>
> Regards,
> Hiram
>
> On Nov 23, 2005, at 10:53 PM, J. Matthew Pryor wrote:
>
>> When a client fails/dies/quits my server side keeps reporting
>> WARNINGs like this:
>>
>> javax.jms.InvalidDestinationException: Destination
>> TemporaryQueue-{TD{ID:craken-1190-1132803090546-1:0}TD}ID:craken-1190-1132803090546-6:0
>> is no longer valid because the client
>> ID:craken-1190-1132803090546-1:0 no longer exists
>>    at
>> org.activemq.broker.impl.BrokerContainerImpl.checkTempDestinationExistance(BrokerContainerImpl.java:495)
>>
>>    at
>> org.activemq.broker.impl.BrokerContainerImpl.sendMessage(BrokerContainerImpl.java:461)
>>
>>    at
>> org.activemq.broker.impl.BrokerConnectorImpl.sendMessage(BrokerConnectorImpl.java:281)
>>
>>    at
>> org.activemq.broker.impl.BrokerClientImpl.consumeActiveMQMessage(BrokerClientImpl.java:735)
>>
>>    at
>> org.activemq.broker.impl.BrokerClientImpl.consume(BrokerClientImpl.java:336)
>>
>>    at
>> org.activemq.transport.TransportChannelSupport.doConsumePacket(TransportChannelSupport.java:374)
>>
>>    at
>> org.activemq.transport.TransportChannelSupport.doConsumePacket(TransportChannelSupport.java:368)
>>
>>    at
>> org.activemq.transport.tcp.TcpTransportChannel.run(TcpTransportChannel.java:315)
>>
>>    at java.lang.Thread.run(Unknown Source)
>>
>> What settings determine how long a temporary queue will hang around for?
>>
>> Thanks,
>> Matthew
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: [activemq-user] cleaing up lapsed client connections

chirino
Yes, that what the error is reporting, that the queue has expired.

But some other client is still trying to send that expired queue a  
message.

Regards,
Hiram

On Nov 24, 2005, at 9:04 AM, J. Matthew Pryor wrote:

> But the client VM has shutdown, that is why I find the error  
> troubling, shouldn't the temp queue expire?
>
> Thanks,
> Matthew
>
> Hiram Chirino wrote:
>
>>
>> A temporary queue only lives as long as the client which created  
>> it remains connected to the server.  This sounds like a normal  
>> error, perhaps the log verbosity should be reduced to debug.
>>
>> Regards,
>> Hiram
>>
>> On Nov 23, 2005, at 10:53 PM, J. Matthew Pryor wrote:
>>
>>
>>> When a client fails/dies/quits my server side keeps reporting  
>>> WARNINGs like this:
>>>
>>> javax.jms.InvalidDestinationException: Destination TemporaryQueue-
>>> {TD{ID:craken-1190-1132803090546-1:0}TD}
>>> ID:craken-1190-1132803090546-6:0 is no longer valid because the  
>>> client ID:craken-1190-1132803090546-1:0 no longer exists
>>>    at  
>>> org.activemq.broker.impl.BrokerContainerImpl.checkTempDestinationExi
>>> stance(BrokerContainerImpl.java:495)
>>>    at org.activemq.broker.impl.BrokerContainerImpl.sendMessage
>>> (BrokerContainerImpl.java:461)
>>>    at org.activemq.broker.impl.BrokerConnectorImpl.sendMessage
>>> (BrokerConnectorImpl.java:281)
>>>    at  
>>> org.activemq.broker.impl.BrokerClientImpl.consumeActiveMQMessage
>>> (BrokerClientImpl.java:735)
>>>    at org.activemq.broker.impl.BrokerClientImpl.consume
>>> (BrokerClientImpl.java:336)
>>>    at  
>>> org.activemq.transport.TransportChannelSupport.doConsumePacket
>>> (TransportChannelSupport.java:374)
>>>    at  
>>> org.activemq.transport.TransportChannelSupport.doConsumePacket
>>> (TransportChannelSupport.java:368)
>>>    at org.activemq.transport.tcp.TcpTransportChannel.run
>>> (TcpTransportChannel.java:315)
>>>    at java.lang.Thread.run(Unknown Source)
>>>
>>> What settings determine how long a temporary queue will hang  
>>> around for?
>>>
>>> Thanks,
>>> Matthew
>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: [activemq-user] cleaing up lapsed client connections

jmatthewpryor
In reply to this post by James Strachan-2
Perhaps this is a Lingo specific thing then, but my logs files are
getting filled up with WARNings like this one

2005-11-28 20:46:50,407 [TcpTransportChannel: 1e6743e[Unknown 0x0:0x0:
Socket[addr=/144.135.37.14,port=3211,localport=2221]]] WARN  
org.activemq.broker.impl.BrokerClientImpl - caught exception consuming
packet: ACTIVEMQ_TEXT_MESSAGE: id = 0 ActiveMQMessage{ , jmsMessageID =
null, bodyAsBytes = org.activemq.io.util.ByteArray@eb68d8,
readOnlyMessage = false, jmsClientID =
'ID:BEEF292-3207-1133166798591-19:0' , jmsCorrelationID = '5' ,
jmsDestination =
TemporaryQueue-{TD{ID:stonker-2566-1133166873789-1:0}TD}ID:stonker-2566-1133166873789-6:0,
jmsReplyTo = null, jmsDeliveryMode = 1, jmsRedelivered = false, jmsType
= 'null' , jmsExpiration = 1133176640377, jmsPriority = 5, jmsTimestamp
= 1133176610377, properties = null, readOnlyProperties = false,
entryBrokerName = 'ID:BEEF292-3207-1133166798591-0:0' , entryClusterName
= 'default' , consumerNos = null, transactionId = 'null' , xaTransacted
= false, consumerIdentifer = 'null' , messageConsumed = false,
transientConsumed = false, sequenceNumber = 12200, deliveryCount = 1,
dispatchedFromDLQ = false, messageAcknowledge = null, jmsMessageIdentity
= null, producerKey = ID:BEEF292-3207-1133166798591-25: }, text =
<invoke methodName="notifyDataDiscarded">
  <metadata oneWay="true">
    <remoteParameters>
      <boolean>false</boolean>
      <boolean>false</boolean>
    </remoteParameters>
  </metadata>
  <parameterTypes>
    <java-class>au.com.observant.device.organization.ZoneFacade</java-class>
    <java-class>au.com.observant.util.ByteBuffer</java-class>
  </parameterTypes>
  <arguments>
{SNIP MASSIVE XML MESSAGE}
javax.jms.InvalidDestinationException: Destination
TemporaryQueue-{TD{ID:stonker-2566-1133166873789-1:0}TD}ID:stonker-2566-1133166873789-6:0
is no longer valid because the client ID:stonker-2566-1133166873789-1:0
no longer exists
    at
org.activemq.broker.impl.BrokerContainerImpl.checkTempDestinationExistance(BrokerContainerImpl.java:495)
    at
org.activemq.broker.impl.BrokerContainerImpl.sendMessage(BrokerContainerImpl.java:461)
    at
org.activemq.broker.impl.BrokerConnectorImpl.sendMessage(BrokerConnectorImpl.java:281)
    at
org.activemq.broker.impl.BrokerClientImpl.consumeActiveMQMessage(BrokerClientImpl.java:735)
    at
org.activemq.broker.impl.BrokerClientImpl.consume(BrokerClientImpl.java:336)
    at
org.activemq.transport.TransportChannelSupport.doConsumePacket(TransportChannelSupport.java:374)
    at
org.activemq.transport.TransportChannelSupport.doConsumePacket(TransportChannelSupport.java:368)
    at
org.activemq.transport.tcp.TcpTransportChannel.run(TcpTransportChannel.java:315)
    at java.lang.Thread.run(Unknown Source)

It is related to when remote references are left dangling by a
disappearing client.

How can I detect this situation & resolve it. Since the log entries are
at WARN level, the logs fill up in no time flat & I don't want to miss
other "important" WARNings

Thanks for any pointers

Matthew

James Strachan wrote:

> On 24 Nov 2005, at 03:53, J. Matthew Pryor wrote:
>> When a client fails/dies/quits my server side keeps reporting
>> WARNINGs like this:
>>
>> javax.jms.InvalidDestinationException: Destination
>> TemporaryQueue-{TD{ID:craken-1190-1132803090546-1:0}TD}ID:craken-1190-1132803090546-6:0
>> is no longer valid because the client
>> ID:craken-1190-1132803090546-1:0 no longer exists
>>    at
>> org.activemq.broker.impl.BrokerContainerImpl.checkTempDestinationExistance(BrokerContainerImpl.java:495)
>>
>>    at
>> org.activemq.broker.impl.BrokerContainerImpl.sendMessage(BrokerContainerImpl.java:461)
>>
>>    at
>> org.activemq.broker.impl.BrokerConnectorImpl.sendMessage(BrokerConnectorImpl.java:281)
>>
>>    at
>> org.activemq.broker.impl.BrokerClientImpl.consumeActiveMQMessage(BrokerClientImpl.java:735)
>>
>>    at
>> org.activemq.broker.impl.BrokerClientImpl.consume(BrokerClientImpl.java:336)
>>
>>    at
>> org.activemq.transport.TransportChannelSupport.doConsumePacket(TransportChannelSupport.java:374)
>>
>>    at
>> org.activemq.transport.TransportChannelSupport.doConsumePacket(TransportChannelSupport.java:368)
>>
>>    at
>> org.activemq.transport.tcp.TcpTransportChannel.run(TcpTransportChannel.java:315)
>>
>>    at java.lang.Thread.run(Unknown Source)
>>
>> What settings determine how long a temporary queue will hang around for?
>
> Temporary queues last as long as the connection which created it.
>
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
Reply | Threaded
Open this post in threaded view
|

Re: [activemq-user] cleaing up lapsed client connections

jmatthewpryor
Having taken a good look through the code, this is mostly (but not
completely) a Lingo issue and I can't see how this can be automatically
achieved.

The proxy that is created for the "remote parameter" doesn't have any
way to navigate back to the JmsProxyFactoryBean that created it in order
that it might check the status of the destination it is associated with.

The only simple (ish) solution I can think of is to add a 'ping' method
to my remote listeners and have the server side intermittently 'ping'
all listeners to see they are still alive.

Can anyone else suggest a way to detect dead (deaf) remote listeners?

Thanks,
Matthew

J. Matthew Pryor wrote:

> Perhaps this is a Lingo specific thing then, but my logs files are
> getting filled up with WARNings like this one
>
> 2005-11-28 20:46:50,407 [TcpTransportChannel: 1e6743e[Unknown 0x0:0x0:
> Socket[addr=/144.135.37.14,port=3211,localport=2221]]] WARN  
> org.activemq.broker.impl.BrokerClientImpl - caught exception consuming
> packet: ACTIVEMQ_TEXT_MESSAGE: id = 0 ActiveMQMessage{ , jmsMessageID
> = null, bodyAsBytes = org.activemq.io.util.ByteArray@eb68d8,
> readOnlyMessage = false, jmsClientID =
> 'ID:BEEF292-3207-1133166798591-19:0' , jmsCorrelationID = '5' ,
> jmsDestination =
> TemporaryQueue-{TD{ID:stonker-2566-1133166873789-1:0}TD}ID:stonker-2566-1133166873789-6:0,
> jmsReplyTo = null, jmsDeliveryMode = 1, jmsRedelivered = false,
> jmsType = 'null' , jmsExpiration = 1133176640377, jmsPriority = 5,
> jmsTimestamp = 1133176610377, properties = null, readOnlyProperties =
> false, entryBrokerName = 'ID:BEEF292-3207-1133166798591-0:0' ,
> entryClusterName = 'default' , consumerNos = null, transactionId =
> 'null' , xaTransacted = false, consumerIdentifer = 'null' ,
> messageConsumed = false, transientConsumed = false, sequenceNumber =
> 12200, deliveryCount = 1, dispatchedFromDLQ = false,
> messageAcknowledge = null, jmsMessageIdentity = null, producerKey =
> ID:BEEF292-3207-1133166798591-25: }, text = <invoke
> methodName="notifyDataDiscarded">
>  <metadata oneWay="true">
>    <remoteParameters>
>      <boolean>false</boolean>
>      <boolean>false</boolean>
>    </remoteParameters>
>  </metadata>
>  <parameterTypes>
>    
> <java-class>au.com.observant.device.organization.ZoneFacade</java-class>
>    <java-class>au.com.observant.util.ByteBuffer</java-class>
>  </parameterTypes>
>  <arguments>
> {SNIP MASSIVE XML MESSAGE}
> javax.jms.InvalidDestinationException: Destination
> TemporaryQueue-{TD{ID:stonker-2566-1133166873789-1:0}TD}ID:stonker-2566-1133166873789-6:0
> is no longer valid because the client
> ID:stonker-2566-1133166873789-1:0 no longer exists
>    at
> org.activemq.broker.impl.BrokerContainerImpl.checkTempDestinationExistance(BrokerContainerImpl.java:495)
>
>    at
> org.activemq.broker.impl.BrokerContainerImpl.sendMessage(BrokerContainerImpl.java:461)
>
>    at
> org.activemq.broker.impl.BrokerConnectorImpl.sendMessage(BrokerConnectorImpl.java:281)
>
>    at
> org.activemq.broker.impl.BrokerClientImpl.consumeActiveMQMessage(BrokerClientImpl.java:735)
>
>    at
> org.activemq.broker.impl.BrokerClientImpl.consume(BrokerClientImpl.java:336)
>
>    at
> org.activemq.transport.TransportChannelSupport.doConsumePacket(TransportChannelSupport.java:374)
>
>    at
> org.activemq.transport.TransportChannelSupport.doConsumePacket(TransportChannelSupport.java:368)
>
>    at
> org.activemq.transport.tcp.TcpTransportChannel.run(TcpTransportChannel.java:315)
>
>    at java.lang.Thread.run(Unknown Source)
>
> It is related to when remote references are left dangling by a
> disappearing client.
>
> How can I detect this situation & resolve it. Since the log entries
> are at WARN level, the logs fill up in no time flat & I don't want to
> miss other "important" WARNings
>
> Thanks for any pointers
>
> Matthew
>
> James Strachan wrote:
>> On 24 Nov 2005, at 03:53, J. Matthew Pryor wrote:
>>> When a client fails/dies/quits my server side keeps reporting
>>> WARNINGs like this:
>>>
>>> javax.jms.InvalidDestinationException: Destination
>>> TemporaryQueue-{TD{ID:craken-1190-1132803090546-1:0}TD}ID:craken-1190-1132803090546-6:0
>>> is no longer valid because the client
>>> ID:craken-1190-1132803090546-1:0 no longer exists
>>>    at
>>> org.activemq.broker.impl.BrokerContainerImpl.checkTempDestinationExistance(BrokerContainerImpl.java:495)
>>>
>>>    at
>>> org.activemq.broker.impl.BrokerContainerImpl.sendMessage(BrokerContainerImpl.java:461)
>>>
>>>    at
>>> org.activemq.broker.impl.BrokerConnectorImpl.sendMessage(BrokerConnectorImpl.java:281)
>>>
>>>    at
>>> org.activemq.broker.impl.BrokerClientImpl.consumeActiveMQMessage(BrokerClientImpl.java:735)
>>>
>>>    at
>>> org.activemq.broker.impl.BrokerClientImpl.consume(BrokerClientImpl.java:336)
>>>
>>>    at
>>> org.activemq.transport.TransportChannelSupport.doConsumePacket(TransportChannelSupport.java:374)
>>>
>>>    at
>>> org.activemq.transport.TransportChannelSupport.doConsumePacket(TransportChannelSupport.java:368)
>>>
>>>    at
>>> org.activemq.transport.tcp.TcpTransportChannel.run(TcpTransportChannel.java:315)
>>>
>>>    at java.lang.Thread.run(Unknown Source)
>>>
>>> What settings determine how long a temporary queue will hang around
>>> for?
>>
>> Temporary queues last as long as the connection which created it.
>>
>>
>> James
>> -------
>> http://radio.weblogs.com/0112098/
>>
Reply | Threaded
Open this post in threaded view
|

Re: [activemq-user] java.lang.OutOfMemoryError: unable to create new native thread

kevan
In reply to this post by James Strachan-2
On 11/23/05, James Strachan <[hidden email]> wrote:

>
>
> On 23 Nov 2005, at 14:36, Kevan Miller wrote:
>
> > On 11/23/05, James Strachan <[hidden email]> wrote:
> >>
> >> FWIW we did fix a memory leak recently in 3.2 which might have
> >> something to do with it
> >> http://jira.logicblaze.com/jira/browse/AMQ-414
> >>
> >> Either that or maybe there just wasn't enough heap for the JVM? Could
> >> you try increasing the heap size some and seeing if it just delays
> >> the problem or if you really do have a leak?
> >>
> >> You could try using the 3.2.1-SNAPSHOT version which could well fix
> >> this issue.
> >> http://dist.codehaus.org/activemq/distributions/
> >
> >
> > Good point. If you are reusing a ManagedConnection many times or
> > creating
> > many short-lived Sessions on a ManagedConnection, then you are
> > probably
> > encountering the above problem.
> >
> > James,
> > At the time I generated my patch, I took a look at the 4.0
> > codebase. It
> > seemed that this would also be a problem there...
>
> Really? Fancy submitting a patch :) I took a look at 4.x and saw that
> the ActiveMQSession wasn't registered with the TransactionContext so
> didn't think the problem existed in 4.x though I could have been
> mistaken.


James,
You are correct. The problem doesn't exist in 4.x. I only looked at the code
in Session.close()/dispose() and jumped to an improper conclusion. As you
describe, Sessions are no longer tracked by TransactionContext objects.

--kevan