On 24 Apr 2012, at 12:40, Mircea Markus wrote: > > 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 :-)
Well, a lot cleaner while still being asynchronous… :) -- Manik Surtani [email protected] twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org
_______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
