I am making an application that will work much like a real time chat. A user will be constantly writing on lets say a text area and messages will be send to other users. On the communications class I have set up a receiver. When a message from someone reaches the client, the receive method will be invoked and will get the message. What I can't understand is how the code will be executed. What happens if, while the user is typing/sending a message the receive message is invoked ? What do I need to do in order for this to work properly ?
Hope the question is clear enough.
ps : Im still in the design phase thats why I haven't tested it to see what happens.
Also atm I only use a second thread to receive messages which calls the receive method.
There should not be a problem at all.
When a message from someone reaches the client, the receive method
will be invoked and will get the message. What I can't understand is
how the code will be executed?
You should have a Receiver class that will encapsulate a socket (from which your receive data) and keep a set of listeners (see Observer pattern). A GUI can be one of the listeners. When a message is received via the socket, you need to notify all listeners by forwarding the data received. This way, you have a clean and nice way to notify the GUI about new messages arrivals.
What happens if, while the user is typing/sending a message the
receive message is invoked ?
This depends on the type of IP protocol you are using but in general your don't have to worry about this although I suggest you protect your sockets using lock mechanisms.
What do I need to do in order for this to work properly ?
Here is a nice example that can give you some inspiration :)
EDIT: As for your question regarding execution flow, sending and receiving are two different and uncorrelated operations that can happen at the same time. This can be achieved by implementing send and receive operations in two different threads. Here is an article on socket communications and multithreading.
You should either do what traditional Java EE app servers have done, which is assign a separate thread for processing each incoming message, or try a Java NIO solution along the lines of Netty.
Related
I'm using this code to send and receive Java Object.
TransactionsBean reply = (TransactionsBean) processingTemplate.convertSendAndReceive(EXCHANGE_PROCESSING,
ROUTING_KEY_PROCESSING_TRANSACTION, obj);
I'm thinking is there a need for implementing publisher confirms? Is it better to extend the code in order to ensure reliable delivery or I can just ass try catch block and with replyTimeout to resend again the object? What would be the better approach?
They really represent two different things.
A publisher confirm simply means the message was successfully routed to the queue by the destination.
Not receiving a reply can be for many reasons
the message wasn't delivered to a queue
the server is not running
the server has had some failure
Resending for the latter two cases might not make sense.
So it all depends on your use case.
I'm trying to implement receive exit in java as proposed here:
http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.0.1/com.ibm.mq.csqzaw.doc/jm11171_.htm
// This method implements the receive exit interface
public ByteBuffer channelReceiveExit(MQCXP channelExitParms,
MQCD channelDefinition,
ByteBuffer agentBuffer)
{
// Complete the body of the receive exit here
}
I see that exit method is called, and following documentation I expect agentBuffer to contain data of incoming message. But agentBuffer appears to be null everytime, so that I see no way to affect the message data.
Any clue would be appreciated.
UPD
I was wrong about agentBuffer is always null, it is not. Following T.Rob answer I managed to catch several calls with MQCXP.ExitReason = 14 (MQXR_XMIT).
With one of these calls I receive message data in buffer, and it looks possible to modify such data.
But still, there is a problem with other calls, having the same ExitReason, but not corresponding to any real message transmission. I need to skip such calls, but yet have no idea how to distinguish them.
Any idea how can I do it?
There are several kinds of channel exit in MQ. The MCA channels (QMgr-to-QMgr) make an exit point available when the entire message is in the buffer. This exit point invokes the Message Exit. All channels, MCA and MQI (client), make Send/Receive exit points available. The Send/Receive exit points are exercised any time that a transmission from one channel agent to another is invoked.
In the case of client channels, the receive exit may be invoked for flows that do not include message transport, or they may be invoked many times for a single message. It is up to the program to check the MQCXP structure to determine the API call that is flowing over the client channel and whether the agent buffer should or should not contain anything at that point in time.
Note that Send and Receive exits normally work in pairs. Since the queue manager does not invoke Java programs from the MCA, any corresponding Send or Receive exit on the queue manager's side would be written in C.
See the manual page on Channel send and receive exit programs for more info.
Coding an exit in MQ is extremely difficult and requires an indepth knowledge of MQ. A SVRCONN/CLNTCONN channel pair has bi-directional traffic flow on it and you do NOT see the whole message (unless it is less than 32758 bytes). What you see in a channel send/receive exit are Transmission Segment Header (TSH) messages. Note: TSH messages are NOT documented by IBM!!!
The MCA (Message Channel Agent) invokes a channel send/receive exit for various 'ExitReason' defined by MQXR_***.
But agentBuffer appears to be null everytime, so that I see no way to
affect the message data.
That is because you do not understand MQ nor the flow of the bidirectional channel. You do realize that the TSH messages are in binary not plain text!?! Right? Are you dumping/printing the buffer in HEX or doing System.out.println?? If the latter then see my first sentence in this post.
Use a debugger and view the TSH data. Please don't ask why you are looking at weird stuff as I said, TSH messages are NOT documented by IBM! If you want information then go look at the code for Wire Shark as they have reverse engineered the TSH messages.
Finally, why are you writing a channel send/receive exit as there are many other ways to accomplish looking at message flow than using an exit.
i'm working on an Java client-server application.
The client send a message sequence (the messages can be different types, i,ve got header), and listens for the replies. I've got 2 thread, one for the transmission and one for the receipts.
So i need to handle the replies, in case of errors or in case of the replies doesn't arrive, for example i can try to send the message another time.
My question is.. is there any java patterns that can helps me?
i would like to handle the send and the relative repliy like a single transaction, but note that i don't need to have a synchronous communication. I send all the message in the sequence in the TX thread and wait for the replies on the RX thread.
I've thought to the mediator Pattern, but i don't know if it is the right way.
Thanks
If the question is purely about transmission protocol I would take a look at NAK. http://en.wikipedia.org/wiki/NAK_(protocol_message)
I have implemented a protocol I made up called JCast that sends files over multicast. The files are broken down into small fragments that are numbered. The receiving clients then respond back with any missing fragments that it did not get (these are the NAK's). The server then would resend only the NAK'd fragments.
EDIT: The benefit of NAK over ACK is that the server can send all the packets it needs to without having to wait for ACK's. Since networks are very much improved nowadays, most of the packets would arrive. The few that do not arrive would then just be resent.
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.
I dont know how to implement the queue messaging in smslib, I receive a new sms and I store in a database table, I make some logic and then I produce a new sms, I already archieve this
-synchronous way, but I dont know how to do it in asynchronous way?? can someone guide me or maybe a hint, I see the docs but I dont know how to make the queue since I am receving and sending sms???, I need to run this app and I want that every user gets an answer, for example
I use the method Service.getInstance().queueMessage(msg); but It did the same as Service.getInstance.sendMessage(), so my question is how to use the queue in smslib??
can someone guide me on this??
The sendMessage() and queueMessage() methods both send the messages through your modem, but there is fundamental difference; sendMessage() does it synchronously and queueMessage() does is asynchronously (as you said yourself).
This means that sendMessage() will basically forward the message to the modem, block it until the message is sent, and then return.
If you however are using the queueMessage() method, it will store the message in a queue and the send it "when it can", without blocking the modem.
To get the send status from this message (if it was sent or not, any errors etc) you need to make a class that implements the IOutboundMessageNotification interface. There, in the process method, you get the status message and you can handle it according to you own implementation.
You set you service to "listen" to these notifications using Service.getInstance().setOutboundMessageNotification(outboundMessageNotification);.
The same applies if you want to listen to incoming messages using IInboundMessageNotification.
Hope it helped
-Rob