This content has been marked as final. Show 8 replies
There's no such thing as a "persistent queue". Message are persistent or non-persistent. The term "persistent" does not apply to queues. Because of this, I don't understand your question.
In MQ, setting the broker property imq.autocreate.queue to false means that you will need to create a queue using the "asadmin create-jmsdest" command before you can send messages to it. if you leave this property to its default value of true then a queue will be created automatically when the first message is sent to it.
Are you seeing different behaviour?
OK... Sorry for the confusion
I meant persistent messages, specifically file-based persistence. I was seeing the behavior where restart of a cluster will lose the message in the queue. That behavior fits with the auto created queues and topic. So, I was trying to disable that. Once I set the imq.autocreate.queue='false', and create the queues manually, I was seeing the messages being stored in file under .../fs370/messages/QTestQueue/vrfile , but it takes 2 to 3 attempts to actually see the text file being created under /fs370/messages directory.
I was wondering what was the reason for messages not being persistent every time.
Let me know if it makes sense.
I meant persistent messages, specifically file-based persistence. I was seeing the behavior where restart of a cluster will lose the message in the queue.If you send a persistent message to a queue it should be written to the message store. The message should survive any subsequent broker or cluster restart. It makes no difference whether the queue was auto-created or created using administrative commands.
That behavior fits with the auto created queues and topic.
Which OS are you using? Are you using disk write caching?
I am sending persistent messages. But I don't see it being written to file everytime. Only after multiple installations, I see it getting written to file.
I am using Red hat 5 (2.6.18-194.11.4.el5 #1 SMP Tue Sep 21 05:04:09 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux)
I haven't figured out a way to check if the write-cache is enabled or not. But in either case, it should atleast write the messages to the file at the time of shutting down the cluster .
I upgraded from glassfish 2.1 to 2.1.1, since it comes with MQ 4.4.
Edited by: vineet on May 5, 2011 12:39 AM
Can you be more specific about what you are doing? How are you restarting the cluster? Are you only looking at the files in the message store, or are you trying to consume messages from the queue?
I am using ant scripts to install glassfish, create cluster, create resources, like queues and topics
It's a typical set up. I send persistent messages to a topic in JMS broker through Stateless bean. I have a 'routing' MDB which reads the message from topic and based on message header writes it to one of the queues. I have a consumer stateless bean, which reads message from these queues.
Once I send few messages to the broker, I check if it is persistent by restarting the cluster through Admin Console. But restarting the cluster causes all the message in Broker to be lost.
Before you sending persistent messages to the topic, make sure the MDB is ready listening on the topic and the MDB should be durable subscriber in order to have unconsumed messages routed to it to survive broker restart for persistent topic messages will not be persisted by MQ unless there is a durable subscriber for it; and make sure you are sending persistent messages to the queues, and in your test, you need to be able to tell whether messages in the queues had already been consumed by your consumer stateless bean.
The producer in this case was stateless bean, which was reading a resource value 'persist' to send the message as producer. The value was being used from annotaion @Resource(name="persist"). For some reason, it was not always being read correctly.
I changed to read the value through context lookup. That works now !
Thanks for the help.