I would like to write a method which handles the flow of communication on XMPP. The sequence of things I'd like to do is:
Send message.
Wait for response.
Process the response.
Since we could be waiting longer than 30s for the response (step 2) I'll be teeing up a task to take care of this. This task will need to send the message and then wait for a response on the XMPP servlet handling the incoming message. My question is: How do I wait in the task servlet thread for the response to arrive in the XMPP Servlet?
I'd normally use a listener pattern where the listener would store the message in a field in the Task object and then trigger a Semaphore to signal that a message has arrived. Like this:
Install listener in XMPP servlet in a static field.
Send message.
Wait for semaphore. ........ Meanwhile, in the XMPP servlet thread, a response will arrive and it will call the listener's callback method which stores the message and releases the semaphore.
Get message from field and process.
I tried this and it worked fine on the development server. However, when I uploaded to the cloud I found that I'd install the listener on the XMPP servlet (step 1) but then a new instance of the servlet would be instantiated when the message came in and there would no longer be a reference to the listener to call, event through the listener is a static field. My conclusion is XMPPServlet is run in a completely different VM meaning the static field is not shared between that servlet and the task one. Is this correct?
In general what is the best practice for communication between these servlets? How to I share data (normally I would've stored it in an object's field) and how do I signal from one to the other when events occur (normally I would've used a semaphore)?
Sorry about the long winded question. Tell me if it's not clear and I'll refine it a bit.
Reposting my answer to the same question you asked on the mailing list:
You can't [wait for a response in the sending process]. Instead, you
should use an asynchronous pattern: Send the message, and register a
handler for incoming XMPP messages. That handler should match up the
response to the corresponding request (stored in the datastore if
necessary) and perform appropriate processing on it.
An App Engine app can be run on any number of machines;
synchronization primitives designed for communication between threads
will not work.
Related
I have a queue and I have this consumer written in java for this queue. After consuming, we are executing an HTTP call to a downstream partner and this is a one-way asynchronous call. After executing this request, the downstream partner will send an HTTP request back to our system with the response for the initial asynchronous call. This response is needed for the same thread that we executed the initial asynchronous call. This means we need to expose an endpoint within the thread so the downstream system can call and send the response back. I would like to know how can I implement a requirement like this.
PS : We also can get the same response to a different web service and update a database row with the response. But I'm not sure how to stop the main thread and listen to the database row when the response is needed.
Hope you understood what I want with this requirement.
My response based on some assumptions. (I didn't wait for you respond to my comment since I found the problem had some other interesting features anyhow.)
the downstream partner will send an HTTP request back to our system
This necessitates that you have a listening port (ie, a server) running on this side. This server could be in the same JVM or a different one. But...
This response is needed for the same thread
This is a little confusing because at a high level, reusing the thread programmatically itself is not usually our interest but reusing the object (no matter in which thread). To reuse threads, you may consider using ExecutorService. So, what you may try to do, I have tried to depict in this diagram.
Here are the steps:
"Queue Item Consumer" consumes item from the queue and sends the request to the downstream system.
This instance of the "Queue Item Consumer" is cached for handling the request from the downstream system.
There is a listener running at some port within the same JVM to which the downstream system sends its request.
The listener forwards this request to the "right" cached instance of "Queue Item Consumer" (you have to figure out a way for this based on your caching mechanism). May be some header has to be present in the request from the downstream system to identify the right handler on this side.
Hope this works for you.
The scenario is the sending of a password reset mail to the user from a web request (and possibly other mail related tasks in the future).
The arguments I bring to the table for queuing:
I believe web requests should be handled as fast as possible
Decoupling the send action from the request, more easily allows externalization of the mail system (if required in the future)
The arguments I recognize against queuing:
The user does not get feedback if something goes wrong during the sending of the message
What are more arguments in this discussion? And to those in favor of queuing, how would you implement the queue? Scheduled action? Infinite dequeuing task (with interval, of course)?
Thanks!
I would suggest you to decouple actual sending of mail from your app business logic.
Do this asynchronously: Use queue or at least different thread for sending such notifications.
Sending of email could be time consuming operation,
even if you use your own internal mail server which is close to your app.
SMTP conversation consists of several requests/responses.
Do not treat sending of a mail as a transactional action.
When target SMTP server replies with 250 OK as a response for DATA command - it just takes responsibility for this mail nothing else.
Delivery could fail in future if next server in the chain is not able to deliver mail (read about DSN, aka bounce).
Last but not least think about failure modes.
What if your business critical functionality is slowed down / blocked by auxiliary one (email notification), not good I guess.
You definitely don't want to do the send synchronously since the mail server may be slow.
Send a JMS message and use an MDB to send the email.
In a Java EE 6+ scenario you can use #Asynchronous annotation in a EJB method. It returns a Future<V>. So you can continue with proccesing and ask later for task ending, while it is executed in another thread.
So you can accept a lot of request fastly, you decouple the send action from request, and you can get feedback.
http://docs.oracle.com/javaee/6/tutorial/doc/gkkqg.html
You may think that requests should be serviced as fast as possible, but what about the user? What does he think?
The user needs his password reset. He doesn't care how long that takes. If he can't complete that request he can't do anything at all.
Don't queue.
I think u should go to queue. Because it help in fast performance and to check whether the password reset request is arrived from correct source.
So u can use Map for queue implementation. Because in map u can use email id as key and a unique request reference as value. And this map element should be deleted within a time period.
Also for fast email service u can create a simple thread class that send emails and start a new thread by passing some data arguments in it. and scheduling will automatically managed by web container for these threads.
This question refers to writing an application that communicates with the NXT block on a lego mindstorms robot.
What I want to do
NXC (not exactly C, a language for writing programs for the NXT) supplies a function until(condition) that waits until condition evaluates to true. I want to implement this using the bluetooth messaging protocol, talking to the NXT via bluetooth from an android application.
What I can do so far:
I'm able to send an input query message (getInputValue(int in)), which sends a message to the NXT asking for the current status of the input in. The NXT then sends back a message with this information, which is then written to a global variable that holds the most recently asked input value (let's call it myValue).
What the problem is:
I'm using bits and pieces from the lego MINDroid application - in this class I have a separate communication thread which handles direct communication with the NXT. When it receives a message, it forwards it on to the main thread, via a Handler. The problem occurs when I try to busy wait for a reply - doing:
while(myValue != valueIWant) {
sleep(100);
getInputValue(in);
}
ends up busying the main thread, so that the handler never actually gets to receive any messages. The communication thread receives the messages from the NXT, forwards them to the main thread, but the handler never gets called because it's doing other stuff.
What's the best way to get around this? I can't get the thread to wait in any way because that would stop it receiving messages also :(
Any suggestions would be appreciated! I'll also happily elaborate on any bits of code.
Links that may be useful
http://bricxcc.sourceforge.net/nbc/nxcdoc/nxcapi/main.html
http://github.com/NXT/LEGO-MINDSTORMS-MINDdroid
http://mindstorms.lego.com/en-us/support/files/default.aspx (for the bluetooth docs)
Solved, using callbacks :) Happy to elaborate if needed.
Edit: (sorry for late reply!)
I ended up implementing a callback procedure, where I attached a 'callback' function to some list. When the handler receives a message, it would look in the list of callbacks and see if the message received matched any of the callback functions that are present - if so, it would execute the method inside the callback.
I then made a class around these callbacks, where I could create execution queues (doA; doB; doC;) and it would wrap those up into a callback chain (callBack({doA; callBack({doB; call...})})), which gave the impression that I was operating in a synchronous environment, when in fact it was operating asynchronously.
Some background information. This is a distributed application with multiples nodes. A 'communication' thread sends and receives all messages sent between these nodes. This cannot be changed.
A 'doStuff' thread asks the 'communication' thread to send a message to a node. It then needs to wait for a response from the other node. The 'communication' thread will receive this response message. It then needs to deliver this message to the correct 'doStuff' thread.
I am unsure what sort of information needs to be stored at the node or within the message to ensure that the correct thread always receives the response message.
Looking for some advice upon how to achieve this. Thanks for reading :)
You probably want to attach some sort of message id to the outgoing message to be included in the response. A sequential number or a UUID would probably do the job. Your communicator thread can then keep track (a map?) of what "doStuff" thread was waiting for a given response and pass it back.
You could also keep track of when the request was sent so that if a response isn't received the communicator thread can notify the doStuff thread that the response wasn't received.
It doesn't seem very difficult
Use either a thread id, or other opaque token invented by the doStuff thread which is stored by the Communication thread (mapped to the calling thread id) and returned with the response The communication thread looks it up in the Map to identify the corresponding thread.
Or am I missing something?
Is using JMS an option at all? If so, you might find that more practical than doing "roll your own." Asynchronous message passing, in general, is a solved problem. If JMS is an option, look at TopicRequestor and/or QueueRequestor in particular.
I wanna build server socket emulator, but I want implement some design pattern there.
I will described my case study that I have simplified like these:
My Server Socket will always listen client socket. While some request message come from the client socket, the server emulator will response the client through the socket.
the response is response code. '00' will describe request message processed successfully, and another response code expect '00' will describe there are some error while processing the message request.
IN the server there are some UI, this UI contain check response parameter such as.
response code
timeout interval
While the server want to response the client message,
the response code taken from input parameter response form UI
check the timeout interval, it will create sleep thread and the interval taken from timeout interval input from UI.
I have implement the function, but I create it in one class. I feel it so sucks.
Can you suggest me what class / interface that I must create to refactor my code.
The need to refactor the code really depends on what task your server is performing based on the client request. If it is something simple then a single class may very well be the best design. If it is doing something more complicated then you may want to move the various operations that can be performed to various service classes. If your results are standard you could create an object (maybe enum?) to describe them.
This is the approach I have taken in one of my own applications. The server handles essentially only the IO between itself and the client. When the client sends a message the server parses it into a standard format "operation" object. This object is then passed to manager object which finds an appropriate "request servicing object". This object then does the actual work. When it is finished it generates a return object that describes the status/ results of the object. This is then taken by the server and formatted in an appropriate manner to send across the wire to the client.
Hopefully this can give you some ideas as to what might be appropriate for your application.