JBossDeveloper

+1 : I don't like the idea of dealing with byte[] buffers directly. You need aways replicate stuff when you could parse it from the buffer directly.

"ovidiu.feodorov@jboss.com" wrote:

Not necessarily, the Remoting implementation can create ByteBuffers by wrapping the byte[] we send as an argument without copying anything, but I don't see any problem with using ByteBuffer instead of byte[] in the method signature.

The only observation I have from the document is about byte arrays
(http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossMessagingRemotingAPIExtensions)



If we need to deal with byte[] directly, having byte[] on the signature will force us (and remoting) to duplicate the object, maybe serialize it before flushing it out to the streaming.

I would like to propose something like access to Input/OutputStream directly saving the need of converting an object to byte[] before sending it.

RemotingOutputStream stream = client.getDirectOutputStream();
 stream.close(); // will dismiss the stream and put client in a state to receive other calls.

 Client client = new Client("bidirectional://jmsserverbox:7777", "EXAMPLE-SUBSYSTEM");

 client.connect()
 client.addHandler(new MessagingCallbackHandler());

 Object result = client.invoke(new MessagingInvocation());


 OutputStream output = client.getDirectOutput(); // this will return a RemotingOutputStream
 InputStream input = client.getDirectInput();
 out.write(...);
 input.read(); // reads the answer
 out.close();

This doesn't make any sense to me.

NIO and streams don't work well together.

NIO is based around a fixed size buffers - this is a quite different way of working to the old stream based io that most people are used to.

As I said earlier in this thread I would be suprised if you can create an API that works equally well for blocking and NIO.

If we want to get the best performance the API must expose access to the underlying buffers. There's no way around this without sacrificing performance which is not an option IMHO.

I'm also getting worried that we've spent a long time on this, and it seems not everyone yet understands the basic differences between a blocking and non blocking approach, this is not a good sign :(

I used ByteStream because on my suggestion 'cause I though it would be possible to work with NIO and STreams (As there is a method to get a STream from a Channel on NIO).

If this is not possible, we could change the approach to whatever other way. and if it's not possible to work with an sort of Buffer then we will have to stick with byte arrays.

Tim, Ovidiu.... replace my suggestion from Input/OUtpuSTream to ByteBuffer.

"ovidiu.feodorov@jboss.com" wrote:

Where exactly did you see the word "stream" in the Remoting API extension document?

ovidiu.feodorov@jboss.com wrote:

The memory allocated when creating a direct buffer is outside of the JVM heap. The allocation is done through native methods, and it's likely to be significantly more expensive than creating non-direct buffers.

I am not saying that we shouldn't use ByteBuffers for the low-level access API, I am saying that we should be very careful how we handle them, and what kind of buffers we pass around, so the drawbacks don't outweigh the speed advantages obtained by having I/O devices writing directly in the memory areas managed by direct buffers.

Another thing to bear in mind with the proposed API.

If you have a method write(byte[] byte), then when used with a non blocking implementation this method might return after having written only a partial number of the bytes.

A similar reasoning applies to reads too.

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.

This means the semantics of the API differ depending on whether the actual implementation is blocking or non blocking.

This also means it's going to be up to the application to piece together requests and responses. This is where most of the difficulty in a non blocking approach comes in.

Trying to get the same API to cope with both approaches strikes me as somewhat analagous to the medieval alchemists trying to turn lead into gold.

It seems to me that our biggest issue is getting an implementation up and running. So far we haven't even got the interface sorted.

At the end of the day our end user won't give two hoots what our internal API looks like, but they will care that our performance sucks.

As I've said before, I could probably knock something up in MINA in a few weeks. Considering we only have just over 4 weeks to have this fully implemented, I think this is our only feasible option.

After that, we philosophise as much as we want about how to retrofit that in remoting.

But please please let's not try and write a new non blocking framework - let's not go down the "Not invented here" path. There are already tried and tested frameworks out there.

Let's get something working, and think about how this nicely fits into a new remoting api later when we have the luxury of time.

Personally - if you're going to provide an API that supports non blocking operations without limiting what the user can do in terms of power/performance then what's wrong with the Channel/Selector API?

This was designed by experts to do just that. Why do we think we can do any better?

If we're trying to provide a higher level abstraction to the the channel/selector API then we're going down the route of writing our own NIO framework, which seems a big waste of time to me since there are already frameworks out there who have gone through that pain. (Not Invented Here syndrome etc)