BytesXMLMessage data safety
I saw in the documentation the recommendation not to cache BytesXMLMessage objects, because they may be reused.
I am usually extracting the data from it using getBytes() method, and pass it down to the next layer of my processing.
Question: is it safe to pass that data array as is? Do I need to make a copy of it?
Answers
-
Hi again @lilyevsky . We're talking specifically the JCSMP API, correct? Where does it say in the docs about not caching message objects? I'm poking around in the docs and don't see anything specific. Please let me know and I can help to get corrected.
That said, it sounds like you're talking on the consume/receive side. One thing I'd like to point out is that
getBytes()
method retrieves data out of the legacy XML portion of the Solace message. https://docs.solace.com/API-Developer-Online-Ref-Documentation/java/com/solacesystems/jcsmp/BytesXMLMessage.html#getBytes()The proper place to read/write binary data is to cast the incoming message as a BytesMessage, and then use
getData()
: https://docs.solace.com/API-Developer-Online-Ref-Documentation/java/com/solacesystems/jcsmp/BytesMessage.html#getData()Apologies for the method names, there's some legacy reasons there.
But if you're using the BytesMessage methods, then the byte array you receive is a copy and you can do whatever you want with it.
0 -
Hi Aaron, thanks for answering my question.
Sorry about the confusion with not caching messages - it appears I saw it in https://docs.solace.com/Solace-PubSub-Messaging-APIs/API-Developer-Guide/Java-API-Best-Practices.htm#Do and it was actually about producer message pool, nothing to do with consuming messages.0 -
@Aaron Hello Aaron! I have a question I would like to ask, given that the XML portion of solace message seems to be legacy, then would there be any updates for the solace asynchronous receive? It seems that I can only onReceive() as a BytesXMLMessage then I would need to use instanceof to test if it is a BytesMessage. Would it remain as is, or are there plans to update it to support other types of onReceive with different parameters?
0