Perhaps I am missing something, but the codes you indicate mostly appear to be positive values with a null buffer. The positive return codes should fall into the 'Any positive value > 0' case which is also a success case. What is happening under the scenes in this scenario is that there are bytes that were read off the wire (presumably TCP/Socket connection type) but not enough to return a full messgage/buffer of content. This could be due to TCP not having the rest of the data for us yet, it could be due to UPA (now called ETA, more later) reassembling a fragmented message and requiring more parts, or any number of other factors all tied to either the underlying OS read calls or our internal fragmentation/reassembly. Other non-TCP transports may not return the positive values indicating internal read buffer depth so this is why we try to avoid API users applying any specialized logic around it.

The negative codes you mention have different meanings, most common one you would likely see from what you mention is -11 which is the case where the underlying socket has no data to give us and the input buffer is empty.

I notice you are referring to the product as UPA. Several years ago, UPA was 'rebranded' and became part of the Elektron SDK so it is now called ETA. New enhancements and bug fixes can be found in that code line and it is freely downloadable here on the Dev Community. Part of the reason I am mentioning this is that ESDK (and ETA) is also fully open source so you. This will let you pull the code from either the GitHub repo or use the code in the distribution package you download from Dev Community. The code is fully buildable with gradle (the JARs are on Maven Central as well) and you can step in below the surface to see how these things are behaving (or any other questions or issues you may have). As always, we are happy to help answer questions as well.

Hope my answer helps!

And to be clear - the TransportBuffer returned from Channel.read is null

We've also got over 1000 with return code 2896

Hello @Paul.Wuethrich2,

According to UPA Java Developer Guide, Channel.read return codes section, on FAILURE the connection is not longer valid or safe to read.

The channel should be closed, with the intent to reestablish once the condition clears.

"FAILURE Indicates a failure condition, often that the connection is no longer available. The Channel should be closed (for details, refer to Section 9.13). For more details, refer to Error content."

At the time of these failures I would try to asses the health of the network, the machine, and the infra, to see where the cause of this failure originates.

upa-java-channel-read-api-guide.png

Thx again for the quick reply but I do want to point out that the API guide is not entirely consistent with your response per the attached screenshot. Either way, do we know what these return codes mean given the API guide extract I included as pic implies that the API may be assembling fragments of a message? Ideally, I'd like to be able to differentiate between various conditions so that we only disconnect when absolutely required.

We are receiving a null buffer per my note above and return codes 1448 and 2896 and I don't have any documentation for these. Is there a comprehensive list somewhere as the API guide only describes a very small subset.

And also per my original note - we seem to be handling incoming data without an issue (seemingly)

Thanks for the detailed reply Brian.

We have been treating the positive return codes as you describe (i.e. just keep reading and do not drop the channel) as this is what was documented in the examples so all good and I was mainly curious if these codes had any specific meaning.

Also, we're aware of the new branding and github project and as a result of another publishing related connectivity issue on top of an internal TREP 3.3 migration; we're upgrading the Java API libraries to the 3.3 ETA libraries.

Thx - the above scenarios are running in a managed linux enterprise production environment