> > The reason I ask is that at some point we should look at not only an NIO impl (I know you had one that you experimented with some while back) but also a JDK7 NIO2 one, and benchmark the three. Agreed. I'd expect an NIO/NIO2 client to handle much better the async requests from client to the server than the current IO client which is optimised for sync operations.

On 24 Apr 2012, at 12:25, Manik Surtani wrote: > > On 24 Apr 2012, at 09:25, Mircea Markus wrote: > >>> >>> The reason I ask is that at some point we should look at not only an NIO impl (I know you had one that you experimented with some while back) but also a JDK7 NIO2 one, and benchmark the three. >> >> Agreed. I'd expect an NIO/NIO2 client to handle much better the async requests from client to the server than the current IO client which is optimised for sync operations. > > I was just wondering because the entire stack could be async, all the way from API call to network transport, and the network future appropriately wrapped and returned as a return value to the client. If a sync API is called, just delegate to the async operation and call get() once on the compound future. Should make for a very clean and high performance client. With NIO the async path should be faster indeed, but would affect the sync path as there would be a point in which client threads are blocked waiting for the transport thread (inter thread com). Instead of waiting they could do the work interaction themselves and avoid the passing of requests/responses for one thread to the other.

Performance wise, I don't think NIO would overtake IO for for *sync* calls but it will for *async* calls. Also code wise, I don't think it would be simpler, just because of NIO's model and inter thread communication. But I think a NIO client would be of interest especially when using the clients in async mode. And performance wise for sync clients - we might see different numbers than what I expect.

On 24 Apr 2012, at 14:13, Manik Surtani wrote: > > On 24 Apr 2012, at 11:39, Mircea Markus wrote: > >> >> On 24 Apr 2012, at 12:25, Manik Surtani wrote: >> >>> >>> On 24 Apr 2012, at 09:25, Mircea Markus wrote: >>> >>>>> >>>>> The reason I ask is that at some point we should look at not only an NIO impl (I know you had one that you experimented with some while back) but also a JDK7 NIO2 one, and benchmark the three. >>>> >>>> Agreed. I'd expect an NIO/NIO2 client to handle much better the async requests from client to the server than the current IO client which is optimised for sync operations. >>> >>> I was just wondering because the entire stack could be async, all the way from API call to network transport, and the network future appropriately wrapped and returned as a return value to the client. If a sync API is called, just delegate to the async operation and call get() once on the compound future. Should make for a very clean and high performance client. >> With NIO the async path should be faster indeed, but would affect the sync path as there would be a point in which client threads are blocked waiting for the transport thread (inter thread com). Instead of waiting they could do the work interaction themselves and avoid the passing of requests/responses for one thread to the other. > > Well, I think all network IO is async by nature so if we take advantage of this from the start, even sync calls would be faster. E.g., even with OIO, we write bytes onto the operating system's TCP stack and then wait for a response and get notified by the OS. So, async, really. ;) As I said, the results might look different once we benchmark. From what I've discussed with Trustin when I implemented the client, IO was a better fit than NIO for *sync* clients and intuitively I can see why. > >> Performance wise, I don't think NIO would overtake IO for for *sync* calls but it will for *async* calls. Also code wise, I don't think it would be simpler, just because of NIO's model and inter thread communication. But I think a NIO client would be of interest especially when using the clients in async mode. And performance wise for sync clients - we might see different numbers than what I expect. > > Let's whiteboard this up at some point, I bet if we assume everything is async, the design can actually be a lot cleaner. Passing resources between threads can be clean too, by using event handlers. the design for current hr client is quite clean imo, "a lot cleaner" seems to imply otherwise. But let's do it and see :-)