public abstract class AbstractByteArrayCommandTransport extends CommandTransport
CommandTransport
that works with byte[]
instead of command object.
This base class hides away some of the Command
serialization details. One less thing
for transport implementers to worry about.Modifier and Type | Class and Description |
---|---|
static interface |
AbstractByteArrayCommandTransport.ByteArrayReceiver |
CommandTransport.CommandReceiver
Constructor and Description |
---|
AbstractByteArrayCommandTransport() |
Modifier and Type | Method and Description |
---|---|
abstract void |
setup(AbstractByteArrayCommandTransport.ByteArrayReceiver receiver)
Starts the transport.
|
void |
setup(Channel channel,
CommandTransport.CommandReceiver receiver)
Starts the transport.
|
void |
write(Command cmd,
boolean last)
Called by
Channel to send one command to the other side. |
abstract void |
writeBlock(Channel channel,
byte[] payload)
Writes a byte[] to the transport.
|
closeRead, closeWrite, getRemoteCapability
protected Channel channel
public abstract void writeBlock(Channel channel, byte[] payload) throws IOException
IOException
public abstract void setup(AbstractByteArrayCommandTransport.ByteArrayReceiver receiver)
CommandTransport.setup(Channel, CommandReceiver)
for more details.
In this subtype, we pass in AbstractByteArrayCommandTransport.ByteArrayReceiver
that uses byte[] instead of Command
public final void setup(Channel channel, CommandTransport.CommandReceiver receiver)
CommandTransport
Channel
,
after the CommandTransport.getRemoteCapability()
is invoked.
The first purpose of this method is to provide a reference back to Channel
, and
the second purpose of this method is to allow CommandTransport
to message pumping,
where it starts receiving commands from the other side and pass them onto CommandTransport.CommandReceiver
.
This abstraction enables asynchronous processing — for example you can have a single thread
serving a large number of Channel
s via NIO.
For subtypes that prefer synchronous operation, extend from SynchronousCommandTransport
.
Closing the read pump: Channel
implements
Channel.CloseCommand
its own "end of command stream" marker, and
therefore under the orderly shutdown scenario, it doesn't rely on the transport to provide EOF-like
marker. Instead, Channel
will call your CommandTransport.closeRead()
(from the same thread
that invoked CommandTransport.CommandReceiver.handle(Command)
) to indicate that it is done with the reading.
If the transport encounters any error from the lower layer (say, the underlying TCP/IP socket
encountered a REST), then call CommandTransport.CommandReceiver.terminate(IOException)
to initiate the abnormal
channel termination. This in turn calls CommandTransport.closeRead()
to shutdown the reader side.
setup
in class CommandTransport
public final void write(Command cmd, boolean last) throws IOException
CommandTransport
Channel
to send one command to the other side.
Channel
serializes the invocation of this method for ordering. That is,
at any given point in time only one thread executes this method.
Asynchronous transport must serialize the given command object before returning from this method, as its content can be modified by the calling thread as soon as this method returns. Also, if an asynchronous transport chooses to return from this method without committing data to the network, then it is also responsible for a flow control (by blocking this method if too many commands are queueing up waiting for the network to unclog.)
write
in class CommandTransport
cmd
- The command object that needs to be sent. Never null. This must be
serialized via Command.writeTo(Channel, ObjectOutputStream)
last
- Informational flag that indicates that this is the last
call of the CommandTransport.write(Command, boolean)
.IOException
Copyright © 2004–2022. All rights reserved.