Class AbstractByteArrayCommandTransport
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.- Since:
- 2.13
- Author:
- Kohsuke Kawaguchi
-
Nested Class Summary
Modifier and TypeClassDescriptionstatic interface
Nested classes/interfaces inherited from class hudson.remoting.CommandTransport
CommandTransport.CommandReceiver
-
Field Summary
-
Constructor Summary
-
Method Summary
Modifier and TypeMethodDescriptionabstract void
Starts the transport.final void
setup
(Channel channel, CommandTransport.CommandReceiver receiver) Starts the transport.final void
Called byChannel
to send one command to the other side.abstract void
writeBlock
(Channel channel, byte[] payload) Writes a byte[] to the transport.Methods inherited from class hudson.remoting.CommandTransport
closeRead, closeWrite, getRemoteCapability
-
Field Details
-
channel
-
-
Constructor Details
-
AbstractByteArrayCommandTransport
public AbstractByteArrayCommandTransport()
-
-
Method Details
-
writeBlock
Writes a byte[] to the transport. The block boundary is significant. A transport needs to ensure that that the same byte[] is read by the peer (unlike TCP, where a single write can be split into multiple read()s on the other side.)- Throws:
IOException
-
setup
Starts the transport. Seesetup(Channel, CommandReceiver)
for more details. In this subtype, we pass inAbstractByteArrayCommandTransport.ByteArrayReceiver
that uses byte[] instead ofCommand
-
setup
Description copied from class:CommandTransport
Starts the transport. This method is called once and only once at the end of the initialization ofChannel
, after theCommandTransport.getRemoteCapability()
is invoked. The first purpose of this method is to provide a reference back toChannel
, and the second purpose of this method is to allowCommandTransport
to message pumping, where it starts receiving commands from the other side and pass them ontoCommandTransport.CommandReceiver
. This abstraction enables asynchronous processing — for example you can have a single thread serving a large number ofChannel
s via NIO. For subtypes that prefer synchronous operation, extend fromSynchronousCommandTransport
.Closing the read pump:
Channel
implementsChannel.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 yourCommandTransport.closeRead()
(from the same thread that invokedCommandTransport.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 callsCommandTransport.closeRead()
to shutdown the reader side.- Specified by:
setup
in classCommandTransport
-
write
Description copied from class:CommandTransport
Called byChannel
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.)
- Specified by:
write
in classCommandTransport
- Parameters:
cmd
- The command object that needs to be sent. Never null. This must be serialized viaCommand.writeTo(Channel, ObjectOutputStream)
last
- Informational flag that indicates that this is the last call of theCommandTransport.write(Command, boolean)
.- Throws:
IOException
-