Is all of this conversation just to avoid using a lock? The simplest thing to synchronize the non io processor with an external thread would to use a lock.
On Thu, Feb 14, 2019 at 1:07 PM Emmanuel Lécharny <elecha...@gmail.com> wrote: > > On 14/02/2019 17:28, kevintjuh93 wrote: > > Yes, I am aware that's what happens. And in these cases I can make it > execute > > at the end of a messageReceived. But my case is that I do something from > a > > non io-processor thread, but what it does needs to be synced with the > > io-processor. > > Ok, now that makes sense to me. > > The thing is that a session is really tied to a socket, so there is no > obvious way to send an event to this session. The IoProcessor thread is > really used only when a SelectorKey is receiving an event, and we can't > create such an event. > > There is something you can do though: there is an idling mechanism that > can be used to send an event to the IoHandler every second (this is not > configurable), and you can probably leverage that. When the sessionIdle > event is processed, you can check if there is something to due in a > queue that your external thread has filled in. > > This is kind of a hack though... > > Another possibility would be to get the list of managed sessions from > your service with the IoService.getManagedSessions() method, but there > is a limited set of actions you can do on a session: write or set an > attribute. > -- CONFIDENTIALITY NOTICE: The contents of this email message and any attachments are intended solely for the addressee(s) and may contain confidential and/or privileged information and may be legally protected from disclosure.
