I don't think I am using message selectors on my topic. Also This seems to happen when traffic is pretty low. I don't imagine paging is happening.
How can I fix this issue now without waiting for the bug to be fixed? My config for hornetQ's address settings is below. Would you suggest that I change the address-full-policy to BLOCK and just increase the max-size-bytes. I am sure that the topic wouldn't have had more than a few hundred messages a minute flowing to the consumers(numbered around 40). Anyway, let me know what you think. This seems to happen once or twice each day.
I'm referring to 24.9 (unacked messages).
I think that makes sense. It does however look like we are acknowledging the messages right away. Here is the message listener for the clients. Am I missing something here. The other interesting thing is that when this happens I pull up Java VisualVM and go to look at the topic and I can't. I see that the topic is there but when I click on it to look at the attributes it won't show anything just a blank page and it won't let me invoke any jmx operations I can still see the queues like normal but not the topic. Is there a way to test your theory that I am running into this issue?:
public class JMSPerseusUpdateClient implements MessageListener
private Map<Class,TopicCallBack> callBackMap;
private TopicConnection connection;
private TopicSession topicSession;
private TopicSubscriber subscriber;
public JMSPerseusUpdateClient(LoginSessionDetails loginSessionDetails, ExceptionListener handler)
callBackMap = new HashMap<Class, TopicCallBack>();
ContextDetails contextDetails = loginSessionDetails.getMessagingServerContextDetails();
TopicConnectionFactory factory = (TopicConnectionFactory) contextDetails.getContext().lookup(loginSessionDetails.getAppServerContextDetails().getConfig().getConnectionFactory());
connection = factory.createTopicConnection();
topicSession = connection.createTopicSession(false, Session.CLIENT_ACKNOWLEDGE);
//Lookup a topic
Topic topic = (Topic) contextDetails.getContext().lookup("topic/PerseusUpdateTopic");
subscriber = topicSession.createSubscriber(topic);
catch (Exception ex)
throw new PerseusException("Unable to create remote connection to model server.", ex);
public void addCallBackHandler(Class clas, TopicCallBack callback)
public void onMessage(Message message)
message.acknowledge();//acknowleging the message as soon as I can.... (If I have issues with processing them ohh well)
ObjectMessage objMessage = (ObjectMessage) message;
Serializable object = objMessage.getObject();
TopicCallBack callBackHandler = callBackMap.get(object.getClass());
if(callBackHandler == null)
catch (JMSException e)
Logger.getLogger(this.getClass()).error("Error getting and processing message", e);
public void closeConnections()
catch (Exception e)
public static interface TopicCallBack<T>
public void callBack(T t);
Since you're using ClientAcknowledge.. ACKs will be batched accordingly to the TransactionBatchSize.
Try using Auto-ACK for a test or Transactions on the consumer (but don't consume the whole thing in a single batch), or you may still starve (having more messages in memory than what would fit in your max-size on the address settings).
Are you saying that if we use topicSession = connection.createTopicSession(false, Session.AUTO_ACKNOWLEDGE); the acks will not be batched together? I can change that. I am not sure I understand what you mean when you say "or Transactions on the consumer (but don't consume the whole thing in a single batch), or you may still starve (having more messages in memory than what would fit in your max-size on the address settings)" Do I have to explicitly say that the session is non-transacted? I don't care if I have a transactional session I can lose some messages. What can I do to elimnate the transactional behavior of the session? I thought I hadd to create the session with Session.SESSION_TRANSACTED passed in.
not using a whole batch I mean:
If you consume 200 MB of messages... you will starve as the memory will MaxSizes.
You can't just ACK messages that are requivalent > max-size, or you would starve. The same principle will be valid to batch-size or Transactions.
Okay I changed the acknowledgment mode to be pre-acknowledge to try and avoid this issue that way the server should hold onto the message at all. The topic still froze after a day and a half. Any other ideas?
Can you provide a self contained test?
Even if it's not a bug, it would help us identify what you're doing wrong.
I don't know exactly how to reproduce this seeing as I don't know what is causing it exactly and it takes a half a day or a day for it to show up. I have however found that setting the ttl on the messages seems to help significantly. I don't know if messages are hanging around for clients that have already disconnected or something.
Maybe you are creating new subscriptions, and the old subscriptions are still about.