Producer and Consumer in java with consuming timeout - java

I want to write a CommunicationSupervisor for connection to a device with these features.
Outgoing messages should be queued in a data structure.
There is just one Consumer. Consumer should check if there is an element in queue.
Consumer should send the outgoing message and wait for an incoming response.
It is possible to produce new outgoing messages while consumer
is waiting for a responce but they will not be handled until consumer
is getting a response for first element, then second and so on
If consumer is getting a timeout for a message an exception should be raised but consumer should proceed with the other outgoing messages in the queue.
My question is what is the best method to implement this? Shall I use a SynchronousQueue as a data structure? Or do we have a pattern example for this? By the way We are using Java 6. So solution for java 8 is not going to work.
Thanks for the help

Related

In RabbitMQ is there a way for making sure the consumer consumes the message and then only the flow continues?

I have some code after the consumer consumes, right now since the message queue is asynchronous the flow will continue even if the message is not consumed by the consumer. I want to wait till the consumer receives the message and till then the flow needs to be paused. Is there any way to do it? I'm using RabbitMQ Java implementation and I'm using topic exchange.
In your case you can make your Queue a Lazy queue so that message will be stored on disk until the consumer comes back and picks your messages.
https://www.rabbitmq.com/lazy-queues.html

Is it possible to make the subscriber wait 3 seconds before retrieving the last message from the topic?

I am implementing a simple MQTT subscriber using PAHO, and it is working fine.
But I was told that the subscriber should not receive all messages sent to the topic, but instead it should get one message every 3 seconds (the last that was sent).
Is this possible?
No, messages are delivered to the subscriber by the broker as they arrive, they are not pulled/collected.
There is nothing to stop you adding incoming messages to a queue in the client an processing them at what ever rate you want, but this has nothing to do with MQTT or the Paho client.

A message sent to JMS Queue will be consumed by only a single consumer?

A case where senders are sending messages to a Queue, for example message1 is sent by sender1 to a queue. Now a consumer named consumer1 connects to queue and reads the message message1.
There is another consumer named consumer2. But the message message1 is already consumed by consumer1 so it will not be available for consumer2.
When a next message arrives in queue, consumer2 might receive that message if it reads the queue before consumer1.
Does it mean that it all is a case whether one consumer reads the queue before the other in order to get the first message available from the queue?
This is the nature of a Queue in JMS, messages are sent to one consumer and once ack'd they are gone, the next consumer can get the next message and so on. This is often referred to as competing consumers or load balancing. The consumers can share the work as jobs or work items are enqueued which allows for higher throughput when the work associated with the items in the Queue can take significant time.
There are options depending on the messaging broker to make a consumer exclusive such that only that consumer can read messages from the queue while the other consumers sit and wait for the exclusive consumer to leave which makes them backups of a sort.
Other options are to use something like Apache Camel to route a given message to more than one queue, or to use AcitveMQ Virtual Topics to send messages to a Topic and have that message then enqueue onto specific consumer Queues.
The solution depends on the broker you are using and the problem you are trying to solve, none of which you've really made clear in the question.

How Amazon SQS works in this scenario?

Consumer is listening on queue(FIFO or standard queue ),Producer produces the message on queue.
Does Amazon SQS queue deletes the message from queue automatically once it gets acknowledgement from consumer ? Is there a way/configuration where queue keeps the message instead of deleting it and ensures it is not delivered again.
Producer produces the message on queue. Consumer becomes offline because of network issue. After some time he/she get backs to online. will queue deliver the message
to consumer when he gets online ? I think yes as queue has not received ACK from consumer.
I believe you are asking from rabbitmq perspective. There is some difference. There is no ack in sqs. Messages are not automatically deleted, they stay in queue even after a consumer accepts it. The messages need to be explictly deleted by the consumer after it has done processing it.
Sqs does not bother about the online offline status of a consumer. The consumer periodically polls sqs for new items. If a message is available, it is handed out. Once consumer is done, it calls sqs to delete that message. Then again poll for new message.
In your scenario, once the consumer is done processing a message, it can make two requests: one to enqueue the message in a different queue and second to delete the message from original queue.
If you have multiple consumers listning on the same queue, then a concept of message-invisibility-period comes to play. If you have such setup, ask in comments and i will update with more info.
Hope it helps.

How to understand the "synchronous" and "asynchronouns" messaging in JMS?

After reading some document of JMS, I totally puzzled by the phrase synchronous and asynchronouns.
See this page: http://docs.oracle.com/cd/E19798-01/821-1841/bncdq/index.html
Synchronous
You use the receive method to consume a message synchronously.
You can use this method at any time after you call the start method:
connection.start();
Message m = consumer.receive();
connection.start();
Message m = consumer.receive(1000); // time out after a second
To consume a message asynchronously, you use a message listener, described in the next section.
Asynchronous
JMS Message Listeners
A message listener is an object that acts as an asynchronous event handler for messages. This object implements the MessageListener interface, which contains one method, onMessage. In the onMessage method, you define the actions to be taken when a message arrives.
You register the message listener with a specific MessageConsumer by using the setMessageListener method. For example, if you define a class named Listener that implements the MessageListener interface, you can register the message listener as follows:
Listener myListener = new Listener();
consumer.setMessageListener(myListener);
I have two questions:
As what I understood, the nature of JMS is asynchronous. Producer publishes messages to the queue/topic, it doesn't need to wait consumer. This is asynchronous behaviour. How can it be "synchronous"?
If the "mesageListener" is asynchronous, but in my test with spring-jms, I found it always running in a thread. That means, if I write Thread.sleep(2000) in onMessage, it have to be wait 2 seconds before processing next message. Is it "asynchronous"?
If you understand it better like this, consumer.receive() uses a pull model: you read from a queue and are blocked waiting for this message until it comes, or some timeout has elapsed.
Using a listener uses a push model: you register a listener and, when a message comes in, the listener is called, in a separate thread.
Everything is done in a thread in Java, and the listener call is no exception. Whether the listener message handling prevents the processing of other messages in the queue depends on how many threads are dedicated to message processing. If you configure Spring to use a pool of 5 threads to process messages asynchronously, then 5 listeners will be able to process messages in parallel.
Like I understand this:
asynchronous - MessageListener: Use this on a server that listens to a queue. When a message arrives, then deal with it immediately. The server keeps listening to this queue.
synchronous - consumer.receive(1000): Use this on a client applications that now and then needs to check if a message is intend for this client. Example: poll every 60 seconds. This only opens a connection to the server shortly. The 1000 milliseconds will keep this connection open. If a message arrives within these 1000 milliseconds, then the message is consumed and the connection is closed.
You are looking at it end-to-end: from publisher to the consumer. Yes, it is asynchronous delivery from publisher to consumer irrespective of Sync/Async consumer. However Sync/Async in your question is for consumer only, i.e from the JMS broker (eg: ApacheMQ) to the consumer. As others have pointed out, Sync consumers pull messages sequentially from the broker and are waiting for messages. Async consumers register a callback where messages pushed to them (onMessage). Async consumers can go about doing other things while these messages are delivered to them asynchronously from the JMS broker.
I understand synchronous/asynchronous differently.
Synchronous: Caller(Sender) has to wait till the response from consumer has been received(till the time-out) -- request/reply pattern
Asynchronous: Caller(Sender) just post message and continue with its work, while the consumer processes as soon as the message reaches it -- one way request
Any MOM(Message Oriented Middle ware) follows service activator pattern which promotes asynchronous communication. One of my project has implemented a framework around JMS to make communication really synchronous.
Any message has 2 parts.
a. Metadata attributes
b. Payload
Set attribute "reply-to-queue" to a randomly generated value
Make sure the MOM framework creates temporary queue with name from #2
Make sure the sender spawns thread, which listens to temporary queue created in #3
Publish message and block sender till it receives message to temporary queue
Make sure the consumer intercepts "reply-to-queue" header and publishes response to it
This is one of the ways to make MOM based communication acts like synchronous. You may find other implementations like request-reply mechanism.

Categories