Weblogic application servers that I am using are clustered. I have a created a JMS queue and it has a JNDI name. When a consumer looks up the jndi name and publishes the event on a queue , would it be published in the queue created in both the app servers? The same MDB will be running on both the servers - which one will get the message posted on to the queue? In case I need to delete the message put on the queue , should I iterate through all the nodes and delete the message?
Thanks.
Using a queue means the message is guaranteed to be consumed exactly once. Meaning, that the message will be delivered to both nodes, but it will only be processed once globally by one of the nodes. WebLogic handles the synchronization and coordination between nodes in your cluster to simultaneously guarantee the delivery, but assure that it is processed exactly once globally.
This is contrast to a topic, where each subscriber gets a copy of the message. Each message will be processed once by each subscriber.
You don't need to iterate through the nodes to delete the message... just grab a jndi reference to the queue and delete the message before any consumer consumes it.
You don't say what type of queue you're creating within Weblogic for this. For a clustered environment it's better to use a DistributedQueue, rather than a standard Queue. I believe it allows Weblogic to better handle how to deal with messages on the queue when one of the nodes in the cluster goes down. There is also the option to view the contents of a queue and delete messages from the Weblogic Admin Console.
Related
Our architecture is based on a ActiveMQ 5.10.0 backbone that consists of about 70 queues. Different applications send messages to queues and different applications consumes messages from queues.
In details, only 5 queues have more than one consumer while the remaining have one single consumer per queue.
Everything works fine except for the queues with multiple consumers. For these queues, messages are correctly queued but they are not dequeued untill we access to the ActiveMQ Web portal and click on the queue name thus enlisting the full message list. When we do this, suddendly pending messages are dequeued.
Some additional notes:
the queue only contains TEXT messages
we have 10 consumers registered to that queue. Every consumer defines a proper selector in order to consume only some of the published messages.
every message set a timeout since there are messages that doesn't match any selector rule and we don't want to keep messages in the queue indefinitely.
every consumer defines a connection pool via BiTronix pool. According to what suggested in another thread, for every consumer we set the prefetch to 0
Can someone give us any advice? Why accessing the ActiveMQ Web message list unlock the unqueued messages?
I am working in Jboss Messaging Queue server.
I have configured several queue in a separate sample-service.xml and I have configured each queue a Message Driven Bean class.
Now, I am able to enqueue values in the queue and also able to consume the enqueued values from the Queue.
My Problem is, I am not able to browse any of the Queue values even though the Queue has some queue values before its being consumed by its MDB. The QueueBrowser always shows empty values.
Note:
If I disabled the Message Driven Bean, I am able to browse the Queue values.
Please click here to view more information regarding My Queue Configurations.
Thanks in Advance..
I have JMS implementation based on JBoss (to be precise, JBossMQ on JBoss4.2). There are 5 clusters, with each cluster having few nodes. One node in each of the cluster acts as master node. Out of the 5 clusters, one of the cluster is supposed to publish messages to a persistent Topic, and the other 4 clusters consumes those messages. The publishing and consuming is done by only the master node of each cluster.
I want to device a mechanism where the publisher knows that the message was consumed by all the subscribers or a subscriber knows that it has consumed all the messages produced by the publisher. How can this be achieved?
In principle, you use a JMS system in order to not care about that and only configure it the way you need. You could save state information in a shared resource like a database, but I wouldn't do it. Better use monitor features of the JMS system in order to track that. In case your application really needs to know about the successful processing of a message, then you could have a queue where process acknowledge go back to the sender.
For HornetQ, which you might use with JBoss, you'll find an example of a clustered topic here.
I have a MDB deployed on Jboss that gets messages from a Websphere MQ queue,looking in each message header for GroupId and Sequence information.Once it gets all sequences for a group,puts together the payload of each message it received to form one big message and sends it to another system.
Now the MDB will be deployed in a Websphere Application Server 7 clustered environment and I don't know for sure if there is any caching/configuration available to gather all message sequences for a group by one instance of the cluster(otherwise,if one instance receives some message parts and another instance the rest,in the end the MDB won't be able to put together one big message)
I read that the jms-ra resource adaptor can be configured with con.sun.genericra.loadbalancing.selector= (e.g JMSType = 'Instance1' and so on for the other instances)
The JMSType header should be present in the message and should be 'Instance1', for instance 1 to process this message.
But I'm not sure if the system that will put the messages in the queue from where the MDB picks them up will send such information in their message headers.
Is there a way to configure the cluster to achieve this?
When working in cluster environment, MDBs work independently. There are several ways to achieve syncronization.
1) You can use selectors to divide message flows between cluster nodes. Here is the docs http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp?topic=%2Fcom.ibm.mq.csqzal.doc%2Ffg20180_.htm
The main problem is that selectors need some info in message properties to make their job. Somebody must put them there.
2) You can make syncronization on "shared" data collector, such as DB. You will put received messages there. Further processing can be made async or on last message come basis.
3) You can make a "proxy" yourself. You can make additional "internal" queue. Take messages by several MDB from external queue, anylize them and put properties needed for point 1. Then put messages in internal queue and read them as in point 1 using selectors by different nodes.
I'm facing a design issue in which I would like to have only one JMS producer sending messages to two consumers. There are only two servers, and the producer will start generating messages that will be load balanced (with round robin) to both consumers.
In the hypothetical case of one server failing, I do have a mechanism so a new producer will be activated in the remaining server. But what will happen to the messages that were being processed in the server that went down?
Will they be reassigned to the remaining server thus being processed by the remaining consumer? or they will be lost?
If the last case is true there will be another problem. The producer creates messages based on files in a NAS so when a server goes down, the newly activated producer will start creating messages based on the contents of the NAS and that may replicate messages (but that case is handled) the problem is that if the server that goes down is not the server with the active producer then when the server goes up again it will not have messages to consume and also no messages will replace the ones lost.
How can I achieve a design so that no messages are lost?
Note: When one server goes down, the journal and bindings are lost.
Once the message is transferred to a particular node it belongs to that node.
If a node goes down, you would have to activate that node with its journal and the message state would be recovered from disk. You could eventually have messages being redistributed if you don't have more consumers (that will depend on redistribution configuration of course).
Or the best approach would be to have a backup node for each node.
We have been advising the use of collocated topologies, where one VM has an active instance and a backup instance for the other Server... That way each alive server would also have a backup config. That's being improved on 2.4.0 as we speak as you need a lot of manual configuration at the moment.
So, in summary either:
Restart the node
configure backup nodes