What address-full-policy are you using?
The address-full-policy being used was BLOCK. Now I have changed it to PAGE. But still in the stack trace, I can see threads getting blocked in ChannelImpl.sendBlocking. Don't know if I am right here, but hornetq code suggests that the threads should go to ChannelImpl.sendBatched (if it works correctly).
Are you using transactions?
session.commit() or session.rollback() will also make a blocked call.
I don't have the stack trace from you.. so that's my best guess.
You need to send it non-transactionally if you don't want it blocking. (there's no point on making a transaction if you want it unblocked. if you don't want to block means you can afford losing messages in case of failures... so no point on committs then)
We are already using non-transacted sessions. We have also set journal-sync-transactional and journal-sync-non-transactional to false. Given below is the stack trace I am getting:
at org.hornetq.core.client.impl.ClientProducerImpl.doSend(org.hornetq.api.core.SimpleString, org.hornetq.api.core.Message)
at org.hornetq.core.client.impl.ClientProducerImpl.send(org.hornetq.api.core.SimpleString, org.hornetq.api.core.Message)
at org.hornetq.jms.client.HornetQMessageProducer.doSend(javax.jms.Message, long, org.hornetq.jms.client.HornetQDestination)
at org.hornetq.jms.client.HornetQMessageProducer.send(javax.jms.Destination, javax.jms.Message, int, int, long)
at com.bsb.hike.pubsub.jms.JMSProducer.send(javax.jms.Destination, javax.jms.TextMessage, int, int, long)
at com.bsb.hike.pubsub.jms.JMSProducer.send(java.lang.String, com.bsb.hike.common.HikeMessage)
I just checked the connection factory instance. block-on-durable-send is still coming to be true (though I have set it to be false in the configuration). I programatically set it to false and now threads are not blocking.