Thank you, this reassure myself. One last question, what is the best way for obtaining a session from "outside" the acceptor?
Set<IoSession> sessions = acceptor.getManagedSessions(socket_address); Stefano Luceri > > Hi, > Hi, > > > > > > > > I'm using for standard client/server application since a couple of > > months but now I'm facing a problem I don't understand how to solve. > > > > I need to write a server, using mina 1.1.x, > > First of all, you should use MINA 2.0.4, unless you ave very good > reasons to stick to this ancient version (like you want it to run on > Java 1.4, which is not anymore maintained for years, btw...) > > > which listen for a single client > > connection. The client sent requests (XML over TCP), server receives > > and processes these requests in its threads, write an ACK back to the > > client and pass results to application logic. > Ok. So far, so good, as soon as you successully handle packets > fragmentation when receiving XML data. Which is not a piece of cake... > > > > The application, acting on results, needs to send messages back to > the > > client using the same session but from its own threads. > Not a problem. session.write( message ). > > > > In this scenario I see a thread concurrency problem since when > > application decides to send back message to client it's possible that > > client sent something and server is using the session. Maybe I'm > missing something ... > Yes : the session.write(message) is just pushing a bte array on a queue > to be processed as soon as the other thread (the one processing the > incoming message) is ready. When it is, the selector will be waken up, > and the IoProcessor will read the data from the queue and send it to > the client. > > > > > > > > How can I solve this kind of problem? > It's not a problem. Just write the message in the session. > > > > What kind of thread configuration do you suggest to use remembering > > I've a single client connected to the server? > Nothing to be configured there. Plain an simple : let MINA handle the > situation for you. > > > > > > > > I suppose I can share (can I?) session between threads but I've to > > lock > > session.write(...) compromising performances ... > Don't lock anything. It's already thread safe. Unless your codec is > doing weird things... > > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com
