开发者

Large byte array transfer to client

开发者 https://www.devze.com 2023-02-26 19:02 出处:网络
Let me present my situation. I have a lot of data in bytes stored in files on server. I am writing and reading this files using AIO t开发者_运维问答hat is coming in JDK7. Thus, I am using ByteBuffer(

Let me present my situation.

I have a lot of data in bytes stored in files on server. I am writing and reading this files using AIO t开发者_运维问答hat is coming in JDK7. Thus, I am using ByteBuffer(s) for read and write operations.

The question is once I have performed a read on AsynchronousFileChannel I want to transfer the content of the ByteByffer that was used in read operation to the client. Thus I actually want to send the bytes.

What would be the best way to go from here. I don't want to send the ByteBuffer, because I have a pool of them that I reuse, thus this is not an option. I want to be able also to even maybe combine several reads and send the content of several ByteBuffer(s) combined at once.

So what do I send. Just a byte[] array? Or do I need some stream? What be the best solution regarding performance here.

I am using RMI for communication.

Thanx in advance.


You can simulate streams over rmi using the RMIIO library, which will allow you to stream arbitrary amounts of bytes via RMI without causing memory problems on either end.

(disclaimer, i wrote the library)


Unless there is a very good reason not to, then just send the byte array along with sufficient meta data that you can provide reliable service.

The less of the underlying implementation you need to transfer back and forth over RMI, the better. Especially when you work with Java 7 which is not yet generally available.


To use RMI you have to retrieve the contents of the buffer as a byte[], then write it to an ObjectOutputStream (the write happens under the covers). Assuming that you're currently using direct buffers, this means CPU time to create the array in the Java heap, and CPU time to garbage-collect that array once it's been written, and the possibility that the stream will hold onto the reference too long, causing an out-of-memory error.

A better approach, in my opinion, is to open a SocketChannel to the destination and use it to write the buffer's contents. Of course, to make this work you'll need to write additional data describing the size of the buffer, and this will probably evolve into a communication protocol.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号