简体   繁体   中英

Java Non-Blocking IO ObjectStream

I have seen that there are some questions about this topic, but they are all a couple years old or not very elaborate.

I have been migrating an applications old Socket implementation to the new NIO SocketChannel , because it was working unstable and I was going to do this part again (as part of a code-review). So now I am using Non-Blocking SocketChannel , and just found out that I can't just use the ObjectInputStream and ObjectOutputStream because... well it's non-blocking. Apparently the SocketChannel needs to have a size for the transferred data.

Is there a known solution about this problem? Is there maybe a template one can use, or a solution that is commonly approved as best practice ( pattern )? The fact that I can just utilize ObjectInputStream and ObjectOutputStream made everything a lot easier. If I have to create my own implementation, I will probably need too much time and break a lot of things in an application I'm trying to make more stable.

Questions in a summary:

  • Is there a common solution to use ObjectInputStream and ObjectOutputStream in a non-blocking SocketChannel ?
  • Can I maybe even make a hybrid, like accepting the incoming connections in non-blocking mode and when the selector finds out that there is stuff to read, it changes to blocking-mode? (I know it sounds terrible, but I am a bit desperate.)

PS: Using Java 8 and it's a TCP-Stream.

I am using Non-Blocking SocketChannel, and just found out that I can't just use the ObjectInputStream and ObjectOutputStream because... well it's non-blocking.

SocketChannel is blocking by default. If you don't want non-blocking, don't configure it that way.

ObjectInputStream and ObjectOutputStream are much simpler to use with plain Java IO.

Apparently the SocketChannel needs to have a size for the transferred data.

You don't have to, but if you are using an Object*Stream it is simpler.

Is there a known solution about this problem?

Part from using plain IO, or using aa block of data with a length before it using NIO.

If you want to improve performance, I suggest using another serialization library. The built in one is one of the slowest options. There is dozens of alternatives (in fact I have written two ;)

Is there maybe a template one can use, or a solution that is commonly approved as best practice (pattern)?

Using Plain IO, and a faster serializer.

The fact that I can just utilize ObjectInputStream and ObjectOutputStream made everything a lot easier.

In that case you don't want to be using NIO as it will make things ten time harder, esp if you use non-blocking IO and Selectors.

If I have to create my own implementation, I will probably need too much time and break a lot of things in an application I'm trying to make more stable.

Agreed, esp when there is so many alternatives to chose from.

Is there a common solution to use ObjectInputStream and ObjectOutputStream in a non-blocking SocketChannel?

Not at all.

Can I maybe even make a hybrid, like accepting the incoming connections in non-blocking mode and when the selector finds out that there is stuff to read, it changes to blocking-mode? (I know it sounds terrible, but I am a bit desperate.)

Sure, like I said, SocketChannel is blocking by default so you won't need to do anything. I would make the acceptor blocking as well.

PS: Using Java 8 and it's a TCP-Stream.

No problem, it would be the same if you were using Java 1.4. These libraries haven't changed dramatically in the last 12 years.

Serialize your object(s) using a ObjectOutputStream wrapping a ByteArrayOutputStream , and then get the resulting byte[] buffer. Send the buffer over the SocketChannel.

At the other end, extract the byte[] buffer from your SocketChannel , construct a ByteArrayInputStream , and an ObjectInputStream , and read your object(s).

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM