Hi Pat, here a little explanation of the MINA mechanisms. When you close a client-side connection the underlying socket connection is closed, too. Therefore you will also lose all the session data that is stored on the server. So it isn't the right way to close and re-open the session to implement a request/reponse protocol.
Basically MINA is asynchronous so the outgoing and incoming bytes are independent in their socket stream. To implement request/response you must do this by yourself. For my project I implemented such a simple protocol. After the request is written to the session the calling thread enters a wait-Loop based on a synchronized request object and the request object is put into a hashmap where the key is a sequence number. After a response arrives the sequence id is read from the response and the originating request is looked up from the hashmap. Then the waiting thread is woken up with requestObj.notify(). Quite simple in the whole but it works fine and you can easily support parallel requests from different threads. Regards, Michael Pat Chang - 1973 wrote: > > Dear Maarten, > > Firstly, thanks for your response. I hope you dont mind my basic > questions. > > In our application we are sending a sequence of files one after the other > often through a sequence of session.write() operations. Completion of one > write() operation will then invoke the next operation to send the next > sequence. So this has to be synchronous so that we identify the closure of > the last write() before sending the next one. > > Now, yes, you are right, at the client thread is blocked until the session > is closed. This works. > > But my doubts / questions are: > > Question 1: Does closing of session mean closing of actual connection pipe > from client to server? So when I sent the next sequence, do I have to > reconnect? If yes, then this may not be the optimal way of sending data, > as we would need to reconnect every time we send the next set of > sequences. > > Question 2: I use session at the server to store additional data such as > user who has logged in and all the files that were transfered in the past. > When we close the session at the client, and reconnect, will all this data > saved in the server session be lost? > > A few "simple" code snippets on various aspects of Mina Wiki would help > the new "learning" developers like us in quickly learning to use this > great library. > > Thanks again in advance, > Pat > > > Maarten Bosteels-4 wrote: >> >> Hello Pat, >> >> On 9/4/07, Pat Chang - 1973 <[EMAIL PROTECTED]> wrote: >>> >>> >>> Can someone please answer my simple question. Would be much appreciated. >>> >>> >>> Pat Chang - 1973 wrote: >>> > >>> > Hi, >>> > >>> > We want to implement synchronous communication. >>> > >>> > After session.write(ProtocolObj); and session.join();, the thread >>> waits >>> > until session is closed. >> >> >> I guess you session.write(obj).join() since IoSession itself has no >> join() >> method ? >> The thread will wait until the message is written, not until session is >> closed. >> >>> >>> > I would prefer the session to be open, because on the server side, I >>> am >>> > maintaining the data in the server session to accept further data. >>> > Secondly, I think it may not be the optimal way to close and open >>> > connections everytime either. >> >> >> session stays open after writing to it, until you close it (unless remote >> peer closes it) >> >> Maarten >> >>> >>> > Is there a way to achieve synchronized communication which does not >>> > involve reconnecting for every request so that we can reuse the data >>> saved >>> > int he server session as well? >>> > >>> > Regards >> >> >> >> >> >>> Pat >>> > >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/Synchronous-communication-without-dropping-connection-tf4375713s16868.html#a12479878 >>> Sent from the Apache MINA Support Forum mailing list archive at >>> Nabble.com >>> . >>> >>> >> >> > > -- View this message in context: http://www.nabble.com/Synchronous-communication-without-dropping-connection-tf4375713s16868.html#a12481979 Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
