-
Enhancement
-
Resolution: Unresolved
-
Major
-
None
-
None
-
None
This is a follow-up to https://issues.redhat.com/browse/WFCORE-7354.
It's been a long time since I dug into the management protocol, but I had a few minutes today. I think it would be fairly straightforward to update the protocol version and add support for sending deployment content in reasonably sized chunks instead of one single chunk. This removes the need to know the total size of the content from the beginning.
ReadAttachmentInputStreamRequestHandler is what sends this content, with this key bit of its impl:
public void execute(final ManagementRequestContext<OperationExecutionContext> taskContext) throws Exception { final OperationExecutionContext exec = taskContext.getAttachment(); final ManagementRequestHeader header = (ManagementRequestHeader) taskContext.getRequestHeader(); final ManagementResponseHeader response = new ManagementResponseHeader(header.getVersion(), header.getRequestId(), null); final InputStreamEntry entry = exec.getStream(index); synchronized (entry) { // Initialize the stream entry final int size = entry.initialize(); try { final FlushableDataOutput output = taskContext.writeMessage(response); try { output.writeByte(ModelControllerProtocol.PARAM_INPUTSTREAM_LENGTH); output.writeInt(size); output.writeByte(ModelControllerProtocol.PARAM_INPUTSTREAM_CONTENTS); entry.copyStream(output); output.writeByte(ManagementProtocol.RESPONSE_END); output.close(); } finally { StreamUtils.safeClose(output); }
You can see there's 'new ManagementResponseHeader(header.getVersion()...' which means this code knows the protocol version supported by the other side. So this logic can react accordingly. We can increase the protocol version and if we get that version back instead of sending a single length value followed by contents we can loop and send chunk length values and chunk contents. Plus corresponding changes on the other side.
Thinking more, it makes sense we know the other side's version. The flow here is the client sends an operation request that includes info saying there are input streams associated with the op. The server then starts asking for the contents of streams. So the content part is basically the server pulling the content, not the client pushing. That's why the above code is the client handling a request and sending a response, not the client initiating the request.
- is related to
-
-
- Resolved
-
