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
