Multithreaded flooding reliably broken with 2.20

[GoogleCodeExporter]

# What steps will reproduce the problem?

1. Clone https://github.com/pcarrier/kryoflood
2. Run mvn package
3. Observe that everything runs fine with:
java -cp lib/kryonet-2.18-all.jar:target/kryoflood-1.0-SNAPSHOT.jar 
com.github.pcarrier.kryoflood.Main cs 1
4. Observe that everything breaks with:
java -cp lib/kryonet-2.18-all.jar:target/kryoflood-1.0-SNAPSHOT.jar 
com.github.pcarrier.kryoflood.Main cs 2
5. When digging, please be patient with my benchmark coding style :)

# What is the expected output? What do you see instead?

The server goes BufferOverflowException as soon as there are more than one 
client.

# What version of the product are you using? On what operating system?

I am using kryonet-2.18-all.jar from kryonet-2.20.zip. Not sure which version 
that is.

# Please provide any additional information below.

Usage:
"cs" to run a client and a server that floods it with UDP messages
"csu 20" to run 20 clients and a server that floods them with TCP messages
(c for client(s), s for server, u for UDP, followed by a number to have 
multiple clients)

This is the output with 2 clients:
--- 8< ---
% java -cp lib/kryonet-2.18-all.jar:target/kryoflood-1.0-SNAPSHOT.jar 
com.github.pcarrier.kryoflood.Main cs 2
0: Infinity msg/s
1: Infinity msg/s
0 connected!
1 connected!
Exception in thread "Server@1" java.nio.BufferOverflowException
    at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:183)
    at com.esotericsoftware.kryo.io.ByteBufferOutputStream.write(ByteBufferOutputStream.java:42)
    at com.esotericsoftware.kryo.io.Output.flush(Output.java:154)
    at com.esotericsoftware.kryonet.KryoSerialization.write(KryoSerialization.java:51)
    at com.esotericsoftware.kryonet.TcpConnection.send(TcpConnection.java:192)
    at com.esotericsoftware.kryonet.Connection.sendTCP(Connection.java:59)
    at com.github.pcarrier.kryoflood.Main$1$1.run(Main.java:43)
Exception in thread "Client" com.esotericsoftware.kryonet.KryoNetException: 
Incorrect number of bytes (12 remaining) used to deserialize object: 
SimpleTest(id=456673020, message=Hello!)
    at com.esotericsoftware.kryonet.TcpConnection.readObject(TcpConnection.java:146)
    at com.esotericsoftware.kryonet.Client.update(Client.java:239)
    at com.esotericsoftware.kryonet.Client.run(Client.java:317)
    at java.lang.Thread.run(Thread.java:722)
Exception in thread "Client" com.esotericsoftware.kryonet.KryoNetException: 
Invalid object length: 0
    at com.esotericsoftware.kryonet.TcpConnection.readObject(TcpConnection.java:116)
    at com.esotericsoftware.kryonet.Client.update(Client.java:239)
    at com.esotericsoftware.kryonet.Client.run(Client.java:317)
    at java.lang.Thread.run(Thread.java:722)
--- >8 ---

Whereas with one client, everything runs fine:
--- 8< ---
% java -cp lib/kryonet-2.18-all.jar:target/kryoflood-1.0-SNAPSHOT.jar 
com.github.pcarrier.kryoflood.Main cs 1
0: Infinity msg/s
0 connected!
0: 107526.88 msg/s
0: 172117.05 msg/s
0: 157480.31 msg/s
0: 153374.23 msg/s
0: 149700.6 msg/s
0: 154320.98 msg/s
0: 167224.08 msg/s
0: 186219.73 msg/s
0: 168918.92 msg/s
0: 169204.73 msg/s
--- >8 ---

Original issue reported on code.google.com by pie...@spotify.com on 21 Jan 2013 at 12:14

[GoogleCodeExporter]

And this can be reproduced when running server and clients in completely 
separate processes as well.

For example:
% java -cp lib/kryonet-2.18-all.jar:target/kryoflood-1.0-SNAPSHOT.jar 
com.github.pcarrier.kryoflood.Main s &
% java -cp lib/kryonet-2.18-all.jar:target/kryoflood-1.0-SNAPSHOT.jar 
com.github.pcarrier.kryoflood.Main c &
% java -cp lib/kryonet-2.18-all.jar:target/kryoflood-1.0-SNAPSHOT.jar 
com.github.pcarrier.kryoflood.Main c

Original comment by pie...@spotify.com on 21 Jan 2013 at 12:31

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I assume this is more or less an expected behaviour and that "I should take my 
precautions", but it seems that the server could catch this and return an 
exception, instead of failing in flight and breaking the client's state.

Original comment by pie...@spotify.com on 21 Jan 2013 at 1:37