Even though I called BytesXMLMessage.setDeliverToOne(false), I noticed that Requestor.request(XMLMessage request, long timeoutMillis, Destination sendDestination) will just return immediately when a reply is received from any one of the producers. I just wonder how I can wait for all producers to reply.
Requestor.request() is used for a single request and reply, and is expected to return after the first reply message is received.
You will need to implement your own logic to receive multiple replies to a single request.
You can do this by doing something like the following:
Subscribe to a well-known topic for replies.
Publish the request message, with the reply-to field set to the well-known reply topic.
Receive replies on the well-known reply topic that you have subscribed to in (1).
Related
I would like to be able to catch messages going to my GenServer's handle_info in tests, to check those are what I intend to.
1/ Is there a way to print somehow every message coming through?
2/ Using assert_receive is there a way to catch those messages? Should I set the assert_receive before or after the call to the external service that will result in the handle_info trigger? What syntax should I use?
I tried many combinations of assert_receive and I tried a receive do... to try and display messages getting in, with no success.
Both ExUnit.Assertions.assert_receive/3 and ExUnit.Assertions.assert_received/2 do assert messages coming into the current process’ mailbox. The former is to be called either before or after the message was actually sent:
Asserts that a message matching pattern was or is going to be received within the timeout period, specified in milliseconds.
the latter is to be called after:
Asserts that a message matching pattern was received and is in the current process’ mailbox.
That said, both are unlikely a good fit to test the existing GenServer. Messages are to arrive at the GenServer’s messagebox, this functionality is provided by OTP and you should not test it. If you need to log messages, add a call to Logger.log/3 to the handle_info/2 and check the log actually happens with ExUnit.CaptureLog.capture_log/2. If it performs some action upon message arrival, test this action.
In general, you should test your code, not OTP.
Using Microsoft Graph, how can I determine which message an outgoing message is a reply to?
The internetMessageHeaders property is not available for items in the Sent Items folder of mailboxes (using the Graph API, at least -- they are available using EWS or IMAP). If it were, I'd look for the in-reply-to header. In the absence of this, is there something in the standard Graph message properties that will tell me this?
You can check the "Subject" or "bodyPreview" to check if the content contains "RE:", if the answer is yes, the message is reply to.
You can group the message by conversationId and then order by lastModifiedDateTime. This way can check if the message is the original one, if it is not ,it will be reply-to/follow-up one.
Get the message list first(/me/messages or /users/{id | userPrincipalName}/messages and so on), and then foreach the message id to call reply api(/users/{id | userPrincipalName}/messages/{id}/reply and so on). The result in the reply is a reply to.
To Test this, you can use the Graph Explorer first and then paste the JSON to a JSON viewer tool. For further use, you need to use net/java and so on to handle.
API reference: https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/resources/message
https://developer.microsoft.com/en-us/graph/docs/api-reference/v1.0/api/message_reply
Here is my requirement: I receive a request to validate some data/records. Records would be sent to the SQS queue per each request for further processing by another service/component. The message structure looks like this:
messageId: //a unique message id
requestId: //request id common between all messages/records for that request
record_body: {//key-value pairs}
Everything works fine. Now I want to figure out when all messages with the same request id have been read from the queue (I.e. there is no more message for that request id).
The idea that I have is to write each message/record to the database upon each read and then have another scheduled service that can be triggered (by cloudwatch) to check the number of records for each request and finally update the status of the request to complete if the number of records in the database are equal to the number of records in the original request.
I just want to share this to see if anybody else had this kind of requirement and how they approached it!
How about this ?
Include the number of requests and current request to the queue. Make sure the request goes to the queue in the same order.
Example - You have 4 requests for requestId - abc
You will send each request with values included (1:4) (2:4) (3:4) (4:4) in the order to the queue.
This way when you are reading from the queue you will read (4:4) last and you will know you have processed all the 4.
Another way to do is include total number of requests in the message in every message and while processing each message check whether it matches the original one as you have total in your message now. (by querying the database).
I am sending a voice message via Twilio and specifying a callback url for all the statuses but I don't think it is actually getting called because I have not been able to find out what the call back file is supposed to look like. What does the callback file look for? Is it a form being sent in? What does my "callbackfilename" code look like? I cannot find that info anywhere. thanks
These are my params:
params["StatusCallback"]= "http://XXXX.com/events/callbackfilename";
params["StatusCallbackMethod"]="POST";
params["StatusCallbackEvent"]="initiated";
params["StatusCallbackEvent"]="ringing";
params["StatusCallbackEvent"]="answered";
params["StatusCallbackEvent"]="completed";
params["IfMachine"] = "Continue";
Twilio developer evangelist here.
The StatusCallback comes much the same as a TwiML request for an incoming calls. It's sent as form encoded data (application/x-www-form-urlencoded) and includes all the regular parameters sent in an incoming call request.
You also get a bunch of bonus parameters, listed here. You can see those parameters below too:
CallStatus A descriptive status for the call. The value is one of queued, initiated, ringing, in-progress, busy, failed, or no-answer. See the CallStatus section for more details.
CallDuration The duration in seconds of the just-completed call. Only present in the completed event.
RecordingUrl The URL of the phone call's recorded audio. This parameter is included only if Record=true is set on the REST API request and does not include recordings from <Dial> or <Record>. RecordingUrl is only present in the completed event.
RecordingSid The unique ID of the Recording from this call. RecordingSid is only present in the completed event.
RecordingDuration The duration of the recorded audio (in seconds). RecordingDuration is only present in the completed event.
Timestamp The timestamp when the event was fired, given as UTC in RFC 2822 format.
CallbackSource A string that describes the source of the webhook. This is provided to help disambiguate why the webhook was made. On Status Callbacks, this value is always call-progress-events.
SequenceNumber The order in which the events were fired, starting from 0. Although events are fired in order, they are made as separate HTTP requests and there is no guarantee they will arrive in the same order.
If you want to check these parameters and that they're getting sent, you could set up something like a RequestBin which records the requests so that you can inspect them easily.
Let me know if this helps.
What I'm trying to do:
Be able to have users subscribed to a number of different 'chat rooms' and use reverse AJAX / comet to send messages from a chat room to everyone logged into that room. (a bit more complicated but this is a similar use case).
What I'm doing:
Using Grails with JMS and Atmosphere. When a message is sent, I'm using JMS to send the message object which is received by a Grails service which is then broadcasted to the atmosphere URL (i.e. atmosphere/messages).
Obviously JMS is a bit redundant there but I though I could use it to help me filter who should retrieve the message although that doesn't really look it'll work (given that the subscriber is basically a singleton service...).
Anyway, what I need to be able to do is only send out a message to the correct subset of people listening to atmosphere/messages. A RESTful-type URL will be perfect here (i.e. atmosphere/messages/* where * is the room ID) however I have no idea how to do that with Atmosphere.
Any ideas / suggestions on how I can achieve what I want? Nothing is concrete at all here so feel free to suggest almost anything. I've even been thinking (based on the response to another question), for example, if I could do something like send out messages to a Node.js server and have that handle the reverse AJAX / comet part.
If I understand your requirements correctly the following should work (jax-rs + scala code):
1) Everyone who wants to get messages from a chat room registers for it:
#GET
#Path(choose/a/path)
def register(#QueryParam("chatroomId") chatroomId: Broadcaster) {
// alternatively, the Suspend annotation can be used
new SuspendResponse.SuspendResponseBuilder[String]()
.resumeOnBroadcast(false).broadcaster(chatroomId).scope(SCOPE.REQUEST)
.period(suspendTimeout, TimeUnit.MINUTES)
.addListener(new AtmosphereEventsLogger()).build
}
2) To broadcast a message for all the registered users, call the following method:
#POST
#Broadcast
#Path(choose/a/path/{chatroomId})
def broadcast(#PathParam("chatroomId") id: String) {
// first find your broadcaster with the BroadcasterFactory
BroadcasterFactory.getDefault().lookupAll() // or maybe there is a find by id?
broadcaster = ...
broadcaster.broadcast(<your message>)
}
I also recommend reading the atmosphere whitepaper, have a look at the mailing list and at Jeanfrancois Arcand's blog.
Hope that helps.
There is a misunderstaning of the concept of comet. Its just another publish/subscribe implementation. If you have multiple chat-rooms, then you need to have multiple "topics", i.e. multiple channels the user can register to. E.g.:
broadcaster['/atmosphere/chatRoom1'].broadcast('Hello world!')
broadcaster['/atmosphere/chatRoom2'].broadcast('Hello world!')
So I would advance you to creaet multiple channels and do not filter manually the set of users, which should retrieve messages (which is definitely not the way it should be done). You do not need to create anything on the server side on this, since the user will just register for a specific channel and receive messages, which anyone is putting into it.
I would recommend you create an AtmosphereHandler for one URL like /atmosphere/chat-room and then use the AtmosphereResource and bind an BroadcastFilter with it, lets say name it ChatRoomBroadcastFilter.
Whenever a user subscribes to a new chat room, a message would be sent to the server (from the client) telling the server about the subscription. Once subscribed, maintain the list of users <> chat room bindings somewhere on the server.
Whenever a message is broadcasted, broadcast it with the chat room id with it. The in the ChatRoomBroadcastFilter (You probably need to make this a PerRequestBroacastFilter) propagate the message to the user only if the user subscribed to the chat room. I am not sure if this clears it out. If you need code example please mention in the comments. I'll put that but that needs some time so ain't putting it right now ;).