public class IncomingPacket
extends java.lang.Object
TODO -- Sanjeev will add a detailed description of this application level protocol later
When allocating the ByteBuffer, we have two options: 1. Normal java heap buffer by invoking ByteBuffer.allocate(...), 2. Native heap buffer by invoking ByteBuffer.allocateDirect(...), Though it would require extra memory copies in java heap buffer, after experiments trying to use both of them, we choose to use normal java heap buffer, since: 1. It is unsafe to use direct buffer: -- Direct buffer would not trigger gc; -- We could not control when to release the resources of direct buffer explicitly; -- It is hard to guarantee direct buffer would not break limitation of native heap, i.e. not throw OutOfMemoryError.
2. Experiments are done by using direct buffer and the resources saving is negligible: -- Direct buffer would save, in our scenarios, less than 1% of RAM; -- Direct buffer could save 30%~50% cpu of Gateway thread. However, the cpu used by Gateway thread is negligible, less than 2% out of the whole usage in worst case. -- The extra copy is within JVM boundary; it is pretty fast.
Constructor and Description |
---|
IncomingPacket() |
Modifier and Type | Method and Description |
---|---|
int |
readFromChannel(java.nio.channels.SocketChannel channel) |
int |
size() |
void |
unpackMessage(com.google.protobuf.Message.Builder builder) |
REQID |
unpackREQID() |
java.lang.String |
unpackString() |
public int readFromChannel(java.nio.channels.SocketChannel channel)
public java.lang.String unpackString()
public REQID unpackREQID()
public void unpackMessage(com.google.protobuf.Message.Builder builder)
public int size()