Emmanuel Lécharny a écrit: > > Le 11/4/12 4:37 PM, Marko Asplund a écrit : > > ... > > I've done some experimenting and it seems to be possible to get a list > > of active IoSessions from an acceptor using > > IoAcceptor.getManagedSessions(). > > You can then select the correct client session(s) and write packets to > > the client using IoSession.write(myPacket). > > Would this be a valid approach for implementing a control channel? > > Yes. > > > Are there any caveats I should be aware of? In particular are the > > above mentioned APIs thread-safe? > > It depends on what you do in your encoder and decoder : if they are > stateless, then you shoudl'nt have any problem, as the message will be > enqueued in a thread safe list before being sent. Keep in mind that the > processing of a write is done by a single thread, up to this queue. > > Now, again, if you have any filter using any shared data, then it's up > to you to protect the access to those data in a multi threaded environment. > > > What about other IoSession methods, e.g. getAttribute() and setAttribute()? > > Those methods are thread-safe, assuming you don't use a fancy data > structure instead of the default one (ConcurrentHashMap). Now, that does > not mean the content is thread safe. If you use an attribute which is > shared, then be sure that it's protected against concurrent > modifications...
thanks! The procol is stateful in that packets are numbered per session. So, I've a per session thread-safe packet sequence number generator object. The sequence generator is created and placed in the IoSession in IoHandlerAdapter.sessionCreated. Then my ProtocolEncoder.encode method picks up the generator from session and the CumulativeProtocolDecoder implementation is stateless. marko
