How can I get all messages from a JMS topic in Tibco?
I know that I can use a topic subscriber, but it wouldn't fit exactly my needs. I want to start a process only once a day that will read all messages from a topic and process them. I cannot have both a timer and a topic subscriber in the same process.
I tried with "Wait for JMS Topic Message", but it seems that it gets only one message, no matter how many I have in the topic.
I would try going a different direction. You could implement this using 2 separate processes.
One process, a topic subscriber (with a durable) which receives all messages. This process starter should be disabled by default (so the listener is not active).
The second process is a timer, which will activate the first process through Hawk (Engine Command). So every time the subscriber gets activated, it will start processing events.
The problematic part here is the deactivation of the topic subscriber after it is done. For that you need a separate logic, when to deactivate the subscriber. This could also be done by a separate timer or some Hawk Rule which fires, when the subscriber has no more messages.
I think the best solution will be to bridge the JMS topic to a queue and use the "JMS Queue Receiver" activity at the start of your process.
Once you start the instance once a day, it will connect and process all the messages in the queue.
A much more natural solution (if it can be implemented) is to just implement a Topic Subscriber (or a Queue subscriber if the Topic is bridged to a Queue) and let the BusinessWorks Engine spawn Job instances whenever a message gets published.
This allows to spread the workload much more evenly than to get all the messages from either a Topic or a Queue.
Related
I have an application written in Ruby that has multiple threads that each send requests to remote AMQP endpoints. These threads are spawned from time to time when new tasks have to be run.
If I use temporary, exclusive queues per thread for sending responses to their requests, then it becomes easy to write the code to handle incoming messages in this Ruby service. The queues are deleted as soon as the associated channel is closed so they don't stick around after their purpose is over.
The alternatives I can think of all require a listener thread listening on one or more queues that receive all incoming messages / responses into the Ruby service, and then routing these messages to waiting threads using some message identifiers. This seems more complicated, and I am unable to use RabbitMQ for all the required semantic routing.
Is the first model a viable model for AMQP communication? Is there a better pattern for handling this case?
the answer largely depends on your use case
if you don't care about losing messages when a given queue is deleted, then the first option is fine.
if you need messages to stick around in a queue until something comes along to process it, then you need to have a durable queue where messages sit.
there is no requirement for queue per thread, with rabbitmq.
however, you should be using a channel per thread.
given that, you can have a channel per thread and have multiple channels consuming from the same (or different) queue without issue.
as long as you keep channels limited to a single thread, you can do whatever you need in regards to the queues you are consuming from.
I am using RabbitMQ with Spring. I have multiple workers running on separate vm's that pick up messages in a round robin fashion. All is good.
Now, I would like to declare one queue "command" where ALL the workers process messages sent to that queue. So I want this command to be run on ALL the worker/listeners.
Is it possible to set this up using RabbitMQ/Spring?
I saw one solution where each work setup their own queue for processing, but that is not ideal for me.
So, I would essentially like to broadcast a message to a single queue and have all the workers process the message.
Thanks for any help.
Dave
I would essentially like to broadcast a message to a single queue and
have all the workers process the message.
Create a fanout exchange. A publish subscribe feature where all the messages would be pushed to a single queue & received by all the subscriber workers.
I am still learning about this activemq and jms stuff.
I already tried some example and now I can produce and consuming message from the queue/topic.
Now I have a problem, when my client/consumer lost the connection, the message in queue/topic still send out that message, that message become lost and not kept in the queue/topic. So my question is how I can keep that failed message and how to make the broker resend that message again?
thanks
You are mixing up terminology a bit.
Queues will hold messages until consumed or the broker is restarted, unless the message has been marked as persistent, in which case they will stick around even after a broker restart.
Topics only deliver the current message to any current subscriber. However there are several methods you can use to persist messages published to a topic:
Durable subscribers.
Virtual Destinations .
Virtual Topics tend to be popular for many reasons over durable subscribers, but it really depends on the use-case.
How you create a durable subscriber depends on what you are using to create the subscriber (Spring, POJO, some other API?). All methods will at some point call the Session.createDurableSubscriber method, but I suggest reading up on how they behave before choosing this over Virtual Topic or Composite Queues.
The thing which you are looking for might be Durable subscription
You can find documentation for same at http://activemq.apache.org/how-do-durable-queues-and-topics-work.html
I have a JMS ( ACTIVEMQ ) subscriber(asynchronous) that is polling a topic to receive the message from the JMS provider. The provider is putting an object message into the topic every 5 sec and that subscriber is receiving it as usual.Now when the subscriber terminates, the publisher still continuous to put the messages into the topic. so i want to know how can i handle the program termination of subscriber( i,e i want to know how to handle or what method is called when the subscriber terminates). when the subscriber shuts , the provider keeps on putting the messages into the topic . The provider is running on the server and subscriber is running on the client.
please help :)
Advisory Messages is probably what you are looking for. I have not implemented them myself, but I've read it is possible. You should be looking at the consumerCount
Cheers, Eugene.
I have an application which tries to subscribes to a lot of different topics.
The server side publishes a lot of messages through these topics and as soon as the application starts subscribing, it receives so many messages that the application cannot even reach the end of the subscription function.
It seems that the OnMessage Listener is flooded so much (the listener is the class which is trying to subscribe itself ot all the topics).
So basically is there a way to stop the reception of messages until I have subscribed to all of the topics? Or am I missing something there?
The thread trying to subsscribe to all of the topics never get the processor again.
(If the server is down, the subscription is fine since it does not receive anything so it does not lose the processing power..)
Thank you in advance.
Paul.
You could try lower the prefetch limit of the consumers, this would prevent the broker from attempting to dispatch so many messages when they are created which should help reduce the flooding issue you are seeing.
Here's some documentation that might help.
http://activemq.apache.org/what-is-the-prefetch-limit-for.html
Tim -
www.fusesource.com