I have 5 verticles: V{1..5}. All the verticles subscribed at "topic" and send message to "topic". Is there a way how to publish message in a way that it won't be sent to sender? For example, V1 publishes "message" and receives it as well. I want to avoid it. I need "message" sent by V1 to be delivered only to V{2..5}, but not to V1. Is it possible?
It's not possible out of the box. But you could add a header to the message which identifies the sender and filter messages in the consumer.
Related
I was going through the tutorial shared by RabbitMQ here
I am assuming that the client code below
while (true)
{
var ea = (BasicDeliverEventArgs)consumer.Queue.Dequeue();
if (ea.BasicProperties.CorrelationId == corrId)
{
return Encoding.UTF8.GetString(ea.Body);
}
}
Would receive all messages on the queue and will unnecessarily iterate through messages not designated for it. Is their anyway we can avoid it i.e we can modify the client to only receive the messages intended for it only.
The basic work that i intend to achieve through RabbitMQ is Request-Response pattern where a request would be received by web-service which will send data in a queue the data object would have a unique reference number . This would be received by an asynchronous tcp-client which will send data on a tcp/ip layer based on message it had received.
On receiving reply from the asynchronous channel of tcp/ip the channel would parse the data and respond back on the queue with the corresponding request reference number.
The RPC approach is well suited for it but the client code shared have this shortcoming would appreciate feedback on it.
Actually I didn’t understand well your aim, but when you create an RPC model, you have to create an “reply queue”, this queue is bound only to the client.
It means that you will receive back only the client messages, and not all messages.
Since the Rabbitmq RPC model is asynchronous you can execute more than one request without wait the responses and replies could not have the same publish order.
The correlation id is necessary to map your client requests with the replies, so there are not "unnecessarily" messages
hope it helps
In my JAVA application, I'm using Amazon SQS and SNS; I did the below steps:
Step 1: I pushed the message to SQS like,
SendMessageResult aSendMessageStatus = Amazon_SQS_Client.sendMessage(new SendMessageRequest().withQueueUrl(AWS_SQS_URL).withMessageBody(theRequestString));
Step 2: Created topic in SNS like,
CreateTopicResult createRes = Amazon_SNS_Client.createTopic(createReq);
Step 3: Now I am trying to send email by receiving the messages from SQS to 100 of customer.
Can someone advice me on how to subscribe the topic in SNS and send the emails to multiple email addresses.
For SNS to deliver the message, the 100 email address would have to subscribe to the topic. The email address will get confirmation message which they will have to respond to.
For your scenario, another option could be to use the queue service. It can be done in multiple ways. I have a setup as follows:
An application component sends a message to a queue
Another application component polls the queue, retrieves the message
From the message an email is composed and use SES service to deliver emails.
Another option is to use SNS -> SQS -> SES setup, where initial notification goes to SNS, and SNS delivers the notification to SQS.
The notification message itself need not be the complete email message. It could be just a reference to the content and people to which the content is to be delivered. Your application could take care of forming the complete message.
For a scenario where email is delivered to a general application user, I think SES is the right solution rather than SNS.
I can't find documentation for reply processing with gateways and service activators.
If I have gateway which:
1) sends requests to channel ReqChannel
2) accepts replies on channel RepChannel
ReqChannel is connected to router, that routes incoming messages to one of some service activators, let say AServiceActivator and BServiceActivator and that service activators have a configured output-channel="RepChannel".
And if I execute more than one method call on gateway's interface asynchronously or simultaneously from different threads, how gateway will correlate incoming replies to actual service caller?
The gateway creates a temporary reply channel and puts it in the header of the message. This mechanism provides the necessary correlation because each message gets its own reply channel.
If the final consumer (say a service-activator) has no output-channel, the framework automatically sends the reply to the replyChannel header.
For this reason, it is generally not necessary to declare a reply-channel on the gateway for the final consumer to send to.
However, there are times when this is useful - such as if you want to wire-tap the reply channel, or make it a publish-subscribe channel, so the result goes to multiple places.
In this case (when there is a reply-channel on the gateway, and the final consumer sends a message there), the framework simply bridges the explicitly declared reply-channel to the temporary reply channel in the message header.
For this reason, it is critical to retain the replyChannel header in your flow. You can't send some arbitrary reply to a reply-channel, unless you include the original message's replyChannel header.
I have an webapp that is expected to fetch and display data from an External App which is accessible only via messaging (JMS).
So, if a user submits a request on a browser, the same HTTP request thread will have to interact with the Messaging system (MQ Series) such that the same request thread can display the data received from the Messaging System.
Is there a pattern I can make use of here? I saw some vague references on the net that use "Correlation ID" in this way:
Msg m = new TextMsg("findDataXYZ");
String cr_id = m.setCorrelationID(id);
sendQueue.send(m).
// now start listening to the Queue for a msg that bears that specific cr_id
Response r = receiverQueue.receive(cr_id);
Is there something better out there? The other patterns I found expect the response to be received asynchronously.. which is not an option for me, since I have to send the response back on the same HTTP request.
The request/reply messaging pattern is useful for your requirement. You typically use a CorrelationId to relate request & reply messages.
While sending request message you set JMSReplyTo destination on the message. Typically a temporary queue is used as JMSReplyTo destination. When creating a consumer to receive response use a selector with JMSCorrelationId, something like
cons = session.createConsumer(tempDestination,"JMSCorrelationId="+requestMsg.JMSMessageId);
At the other end, the application that is processing the request message must use the JMSReplyTo destination to send response. It must also use the MessageId of the request message and set it as CorrelationId of the response message.
First, open the response queue. Then pass that object to the set reply-to method on the message. That way the service responding to your request knows where to send the reply. Typically the service will copy the message ID to the correlation ID field so when you send the message, take the message ID you get back and use that to listen on the reply queue. Of course if you use a dynamic reply-to queue even that isn't neessary - just listen for the next message on the queue.
There's sample code that shows all of this. If you installed to the default location, the sample code lives at "C:\Program Files (x86)\IBM\WebSphere MQ\tools\jms\samples\simple\SimpleRequestor.java" on a Windows box or /var/mqm/toolsjms/samples/simple/SimpleRequestor.java on a *nix box.
And on the off chance you are wondering "install what, exactly?" the WMQ client install is downloadable for free as SupportPac MQC71.
I'm sending a message from an SNS topic to an SQS. When I'm checking the body of the SQS message on my client, the whole of the message metadata is being sent in the SQS body.
I.E. if I'm sending a message "Hello World" from the topic, my client is receiving:
BenFlowers {
"Type" : "Notification",
"MessageId" : "84102bd5-8890-4ed5-aeba-c15fafc926dc",
"TopicArn" : "arn:aws:sns:eu-west-1:534706846367:HelloWorld",
"Message" : "hello World",
"Timestamp" : "2012-06-05T13:44:22.360Z",
"SignatureVersion" : "1",
"Signature" : "Qzh0qXhijBKylaFwc9PGE+lQQDwHGWkIzCW2Ld1eVrxNfSem4yyBTgouqGX26V0m1qhFD4RQcBzE3oNqx5jFhJfV4hN45FNcsFVnmfLPGNUTmJWblSk8f6znWgTy8UtK9xrTeNYzK59k3VJ4WTJ5kCEj+2vH7sBV15fAXeCAtdQ=",
"SigningCertURL" : "https://sns.eu-west-1.amazonaws.com/SimpleNotificationService-f3ecfb7224c7233fe7bb5f59f96de52f.pem",
"UnsubscribeURL" : "https://sns.eu-west-1.amazonaws.com/?Action=Unsubscribe&SubscriptionArn=arn:aws:sns:eu-west-1:534706846367:HelloWorld:8a3acde2-cb0b-4a56-9b9c-b75ed7307556"
}
This is a bit annoying as I am having to split the message body up on the other end. Speed is pretty important in this application so i would like to eliminate this. Is there any way to just send the message from the SNS and ignore the rest of the metadata?
Thanks,
Ben
SNS recently rolled out a feature that allows you to set 'raw message delivery' on an SNS topic.
http://docs.aws.amazon.com/sns/latest/dg/large-payload-raw-message.html
SNS limits the message size to 8KB, so there's no way to go around this problem using this service.
You could just send your message directly to SQS queue, where the limit is 64KB.
If your issue is the speed of reception of the messages you put in the queue, you could use SNS to notify the client it's time to make a request to SQS for messages to receive.