In my java code I use Google -pubsub.
how can i set a timeout for
subscriber - wait for messages until timeout expires?
(how can i set a retry policy?)
publisher - wait till message is sent for timeout time.
(how can i set a retry policy?)
I saw this post but didn't manage to translate the js post to java
Here is how i set my sub
final Subscriber subscriber = Subscriber
.defaultBuilder(subscriptionName, receiver)
.setChannelProvider(channelProvider)
.build();
and pub
final Publisher publisher = Publisher.defaultBuilder(topicName)
.setChannelProvider(channelProvider)
.build();
With the latest Cloud Pub/Sub client library, you do not need to set timeouts or retry policies in the Subscriber. These are handled under the hood for you and you just need to pass your MessageReceiver into defaultBuilder. When messages are available, they will be sent to receiveMessage. If your subscribing stops for any non-retryable reason, then the Subscriber will be shut down. You can listen for these notifications by calling addListener on your Subscriber.
On the Publisher, you can use setRetrySettings in the Builder. In particular, you'd want to setTotalTimeout on RetrySettings.Builder. The Publisher will retry publish calls on retryable errors up to this total deadline.
Related
Is there a way we can push messages to RabbitMQ and have an expiry time for it and once it expires, it should provide a notification.
Or
Is there a way we can deliver the messages in RabbitMQ after a certain amount of time. For example, I want to push a message in the queue and wants it to get delivered after 10 seconds..and simultaneously next messages.
Regarding the first part of your question, the routing of messages that have expired due to a per-message TTL is a feature of the RabbitMQ dead letter exchange (DLX).
Regarding a delay, this is not something supported by RabbitMQ out of the box, nor in my opinion should it be a feature of a message broker. I can't imagine a legitimate use case where you would deliberately want to introduce a delay into a message queue. In fact, it is a design goal of any message broker to minimize delay with enqueued messages. If you find a delay to be appropriate, then it is also likely that a message queue is not the appropriate means of conveyance.
The RabbitMQ Delayed Message Plugin adds a new exchange type to RabbitMQ where messages routed by that exchange can be delayed if the users chooses to do so.
You can use it in a way like described below.
// ... elided code ...
Map<String, Object> args = new HashMap<String, Object>();
args.put("x-delayed-type", "direct");
channel.exchangeDeclare("my-exchange", "x-delayed-message", true, false, args);
// ... more code ...
I'm new to RabbitMQ and want to implement asynchronous messaging of SAGA with RabbitMQ.So I used RPC example of RabbitMQ to do the task. I've one orchestrator ( RPCClient) and multiple microservices ( RPCServer). Orchestrator uses unique queues to command microservices.And each microservice uses a common queue ( Reply_ Queue) to reply orchestrator. To keep log I want to get notifications in orchestrator side, when any microservice is down for any configurable time.
I read about consumer cancellation,but it only works when I delete the queue.How to get notifications in JAVA with keeping queue messages? And is it correct way to implement saga asynchronous messaging?
To implement a reliable RPC is hard, I can't give a detail guide about how to do this. If we ignore same special failure situation, I can give a simple workaround:
First, we assume that RPCClient never fail, RPCServer may fail anytime.
RPCClient need to know which request is timeout, so it can send request message with a TTL. After RPCServer receive request message and send response message, it should ACK the request message.
If RPCServer:
has failed before consume request message
OR
has failed before send response message
The request message will be republish to Dead Letter Exchange, so RPCClient can consume to some queue binded with that exchange, it can know which request is timeout.
Is there any way a publisher can be acknowledged that a published message has been delivered to a listener when using Spring AQMP? I have a number of queues where I set x-message-ttl = 0, which means messages will be discarded if they cannot be immediately delivered, but as I'm using this in a request/reply scenario, I'd like to be able to abort the request and handle an error immediately.
You could publish a message with the mandatory flag.
If this flag is set, the server will return an undeliverable message
with a Return method. If this flag is zero, the server will queue the
message, but with no guarantee that it will ever be consumed.
And set a return callback which will be called if the message in unroutable.
Another solution should be to use an alternate exchange associated to your exchange. The cons are that you need to bind a queue to this AE and consume messages to be able to know if a request has failed.
I would like to have an advice for this issue:
I am using Jbos 5.1.0, EJB3.0
I have system, which sending requests via UDP'S to remote modems, and suppose to wait for an answer from the target modem.
the remote modems support only UDP calls, therefor I o design asynchronous mechanism. (also coz I want to request X modems parallel)
this is what I try to do:
all calls are retrieved from Data Base, then each call will be added as a message to JMS QUE.
let's say i will set X MDB'S on that que, so I can work asynchronous. now each MDB will send UDP request to the IP-address(remote modem) which will be parsed from the que message.
so basicly each MDB, which takes a message is sending a udp request to the remote modem and [b]waiting [/b]for an answer from that modem.
[u]now here is the BUG:[/u]
could happen a scenario where MDB will get an answer, but not from the right modem( which it requested in first place).
that bad scenario cause two wrong things:
a. the sender which sent the message will wait forever since the message never returned to him(it got accepted by another MDB).
b. the MDB which received the message is not the right one, and probablly if it was on a "listener" mode, then it supposed to wait for an answer from diffrent sender.(else it wouldnt get any messages)
so ofcourse I can handle everything with a RETRY mechanisem. so both mdb's(the one who got message from the wrong sender, and the one who never got the answer) will try again, to do thire operation with a hope that next time it will success.
This is the mechanism, mybe you could tell me if there is any design pattren, or any other effective solution for this problem?
Thanks,
ray.
It's tough to define an exacting solution without knowing the details, but I will assume that when a response is received from a modem (either the correct one or not), it is possible to determine which exact modem the request came from.
If this is the case, I would separate out the request handler from the response handler:
RequestMDB receives a message from the [existing] queue, dispatches the request and returns.
A new component (call it the ResponseHandler) handles all incoming responses from the modems. The response sender is identified (a modem ID ?) and packages the response into a JMS message which is sent to a JMS Response Queue.
A new MDB (ResponseMDB) listens on the JMS Response Queue and processes the response for which the modem ID is now known.
In short, by separating concerns, you remove the need for the response processing MDB to only be able to process responses from a specific modem and can now process any response that is queued by the ResponseHandler.
The ResponseHandler (listening for responses from the modems) would need to be a multithreaded service. You could implement this as a JBoss ServiceMBean with some sort of ThreadPool support. It will need a reference to the JMS QueueConnectionFactory and the JMS response queue.
In order to handle request timeouts, I propose you create a scheduled task, one for each modem, named after the modem ID. When a request is sent, the task is scheduled for execution after a delay of the timeout period. When a response is received by the ResponseHandler, the ResponseHandler queues the response and then cancels the named task. If the timeout period elapsed without a cancellation, the scheduled task executes and queues another request (an reschedules the timeout task).
Easier said than done, I suppose, but I hope this helps.
//Nicholas
I am using a PacketListener to receive XMPP packets.
If I receive the following:
<presence from="jeanne#belle.com" to="betty#belle.com" type="subscribe"/>
is the XMPP server expecting me to respond immediately ?
Motivation: I want to cache all these subscription requests and allow the recipient to selectively ACCEPT/DENY (à la facebook invitations).
Is there an API in which I can request for all subscription requests from openfire ?
You do NOT need to reply immediately or even in a given session; the server stores the fact that you have a pending inbound subscription, and will re-inform you of the pending subscription every time you log in. Therefore, there should be no need to request the list either.