I know I might sounds ridiculous for some experts, however, it's been in my head for quite a while and still no concrete answer found.
In PUBLISH/SUBSCRIBE MESSAGING WITH JMS TOPICS: JMS publisher sends a msg to JMS provider, and JMS provider sends the msg to JMS subscribers and receives their acknowledgement.
Is it possible that I can somehow modify the JMS provider, so that the JMS producer only sends out every other message it receives from JMS publisher?
Totally newbie in this field, so any suggestion is welcomed.
If what you want is for the subscriber to be able to configure to receive messages in batches, where each subscriber can have a different batch size, then JMS will not provide this functionality. This is not a typical pubsub type scenario.
If you want to accomplish this, I would suggest you add some custom buffering on your subscriber side that will queue up the incoming messages and then do a batch notify when your queue is full. This could then be easily configured on a per subscriber basis.
The only messaging system that I know provides a similar functionality is pubsub in XMPP, but even then the batches are determined by a timed interval instead of number.
You could look at filtering at your JMS subscriptions using JMS API Message Selectors. You can then only read/process messages that match a certain criteria.
With more information about what you are trying to accomplish (filtering? testing dropped messages? load balancing? something else entirely?) you might get a better answer.
Why would you want to do this? Would it not defeat the whole gambit of messaging, which is not to lose any messages? Or is it that you want to control exactly how the message gets distributed to subscribers? Even this would go against the basic JMS specifications.
Related
I am using Java, spring-boot and ActiveMQ.
I need to send a large bunch of messages in shortest time.
Right now it takes lot of time to send message one by one using JMSTemplate.
Is there any way I can bunch the messages and send if to activemq at once with guarantee to maintain the order of messages?
thanks in advance
Default ActiveMQ configuration can be slow for large message flow. We use following configuration for improving the message rates -
connection.setOptimizeAcknowledge(true);
consumerSession = connection.createSession(false, Session.DUPS_OK_ACKNOWLEDGE);
setOptimizeAcknowledge configures optimized acknowledgement of received messages while Session.DUPS_OK_ACKNOWLEDGE allows batched acknowledgements.
Spring's JMSTemplate is notorious for bad performance outside a Java EE container (or some other environment which provides pooled connection resources). Read more on the Apache ActiveMQ website. Therefore, you need to use a connection pool or ditch the JMSTemplate for something else.
I have a question regarding JMS. I´ve been checking some blogs, where show how a sending topic message can be receive by a queue listener. It is that even possible, as far as I know only a client subscribe to a particular topic can receive a message published.
Regards.
So, given you publish to a topic, you want to consume the messages from a queue. I assume you use ActiveMQ since you added that tag.
The main reason for this setup is to be able to load balance multiple cluster nodes of the consumer. Plain durable subscriptions won't allow that in JMS 1.x. I guess your case is similar.
In generic JMS, this is not possible. However, in JMS 2.0 durable subscriptions can be load balanced and hence work a bit like queues. Not all JMS brokers implements JMS 2.0. ActiveMQ does not implement JMS 2.0, but ActiveMQ Artemis do.
ActiveMQ allows this by a concept called Virtual Topics. Using Virtual Topics you can give the topic a certain name, say VirtualTopic.MyTopic would forward all published messages to any created queue that matches Consumer.MyConsumer.VirtualTopic.MyTopic.
Example topic name:
VirtualTopic.GameScores
Example queue names:
Consumer.ScoreBoardService.VirtualTopic.GameScores
Consumer.BettingService.VirtualTopic.GameScores
I'm confronted with a system (Java, OSGI-based, Equinox, Blueprint) that needs to send asynchronous notifications via SOAP messages to a remote system. The system must ensure that the notifications reach the remote system (i.e. it reponses with a confirmation message, WS-ReliableMessaging is not available).
Now I see two Options:
Use the EventAdmin mechanism of OSGI to trigger the notifications, implement my own handler which persists the notification in a queue. A quartz job would poll the queue and try to send the Soap message. The message would only be removed from the queue if the remote system reponses successfully.
Use a messaging middleware like ActiveMQ (e.g. as part of Apache Servicemix) to make use of JMS and make the whole task a lot easier.
What do you suggest?
Take JMS, if you go for 1 you'll end up implementing some of the stuff that is already provided by a JMS system. OSGi events are nice, but after a shutdown of the container they are gone. So this will be at least one of the drawbacks that you'll have to re-implement that a JMS messaging system like ActiveMQ already provides.
I am getting into Message Queueing recently (with ActiveMQ) and experimenting.
So far I have been able to set up one producer with 2 consumers written in Java implementing JMS over Tcp. The producer sends 2 types of messages to the queue in ActiveMQ, while at the other end, 2 consumers from a different machine pick up the messages based on the message properties.
My question was:
Does the consumer/producer need to implement the same protocol, or
Would it be possible to have a producer send messages to the Queue with JMS and
have a client (like node js) use another protocol (like AMQP) and collect messages from the same queue?
Thank you for your advice,
Probably the answer to your question is documented at Oracle's JMS as a MOM Standard:
It’s important to note that JMS is an API standard, not a protocol standard. Because all JMS clients implement the same interface, it is easy to port one vendor's clinet to another vendor's JMS provide implementation. But different JMS vendors typically cannot communicate directly with one another.
ActiveMQ implements the standard JMS client library using it's own protocol (OpenWire) however it also supports several other protocols allowing you to connect from other client like an MQTT client, STOMP client or an AMQP client and consume / produce from a Queue.
To see how to use AMQP for instance refer to the ActiveMQ docs and for best results use the latest release of ActiveMQ.
I am using JMS (ActiveMQ) between a Topic Publisher and a variable number of Topic Subscribers.
I would have to check if, at a given moment in time, some of the subscribers are "offline" (disconnected, shutdown, unable to communicate, etc...).
Is there a way that JMS allows the publisher to know which subscribers are "registered"?
Right now, I have it implemented so that subscribers send an "alive" message on a specific Queue (acting as producers) and the publisher receives them (acting as a consumer): if it is detected that any of the subscribers didn't "ping" for X seconds (threshold), it is assumed to be offline.
It works, but I was curious to know if I reinvented the wheel...
I know that this feature is not completely related to Messaging or Pub/Sub paradigm and I also know that Pub/Sub is specifically designed so that the publisher doesn't have to worry about who/where/when its messages will be consumed....but I was wondering that, if it DID want to know, maybe there was a way.
After all, it doesn't seem like a particularly uncommon usecase....
Thank you very much.
I don't think there is a way to tell your publisher the information about the subscribers directly.
what you should do is actually use AMQ advisory messages to keep track of the statuses of your subscribers. Read the article - it provides all the information you need.
JMS explicitly decouples publishers from subscribers. The whole point was supposed to be that the two did not need to know or care about the state of the other. Therefore JMS has no facility to do what you require. On the other hand, providers will have vendor-specific administration APIs and, as Paul notes, the AMQ advisory messages are what you want with Active MQ. Because these are vendor-specific it will not be portable to any other provider though and will not be JMS compliant. Not the fault of AMQ, just that it's not part of the JMS spec.