We're evaluating JMS implementations, and our requirements call for durable subscribers, where subscribers can go down for several hours, while the MQ server accumulates a large number of messages.
Is anyone using Sun MQ in a similar scenario? How is it holding up?
Sun folks, do you know of production installations that use durable topics with high data volumes?
thanks,
-am
We make use of durable subscribers to topics. In general we have not seen any problems but I'm not sure what you consider high data volumes.
For example we can have 40,000 messages pending on a topic to a given durable subscriber that has been offline for a number of hours... and we don't seem to have any problems. Although I do believe we see some slowdown on the transactions - although we are running on modest hardware so that might be expected.
We have been experiencing some intermittent locking on the client side (we're running with SMQ 3.5SP2) - but we are investigating to make sure that it is not an incorrect use of Session/Threads. In the particular scenario we have a few hundred durable subscribers registered to a single topic using selectors - and we're rolling back transactions on a number of the subscribers at around the same time.
But as I say - we have not confirmed this is an issue with the sun broker - although we may try upgrading to SMQ 3.6 to see if that resolves the issue.
We are using a cluster of Suns JMS MQ 3.6 with durable message queues and persistent topics. In a 4 hour window each night we run over 20,000 messages through a queue. The cluster sits on two Windows servers, the producer client is on a AIX box and the consumer is running on a iSeries. Within the 20,000 messages are over 400,000 transactions. Each message can have many transactions. Yes, the iSeries client has gone down twice and the producer continued with the message queue pilling up, as it should. We just use the topic to send and receive command and status inquiries to the clients. So every thing works fine. We have only had a couple issues with a client locking and that maybe fixed with sp3, we are in the process of installing that. The only other issue we have had is that once in a while the producer tries to send an object message with to many transactions and it throws and JMS exceptions. So we put a cap on the size of the messages, if its over a set number of transactions it send each transaction as separately, otherwise it sends all the transactions in one object type (linked list of transactions) message. Compare the cost of this JMS system with Tibco or Sonic and youre looking at big savings.
