I am using glassfish 2 with OpenMQ 4.3. Currently, I am creating a glassfish cluster to deploy application. It also seems to create a cluster for JMS broker. How can I continue to create the glassfish-cluster but keep the JMS broker as independent instances ?
Thanks for the response !
But, REMOTE flag will require a separate startup of broker. Is it not possible to keep it LOCAL and still not create a cluster of broker. In previous versions of application server, it required manual steps to create the cluster. Isn't their some sort of properties files or parameter that I can specify to keep it from create jms broker cluster ?
Do you mean that you want each GlassFish instance in the cluster to start a MQ broker, without the brokers being connected in a cluster? This would mean that messages would not by default be delivered from one GlassFish instance to another. Why would you want this?
Yeah, that's exactly what I was looking for.
The reason I am looking for that configuration is that I am seeing odd behavior with clustered brokers using 2 machines. The drainer rate slows down a lot after running for a while. I did not see that behavior using only one machine with the cluster. So, I want to try out the scenario without cluster broker.
OK. Having the brokers unconnected wouldn't allow messages to be delivered between instances, why is why in a GlassFish cluster the MQ brokers are connected in a cluster. If you want to try something unusual in order to track down the cause of strange behaviour you can use REMOTE mode and then configure the MQ brokers any way you want, though I would suggest that disconnecting the brokers will simply confuse matters.
Thanks for the response.
I was also seeing behavior where broker would not return messages to the consumer. There was an issue again MQ 4.3 (bug 6961586) for this problem. I am seeing a little twist to that problem.
I had around 100,000 messages in the queue, but the consumer would return with 0 messages. But if I send new messages, those new messages are returned to the consumer, and once the queue length reaches 100.000 again, consumer again starts returning 0 messages.
The new messages coming at a slower rate. So, I wonder if the slow drain rate I am seeing is it draining just the new messages and not the old ones..
just a thought