Java Multiple selectors in multiple threads for non-blocking sockets.

Question

I am writing a Java application that will create class objects to represent clients that are connected and registered with an external system on the other side of my application.

Each client object has two nested classes in it, which are interface and external. the interface class will continuously receive data from the actual client and send readings and data to the base class, which will receive this data from the external interface and send it to the external system using the appropriate format and protocol this system requires.

In design, we want every instance of the client object to be a stream. Then, in each stream, there will naturally be two [EDIT] sockets with their own NIO channels each [/ EDIT], one client, one system, located in the front and back, respectively. However, now this indicates the need for non-blocking sockets. I read a tutorial here that explains how to safely use a selector in the main thread to handle all streams with a connection.

But I need several selectors, each of which works in its own thread. From reading the aforementioned tutorial, I learned that key sets in a selector are not thread safe. Does this mean that individual Selectors created in their own repressive streams can create conflicting keys if I try to give them each of my pair of sockets and channels? Moving the selector to the main stream is a small opportunity, but far from ideal, based on the software requirements that have been given to me. Thank you for your help.

Answer 1

Using multiple selectors will be great if you do not register the same channel with the same interests (OP_READ / OP_WRITE, etc.) with selector instances. Registering the same channel with multiple instances of the selector can cause a problem when selector1.select () may use an event that might interest selector2.select ().

The default selectors on most platforms are poll () [or epoll ()]. A.

Selector.select internally calls the int poll( ListPointer, Nfdsmsgs, Timeout) method.

  where the ListPointer structure can then be initialized as follows: list.fds[0].fd = file_descriptorA; list.fds[0].events = requested_events; list.msgs[0].msgid = message_id; list.msgs[0].events = requested_events; 

However, I would recommend using one selected stream, as indicated in the ROX RPC nio tutorial. NIO implementations are platform dependent, and it is possible that what works on one platform may not work on another. I also saw problems in the younger versions. For example, AIX JDK 1.6 SR2 used a poll () based selector - PollSelectorImpl and the corresponding selector provider as PollSelectorProvider, our server worked fine. When I switched to AIX JDK 1.6 SR5, which used an optimized selector based on the polling interface (PollSetSelectorImpl), we often met on our server in select () and socketchannel.close (). One of the reasons I see it is that we open several selectors in our application (as opposed to the ideal theme selection model) and implement PollSetSelectorImpl, as described here .

Answer 2

If you need to use this connection with one socket, you need to separate the process of receiving and writing data from and to the channel from the data processing itself. You must not delegate the channel. The channel looks like a bus. The bus (the only thread controlling the channel) must read the data and write it to the (thread safe) input queue, including the required information, so your client threads (s) can select the correct packet of datagrams from the queue. If the client stream likes to write data, this data is written to the output queue, which is then read by the channel stream to write data to the channel.

Thus, from the concept of exchanging communication between participants using this connection, with their unpredictable processing time (which is the main reason for blocks), you move on to the concept of reading asynchronous data, processing data, and writing data. Thus, this is not processing time, which is unpredictable anymore, but the time your data is being read or written. Non-blocking means that the data stream is as constant as possible, despite the fact that time is required to process this data.