JXSE从v2.5版开始使用nio处理网络消息，并且在其内部使用了非阻塞形式，如下面这个帖子所说
JXSE provides two primary low-level message transports; TCP and HTTP. In the vast majority of cases, even for peers which are behind NAT and firewalls, the TCP message transport is used because it offers the best performance, lowest overhead and lowest latency. The HTTP message transport is used only when it not possible for a peer to open outbound TCP connections to other peers. Since the TCP message transport is so critical to JXSE we chose to focus on improving it for 2.5.
The refactoring of the TCP message transport was begun and has been spearheaded by Mohamed Abdelaziz (hamada). He started the job by replacing all of the traditional java.net.Socket blocking I/O with a non-blocking java.nio.SocketChannel implementation. This initial work enabled us to start to look at the remaining bottlenecks, opportunities and challenges. A number of JXTA developers found hamada's contribution interesting and exciting. Even at this early point it managed to attract my attention as well as Henry Jen (slowhog), Roger Karis (malveaux) and others. slowhog contributed bug fixes and improvements based upon testing the code running on the JXTA public rendezvous servers. I contributed optimizations and a refactoring of the WireFormatMessageFactory and the binary message format to improve performance. malveaux, as usual, contributed his keen analysis and insight to help solve more than a few gnarly problems.
One of the new features and advantages of the new NIO based TCP message transport is much better use of Java Threads. We no longer require nearly as many threads per Socket instance and make extensive use of java.util.concurrent.Executor to effectively handle messages. As the new NIO based TCP message transport became more solid it became very clear that there were significant bottlenecks in how the JXSE Endpoint processed messages. The solution was to make even further use of Executorss and perform all message processing on Executors This surgery required us to enhance the HTTP message transport, the multicast message transport (which is now a separate message transport, but that's another story) and the relay. Again it was a good all around effort with contributions from hamada, slowhog, malveaux, myself and others. Mike Cumings (mcumings) contributed significant insights regarding best-practice use of Executors.
The result of all this work is that JXSE 2.5 makes considerably more efficient use of Threads while significantly improving throughput and latency. This is particularly important for infrastructure peers such as relays and rendezvous as it enables them to handle larger numbers of clients and much more load per instance. We're quite sure that JXTA network operators are going to appreciate this change.
For JXTA users and applications which are heavily dependant upon the HTTP message transport JXSE 2.5 does offer some improvement by using Executors for message processing, but we haven't yet transitioned the message transport to use NIO. Some early explorations have begin looking in to using the Grizzly HTTP server but we're still looking for contributors (especially those with Grizzly experience) to step forward and get something working. It also seems that some additional code sharing is possible between message transports by using the low-level Grizzly APIs. Contributors to investigate this opportunity are also eagerly sought!
The NIO based TCP message transport is a significant addition to JXSE 2.5 and probably provides the most dramatic change to the profile of JXTA applications of all the changes in JXSE 2.5. It is not a change though that's directly visible to applications in terms of new APIs or functionality. Future articles will look at some of the other changes in JXSE 2.5 and their benefits to JXTA application developers and users.
可是我们在基于JXSE开发的时候，是否也能使用非阻塞io？在JXSE提供的两种高级的通信方式中（JxtaBiDiPipe/JxtaSocket），没有发现相应的方法可以实现。