Maybe you have a modified hornetq-beans adding your own Bean and re-adding a subscription?
What version are you using?
You could maybe list the bindings journals using the export tool to see if somehow you had any duplicates added.
Thanks for the ideas.
My current theory is that this situation arises from the fact that I have tried to subscribe to two different JMS topics using the same clientID-subscriptionName combination. I had thought that these would not have to be unique so long as they were for different topics (e.g. I thought I could subscribe "myClientID-LoggingService" to TopicA and TopicB without a problem). But it occurs to me that, under-the-hood in HornetQ, since each subscription is a queue bound to an address, it's possible that these clientID-subscriptionName combinations must be unique across the server. Does anyone know if that's the case?
If so, I'm not sure how HornetQ allowed me to create this situation, but now I don't know how to repair it. When I start the hornetQ server with the JMSServerManager enabled, I can use jconsole to see the duplicate queues, but it won't let me call destroyQueue(), giving me the error message:
"Problem invoking destroyQueue: java.lang.IllegalStateException: HornetQ Server is not started. It can not be managed yet"
But when I comment-out the JMSServerManager, when I connect to HornetQ using jconsole, I don't see the org.hornetq MBeans.
I guess I will next try to use a different management API than the JMX one, with JMSServerManager disabled. Or does anyone have a better suggestion as to how to repair this (which in my mind means deleting this offending queue?)
I have also tried commenting-out the offending topics from the hornetq-jms.xml file, which doesn't have any effect. I seem to be in a Catch-22 state where the server is broken and needs management to fix, but in order to manage it I need to fix the server. Maybe I need to re-install HornetQ.
Maybe there's a bug on what you said. (two different topics using the same IDs)
What would happen if you reset the data? (Please preserve the data, do it as a test only).
Hi Clebert - thanks! Clearing the data directory did allow me to restart the server, and the topics were re-published with all their subscriptions gone. That definitely puts me back in business.
I think I will try to create the same situation again (knowing that I can always delete the data directory -- this is not in production yet) to confirm whether this has to do with having subscriptions with the same clientId/subscriptionName to different topics.
Thanks very much for your quick & helpful advice.
It would be great if you could create a testcase replicating the scenario.
And please open a JIRA if you can replicate the issue with a simple test.
Thanks Clebert, if I can get it to happen, I will create a test case and file an issue. So far, I've been unable to reproduce it. That is, I can reproduce the problem of not being able to use the same clientId/subscriptionName on two different topics, but I can't get the server to get into the "broken" state I had at the beginning of this discussion.
I have 2 topics configured in my hornetq-jms.xml file, and a consumer application with durable subscriptions using the same clientId/subscriptionName to both of those topics. The consumer application uses the spring DefaultMessageListenerContainer to manage its listeners. I am using HornetQ 2.1.2 Final. I know this is only anecdotal, but in case it's helpful, here's what I see:
- with a freshly-deployed server (no messages yet), I can repeatedly start the consumer and then stop it (each time having processed no messages), and oddly the subscription appears to be on only ONE of the topics, and the particular topic seems to change around as viewed in the JMX console - sometimes TopicA will have it, other times TopicB will have it). That seems odd to me because they're durable subscriptions and I would think they would not get unsubscribed even with no messages present.
- once I publish messages to the topics, the subscription stays with the topic that had it before the messages were published. I can't get it to jump around any more (even after the messages have been consumed), I can't get it registered to more than one topic, and I can't cause the server to be in the "broken" state.
So, if I can reproduce just the "Unable to use the same subscription ID and name on multiple topics" issue, should I file a JIRA? Is that supposed to be supported? Or is it just the startup failure I saw earlier that's unexpected?
Once again, thanks for all your help.
>So, if I can reproduce just the "Unable to use the same subscription ID and name on multiple topics" issue, should I file a JIRA? Is that supposed to be supported? Or is it just the startup failure I saw earlier that's unexpected?
I don't think that's a bug. I would need to dust of the spec. (can't have it all on my head :-) )
Open it if you can get the server into a broken state, or if you find any indication this is against the spec somehow. (discuss it here first please).