[jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Messaging and Remoting

"ovidiu.feodorov(a)jboss.com" wrote : | So, I agree that there is an efficiency problem with using byte[] instead of direct ByteBuffers, but saying that an interface that use byte[] cannot inherently work with a NIO runtime is just wrong. A byte[] has nothing to do with non-blocking-ness per se. | Well I don't think I ever said that. The point I was making is that we shouldn't *prevent* people from using direct buffers if they want, by forcing them to use byte arrays. I think it's a bad API that doesn't allow the user to exploit the full available power. Certainly the user should be careful, but it's user errror if they screw up. I think we have no (at least tacitly) agreed that byte buffers should be exposed, not byte[] so this is rather moot. anonymous wrote : | Tim wrote : | | This is what non blocking is all about. A blocking implementation would block until all the bytes had been written. This preventing the thread neing used for anything else while the blocking is occurring. | | | | No, this is not what non blocking is all about. | This *is* what non blocking is all about. Certainly NIO has other nice things like byte buffers and charset support, but we're talking about blocking here not NIO in general. By avoiding blocking on reads or writes it enables a small number of threads to handle a large amound of "connections". If reads or writes were blocking that wouldn't be possible. That's the crux of the matter. "Ovidiu" wrote : | There are two different (and orthogonal) aspects: non-blocking behavior + readiness selection AND direct buffers. You can avoid using direct buffers if you want to, and still get non-blocking behavior at the "lower" level of your framework. In the end, you want to achieve separation between your client code and the transport. | | Tim wrote : | | This also means it's going to be up to the application to piece together requests and responses. | | | | No. | | Let's walk through a simple example. Let's say that you want to send a message acknowledgment from the client to the server, saying that message with id = 77 has been successfully processed by the client code... | To re-iterate what I said earlier. Yes, you can handle the partial reads/writes in the framework which is basically what you are proposing. However, this is one of the major value adds of NIO frameworks like MINA (I don't know about ember but I wouldn't be surprised if it did this too), so we are now getting into the realms of writing our NIO framework, and now the warning bells are ringing. Why not just use one that we know works? Frameworks also seem to handle other stuff like byte buffer pooling (important with direct buffers as you have pointed out) and allow different selector/worker thread models to be used. Also SSL support is built in (with MINA at least) although this is only with JDK5. "Ovidiu" wrote : | We will decide on a solution at the end of the remoting meeting that will take place this week. The solution I propose is one of the possible outcomes. Using an external framework it's another. Nothing is a priori overruled. | Great :) My 2c (again): Facts: a) We need NIO. (I'm not even mentioning multiplex here) b) Remoting doesn't support NIO as we require it. c) Other NIO frameworks exist which support what we want to do. d) We must have this done in 4 weeks. Options: a) Write our own NIO framework. (Alarm bells!!) b) Use an NIO framework that already exists c) Wrap remoting around an existing NIO framework, and hope that remoting can somehow provide a better API. Conclusions: a) This is far too time consuming and error prone. b) Is my preferred solution c) Is something worth exploring, but I fail to see what value remoting would add by wrapping the underlying NIO interface. What could it do better? I would suggest b), then in phase 2, see if it makes sense to combine this with remoting somehow. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3980645#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...