I am wondering if MQ can be used as a state cache for monitoring? And is this a good idea or not?
In theory you can have many sources (monitoring agents) that detect problem states and distribute them to subscribers via an MQ system such as RabbitMQ. But has anyone heard of using MQ systems to cache the state, so when clients initialize, they read from the state queue before subscribing to new state messages? Is that a bad way to use MQ?
So to recap, a monitor would read current state from a state queue then setup a subscription queue to receive any new updates. And the state queue would be maintained by removing any alerts that are no longer valid by the monitoring agents that put the alert there to begin with.
Advantage would be decentralized notification and theoretically very salable by adding more mq systems to relay events.
I have a use case for Rabbit MQ that holds the last valid status of a system. When a new client of that system connects it receives the current status.
It is so simple to do!
You must use the Last Value Cache custom exchange https://github.com/simonmacmullen/rabbitmq-lvc-plugin
Once installed you send all your status messages to that exchange. Each client that needs the status information will create a queue that will have the most recent status delivered to that queue on instantiation. After that it will continue to receive status updates.
IBM MQ FTE uses such way for storing logs.
I think it is good idea, if you can prevent destination queue from overflow, because IBM MQ for example remove overdue messages only during GET call.
Related
Is it possible to keep a history of messages (with message content would be perfect) that have already been retrieved and are no longer on a queue?
In the application I can see when the sender attempts to put the message in the queue and when the receiver attempts to pick the messages up, but I'd like to see when the message really arrived into the queue and when the messages were really received.
Does MQ Explorer have this function? How would I use it?
What you are looking for is a message tracking/auditing software for IBM MQ. You can find a list of what is available here.
It is possible to use an API exit to make copies of messages in a queue or to audit both PUT and GET operations.
It is also possible to put messages to a topic, then create as many administrative subscriptions to destination queues as required. Something can then GET and log messages from one of those destination queues. The problem with this is that MQ changes the message ID between publication and consumption whereas in a queue it remains static.
There is no native MQ function to capture messages. It's possible to use linear logs and later scrape the logs but these do not necessarily capture all messages due to optimization. (A message PUT to a waiting getter outside of syncpoint for example.) However there is at least one commercial product to scrape linear transaction logs to audit message activity.
The philosophy of MQ in general is that it is the delivery mechanism and deals with envelope data to route and deliver but does not deal with payload data. WAS, IIB and other broker/transformation engines are where IBM has put all of the functions that deal with message payloads.
We are using WebLogic 10.3.6.0 and IBM MQ 7.5.
Application design is to send messages to a dead letter queue (in WebLogic) on re-delivery. The re-delivery happens as the first delivery has failed due to some network issue or database data source failure.
My Client wants a way to browse the messages in the dead letter queue from the application GUI and pull them for processing when the network issue or data source issue has been resolved.
What is the best way to go about this?
I cam across QueueBrowser coupled with activemq or some other implementation. Is QueueBrowser possible with WebLogic? Please suggest on best ways to achieve this requirement.
Kindly pardon if my question is too naive. I am only a PL/SQL programmer.
Valerie is referring to the SYSTEM DLQ and application should never ever write to it. Application's should have there own DLQ.
i.e. If your application queue is called 'TEST.Q1' then your application DLQ should be called 'TEST.Q1.DLQ'.
There is a whole long list of MQ tools here to view messages and manage your MQ environment.
Is the application actually designed to write to the DLQ? If so, that is a very poor design. The DLQ is for the queue manager and MQ software to place messages which can not be delivered. The application should not be writing to the DLQ.
As for how to view messages on DLQ, that can be done with the MQ Explorer GUI. Or to write a script, use the DLQ handler (runmqdlq) with a rules table for processing messages.
I have a TIBCO BusinessWorks process that is publishing to a JMS topic -- lets call it TOPIC.A -- there is one process that is subscribing to that topic with a name SUBSCRIBE.A.
The problem I have is that the first server that starts listening to SUBSCRIBE.A hooks in fine. The other 3 servers, running the exact same process get an error of "WebSphere MQ call failed with compcode '2' ('MQCC_FAILED') reason '2429' ('MQRC_SUBSCRIPTION_IN_USE')"
This can't be reasonable behavior for enterprise software, and I know WebsphereMQ, JMS and TIBCO Businessworks all scale well, so I must be missing something. I only want each event processed once, but a single box just isn't going to do it, both for fail-over reasons and shear volume reasons.
What do I have to do to let all 4 servers in the cluster to service the subscription SUBSCRIBE.A?
I agree it does not seem like reasonable behavior for enterprise software - but this restriction is imposed by the JMS specification. The JMS 1.1 spec, section 6.66.1 says "Only one session at a time can have a TopicSubscriber for a particular durable subscription".
That said, WebSphere MQ does provide a vendor-specific option that allows you to do what you want: see the CLONESUPP Connection Factory property. This is documented in the Infocenter at the CLONESUPP properties page.
While it's specific to MQ, if you specify this using administered objects you code will not need to use any vendor-specific methods.
The reason for MQRC 2429 is because all of your 4 subscribers are using the same client ID and all are trying to use the same durable subscription. When a subscriber is already actively listening on a durable subscription, no other subscribers can listen on the same. If you want all subscribers to listen concurrently, then have separate client ids for each of your subscribers.
But you must note that all subscribers will get a copy of the same message published by a publisher (TIBCO BusinessWorks in your case). So if all subscribers are active, all will process the event.
For fail-over you can look at using WebSphere MQ Multi-instance queue manager feature or any other HA solutions. For load sharing you can look at WebSphere MQ clustering feature.
I used the Subscriber SYSTEM.JMS.D.SUBSCRIBER.QUEUE and Client ID as setClientID("USER1") and used topicSubscriber = topicSession.createDurableSubscriber(topic,"SUB1");
The topicSubscriber is created and while trying to receive using this topicSubscriber.receive(); , it is not receiving the messages from topic , but there are messages in topic.
Can any one say why its not receiving messages and whether i need to chek any queue configurations.
Any help is appreciated.
Thanks in advance.
I already had topicConnection.Start() in my coding , also i checked in TopicSession there is no Start() Method.
The same code with Non durable subscriber method topicSession.createSubscriber(topic); is working , but for durable it is not working.
Thanks
Sorry, yes I meant topicConnection.Start(). It was worth a check.
I got the answer for durable subscriber not working ,
My queue depth has reached the max queue depth , so the subscriber is not able to subscribe the message.
Eg . my max queue depth for queue SYSTEM.JMS.D.SUBSCRIBER.QUEUE is set to 100 , and if we check our current queue depth and if it reaches 100 the subscriber will not work.
As an alternative way iam trying to create with Temporary Topic , here iam getting an error while creating the durable subscriber topicSession.createDurableSubscriber(topic,"SUB1");
JMS Exception :: javax.jms.InvalidDestinationException: MQJMS0003:
Destination not understood or no longer valid
Can anyone help to solve this error.
Thanks in Advance.
The problem seems to be how you are using SYSTEM.JMS.D.SUBSCRIBER.QUEUE. You appear to be directing messages and subscribers to this queue as the destination for a durable subscription. IBM MQ uses that queue to manage durable subscriptions.
As a general rule, queues whose names begin with SYSTEM are for internal system use by MQ. Some of them, such as SYSTEM.ADMIN.*.EVENT are OK to get messages from but you would not use these as a subscription destination for unrelated messages either.
Many tutorials use SYSTEM.DEFAULT.LOCAL.QUEUE as a destination for messages but this is only because the queue is known to exist on all versions of MQ and MQ uses only the definition of the queue and never the content of that queue. It is easier for the tutorial writer (and IBM is just as guilty here) to point at SYSTEM.DEFAULT.LOCAL.QUEUE then to walk the student through the need for and means to create their own queue. So although best practices suggest it should not be an exception to the "do not use SYSTEM objects" rule, common usage makes SYSTEM.DEFAULT.LOCAL.QUEUE the de facto exception.
The other exceptions are, of course, the command queues for MQ, MFT and IIB. These are also names SYSTEM.* but are designed for users to communicate with the software listening on the queue.
Note that all the exceptions "do not use SYSTEM objects" rule are interfaces between applications and MQ system resources. The event queues are MQ sending information to the user. The command queues are the user sending information to the system components. A subscription is neither of these categories. A destination for a subscription is considered an application-owned object, even when the system manages it on behalf of the subscriber.
When you want a durable subscription, either let the system assign a permanent queue and use that, or else pre-define a queue (that is not named SYSTEM.*) and use that. Whatever else you do, please do NOT try to hijack MQ's internal system queues for application-level purposes.
I have a .NET application that needs to monitor a queue in WebSphere MQ. I need to react to each message without impacting the current process. The client application can't explicity send me the same message.
Can I read a message without removing it from the queue? Can I be notified for each message? Can I configure the MQ to duplicate the current queue?
Is there another solution?
If you are using WMQ v7 then you can do this without any impact to the existing applications other than to change the queue name for one of them.
Currently the message producer and consumer use the same queue. In v7 of WMQ you can create an alias over a topic so that the message producer thinks it's a queue. Then you can create two administrative, durable subscriptions such that one points to the existing input queue and another points to a queue dedicated to your new application.
Of course you are already using v7 since v6 goes out of service next year, right? You can upgrade the QMgr to v7 which enables this behavior while still using v6 client code for the apps.
If you are using WMQ v6 then the MirrorQ program might work for you.
You could change from using a queue to a durable topic and have both your reader and your browser subscribe to it.
You could also create a distribution list on your queue manager. A distribution list is used to send a copy of the same message to multiple queues. You would then have a processing queue and a browsing/monitoring queue.