(ServerSocketChannel) key.channel(); SocketChannel channel = server.accept(); registerChannel (selector,
do this because only ServerSocketChannel objects support the OP_ACCEPT operation. We also know our code registers only a single ServerSocketChannel object with interest in OP_ACCEPT. With a reference to the server socket channel, we invoke accept() on it to obtain a handle to the incoming socket. The object returned is of type SocketChannel, which is also a selectable type of channel. At this point, rather than spawning a new thread to read data from the new connection, we simply register the socket channel with the selector. We tell the selector we’re interested in knowing when the new socket channel is ready for reading by passing in the OP_READ flag. If the key did not indicate that the channel was ready for accept, we check to see if it’s ready for read. Any socket channels indicating so will be one of the SocketChannel objects previously created by the ServerSocketChannel and registered for interest in reading. For each socket channel with data to read, we invoke a common routine to read and process the data socket. Note that this routine should be prepared to deal with incomplete data on the socket, which is in nonblocking mode. It should return promptly so that other channels with pending input can be serviced in a timely manner. Example 4-1 simply echoes the data back down the socket to the sender. At the bottom of the loop, we remove the key from the selected key set by calling remove() on the Iterator object. Keys can be removed directly from the Set returned by selectedKeys(), but when examining the set with an Iterator, you should use the iterator’s remove() method to avoid corrupting the iterator’s internal state. 4.3.4 Concurrency Selector objects are thread-safe, but the key sets they contain are not. The key sets returned by the keys() and selectedKeys() methods are direct references to private Set objects inside the Selector object. These sets can change at any time. The registered key set is read-only. If you attempt to modify it, your reward will be a java.lang.UnsupportedOperationException, but you can still run into trouble if it’s changed while you’re looking at it. Iterator objects are fail-fast: they will throw java.util.ConcurrentModificationException if the underlying Set is modified, so be prepared for this if you expect to share selectors and/or key sets among threads. You’re allowed to modify the selection key set directly, but be aware that you could clobber some other thread’s Iterator by doing so. If there is any question of multiple threads accessing the key sets of a selector concurrently, you must take steps to properly synchronize access. When performing a selection operation, selectors synchronize on the Selector object, the registered key set, and the selected key set objects, in that order. They also synchronize on the cancelled key set during Steps 1 and 3 of the selection process (when it deregisters channels associated with cancelled keys). In a multithread scenario, if you need to make changes to any of the key sets, either directly or as a side effect of another operation, you should first synchronize on the same objects, in the same order. The locking order is vitally important. If competing threads do 151
Note: If you are looking for top 10 and very good webhost to host and run your jsp application check Actions jsp hosting services