activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Hanik - Dev Lists <devli...@hanik.com>
Subject Re: Question about Producer Consumer usage
Date Wed, 14 May 2008 04:26:10 GMT
jaya_srini wrote:
> Thanks Filip!
>
> Could using a failover transport cause this deadlock? We did see a network
> blip and several reconnect attempts being made in the logs by the failover
>   
that is possible but one can't tell for certain until there is a trace 
of it, the goal of a failover system is that it should change the 
behavior of a single point of failure system, but most of the time it does.

> transport. I was wondering if the failover thread trying to reconnect and
> the application thread trying to send a message somehow could get into state
> of deadlock
>
> After we removed the failover transport and enable async send and dispatch
> we are not seeing this issue anymore atleast not so far...
>   
good!
> Thanks again for taking time to respond!
>   
you're welcome
Filip
>
>
> Filip Hanik - Dev Lists wrote:
>   
>> at
>> org.apache.activemq.ActiveMQConnection.syncSendPacket(ActiveMQConnection.java:1172)
>> 	at org.apache.activemq.ActiveMQSession.send(ActiveMQSession.java:1640)
>> 	- locked <0x07c45ea0> (a java.lang.Object)
>> you are sending sync, in your code you can do this
>>
>> what you can do is play around with the async settings
>>
>>             ActiveMQConnectionFactory connectionFactory = new
>> ActiveMQConnectionFactory(user, password, url);
>>             connectionFactory.setAlwaysSyncSend(false);
>>             connectionFactory.setDispatchAsync(true);
>>             connectionFactory.setAlwaysSessionAsync(true);
>>
>> alternatively, you can create your own dispatch thread/queue to have
>> complete control of order of messages being sent etc.
>>
>> one thing that stands out
>>
>> "ActiveMQ Transport: tcp://localhost:61616" prio=6 tid=0x34054800
>> nid=0x6d8 runnable [0x3631f000..0x3631fd98]
>>    java.lang.Thread.State: RUNNABLE
>> 	at java.net.SocketInputStream.socketRead0(Native Method)
>> 	at java.net.SocketInputStream.read(SocketInputStream.java:129)
>> 	at
>> org.apache.activemq.transport.tcp.TcpBufferedInputStream.fill(TcpBufferedInputStream.java:50)
>>
>> the transport thread is waiting for data from the server, and that causes
>> the thread currently trying to send a message to be blocked, and as a
>> result everything else is blocked
>>
>> turning on async sending, might only mask the real problem, on why the
>> transport thread is inside the socketRead0 method, and not data is being
>> received from the server
>>
>> when taking thread dumps, always take two of them, otherwise you don't
>> have a reference in time 
>> Filip
>> 	
>>
>>
>>
>> jaya_srini wrote:
>>     
>>> here's the link
>>>
>>> http://www.nabble.com/file/p17221085/thread_dump.txt
>>>
>>> thanks
>>> Jaya
>>>
>>>
>>> Filip Hanik - Dev Lists wrote:
>>>   
>>>       
>>>> paste it into the email or provide a link to it,
>>>> attachment dont make it to the user list
>>>>
>>>> Filip
>>>>
>>>> jaya_srini wrote:
>>>>     
>>>>         
>>>>> Hi Filip
>>>>>
>>>>> I have attached the file "thread_dump.txt" that gives the thread-dump.
>>>>>
>>>>> if you need more info please let me know.
>>>>>
>>>>> thanks!
>>>>> jaya
>>>>>
>>>>>
>>>>> Filip Hanik - Dev Lists wrote:
>>>>>   
>>>>>       
>>>>>           
>>>>>> that is a thread dump for one (1) thread, why don't you post the
>>>>>> entire 
>>>>>> thread dump for all threads
>>>>>>
>>>>>> Filip
>>>>>>
>>>>>> jaya_srini wrote:
>>>>>>     
>>>>>>         
>>>>>>             
>>>>>>> thanks for the response, Filip!
>>>>>>>
>>>>>>> Thread dump below is what we got on the client side. I'll try
and see
>>>>>>> if
>>>>>>> I
>>>>>>> can get a better dump. So what would be the resolution for this?
Will
>>>>>>> enabling the jms.useAsyncSend property on the connection URI
help fix
>>>>>>> this
>>>>>>> i.e cause the send to be asynchronous so that it doesn't block?
>>>>>>>
>>>>>>> daemon prio=6 tid=0x3793f400 nid=0x1f28 waiting for monitor entry
>>>>>>> [0x38aff000..0x38affc98]
>>>>>>>    java.lang.Thread.State: BLOCKED (on object monitor)
>>>>>>> 	at
>>>>>>> org.apache.activemq.ActiveMQSession.send(ActiveMQSession.java:1587)
>>>>>>> 	- waiting to lock <0x07c45ea0> (a java.lang.Object)
>>>>>>> 	at
>>>>>>> org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:226)
>>>>>>> 	at
>>>>>>> org.apache.activemq.ActiveMQMessageProducerSupport.send(ActiveMQMessageProducerSupport.java:268)
>>>>>>> 	at
>>>>>>> org.apache.activemq.ActiveMQTopicPublisher.publish(ActiveMQTopicPublisher.java:146)
>>>>>>>
>>>>>>>
>>>>>>> Filip Hanik - Dev Lists wrote:
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>>>> as I mentioned, the blocking happens on the mutex for an

>>>>>>>> ActiveMQSession, the only way you can end up blocking two
threads
>>>>>>>> there, 
>>>>>>>> is if two threads are using the same session,
>>>>>>>>
>>>>>>>> can you post the complete thread dump?
>>>>>>>>
>>>>>>>> thanks
>>>>>>>> Filip
>>>>>>>>
>>>>>>>> jaya_srini wrote:
>>>>>>>>     
>>>>>>>>         
>>>>>>>>             
>>>>>>>>                 
>>>>>>>>> So Sorry! :(
>>>>>>>>>
>>>>>>>>> I just thought I would explain our scenario in more details.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> jaya_srini wrote:
>>>>>>>>>   
>>>>>>>>>       
>>>>>>>>>           
>>>>>>>>>               
>>>>>>>>>                   
>>>>>>>>>> Hello
>>>>>>>>>>
>>>>>>>>>> Apologies for all the questions but I am a newbie
to ActiveMQ and
>>>>>>>>>> I
>>>>>>>>>> would
>>>>>>>>>> really like to better understand how the ActiveMQ
broker works and
>>>>>>>>>> was
>>>>>>>>>> wondering if someone can explain how it would work
for the
>>>>>>>>>> scenario
>>>>>>>>>> below:
>>>>>>>>>>
>>>>>>>>>> I am using single session with 1 producer and 1 consumer
(durable
>>>>>>>>>> Topic
>>>>>>>>>> subscrber) for producing and consuming messages i.e
the same
>>>>>>>>>> session
>>>>>>>>>> produces and consumes messages. The session/producer/consumer
are
>>>>>>>>>> created
>>>>>>>>>> in app startup once and are reused through out.
>>>>>>>>>>
>>>>>>>>>> There is a message listener on the consumer for receiving
messages
>>>>>>>>>> asynchrounously. 
>>>>>>>>>>
>>>>>>>>>> Messages are persistent (written to the database)
and we are using
>>>>>>>>>> the
>>>>>>>>>> Publish-Subscribe model.
>>>>>>>>>>
>>>>>>>>>> The client APP (that send and receives the message)
and the
>>>>>>>>>> ActiveMQ
>>>>>>>>>> broker are on different machines so I use a TCP transport
to
>>>>>>>>>> establish
>>>>>>>>>> connection with a failover protocol so the connection
URI looks
>>>>>>>>>> like
>>>>>>>>>> below
>>>>>>>>>>
>>>>>>>>>> failover:(tcp://<broker_ip>:61616/)
>>>>>>>>>>
>>>>>>>>>> We are using ActiveMq 5.0.0
>>>>>>>>>>
>>>>>>>>>> Given the above info, what is the number of threads
created on the
>>>>>>>>>> broker
>>>>>>>>>> side for sending and dispatching. Will the send and
dispatch be
>>>>>>>>>> synchronous by default for the above?
>>>>>>>>>>
>>>>>>>>>> If I make the connection URI to be as follows
>>>>>>>>>>
>>>>>>>>>> tcp://<broker_ip>:61616?jms.useAsyncSend=true&jms.dispatchAsync=true
>>>>>>>>>>
>>>>>>>>>> will this cause the send and dispatch to be asynchronous?
>>>>>>>>>>
>>>>>>>>>> We are having some porblem with producer bloacking
on
>>>>>>>>>> ActiveMQSession.send() with our current set up and
I would like to
>>>>>>>>>> really
>>>>>>>>>> understand what's happening to be able to resolve
this.
>>>>>>>>>>
>>>>>>>>>> thank you!
>>>>>>>>>> jaya
>>>>>>>>>>
>>>>>>>>>>     
>>>>>>>>>>         
>>>>>>>>>>             
>>>>>>>>>>                 
>>>>>>>>>>                     
>>>>>>>>>   
>>>>>>>>>       
>>>>>>>>>           
>>>>>>>>>               
>>>>>>>>>                   
>>>>>>>>     
>>>>>>>>         
>>>>>>>>             
>>>>>>>>                 
>>>>>>>   
>>>>>>>       
>>>>>>>           
>>>>>>>               
>>>>>>     
>>>>>>         
>>>>>>             
>>>>> http://www.nabble.com/file/p17221085/thread_dump.txt thread_dump.txt

>>>>>   
>>>>>       
>>>>>           
>>>>     
>>>>         
>>>   
>>>       
>>
>>     
>
>   


Mime
View raw message