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
Nested ClassesModifier and TypeClassDescriptionstatic interfaceNested classes/interfaces inherited from class hudson.remoting.CommandTransport
CommandTransport.CommandReceiver -
Field Summary
Fields -
Constructor Summary
Constructors -
Method Summary
Modifier and TypeMethodDescriptionabstract voidStarts the transport.final voidsetup(Channel channel, CommandTransport.CommandReceiver receiver) Starts the transport.final voidCalled byChannelto send one command to the other side.abstract voidwriteBlock(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.ByteArrayReceiverthat uses byte[] instead ofCommand -
setup
Description copied from class:CommandTransportStarts 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 allowCommandTransportto 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 ofChannels via NIO. For subtypes that prefer synchronous operation, extend fromSynchronousCommandTransport.Closing the read pump:
ChannelimplementsChannel.CloseCommandits 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,Channelwill 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:
setupin classCommandTransport
-
write
Description copied from class:CommandTransportCalled byChannelto send one command to the other side.Channelserializes 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:
writein 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
-