-
1. Re: Remoting 3 - requirements
My feeling is we shouldn't duplicate effort on this one.
We have an urgent need for a NIO transport, but we don't need all the bells and whistles of a generic framework like remoting.
I would rather us write our own specific transport in a few weeks then contribute that back to the remoting project where you can add the extra bits and shiny bells and buckles.
My feeling is that if you start trying to create an all singing dancing NIO framework now this is going to take too long for us which introduces a major risk for us.
Wdyt? -
2. Re: Remoting 3 - requirements
Isn't NIO solely a performance optimization? If so, why is it on your critical path? Can't you be doing other things while Tom, et al. are doing this?
-
3. Re: Remoting 3 - requirements
Tim, I think you should do what you think is right for messaging.
As purely personal opinion, I think that remoting should move to a messaging based model (compared to being solely RPC based) for remoting 3. I also think that if this to be the case, remoting should do its best moving forward to support behavior/features other project might need so they can use remoting without having to write/maintain that same code internal to their projects.
Of course, this means that end result of remoting 3 would have to be compelling enough (i.e. all the features, behaviors, performance, etc.) that other projects would be willing to adopt it. In order to do this, the remoting team HAS to know and understand the requirements other project have. This why I started this thread.
As far as NIO goes, the only real performance gain in using NIO is when you have a very large number of concurrent connections being processed since it does not require a thread per connection and the associated overhead of thread context switching.