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:
ObjectInputStream
and ObjectOutputStream
in a non-blocking SocketChannel
? 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.