Need stomp parameter to be sent through, for activemq to see ActiveMQTextMessage

[mfeblowitz]

ActiveMQ can receive either ActiveMQTextMessage content or ActiveMQBytesMessage content, depending on a couple of headers sent in with the stomp message. For systems expecting text content (as ours is), receiving byte content results in severe errors being thrown and no content being delivered.

Initially described here, inclusion of content-length header can determine whether the incoming message is expected to be one or the other.

As it turns out, in some circumstances, it might not be possible to suppress the presence of a content-length header and in those cases the hack doesn't work. However, look here for a more reliable solution:

Be aware that, by default, messages published via Stomp which include a content-length header will be converted by ActiveMQ to binary messages, and will not be visible to your web clients. Beginning with ActiveMQ 5.4.0, you can resolve this problem by always setting the *amq-msg-type* header to text in messages which will may be consumed by web clients.

So, what's needed in the nodes is a way to punch in that amq-msg-type header, to control the selection of the message type.

I've tested a hack in 18-stomp.js that allows for text type messaging, since it appears that the default for the stomp nodes is ByteMessage format. I've modified line 138 to the following:

node.client.publish(node.topic || msg.topic, msg.payload, {'amq-msg-type':'text'});

I'm thinking that it would be better to install into the stomp nodes a message type selector, allowing users to specify which message type is to be used/expected.

Also, I found that with text type messages, simply sending JSON does not work. It would be better in cases of TextMessage format to have the node test for JSON payload content and stringify if necessary.

[knolleary]

The tricky part is that is an ActiveMQ specific header, which might mean nothing to another stomp implementation.

Need to consider how to expose this in a stomp meaningful way.

[dceejay]

Well its a generic stomp option so we could just allow use of say msg.header to pass it in for the more advanced user.... Unless there really are a defined list of possible options.

[mfeblowitz]

That would suffice, and was the first thing I tried. There could be other header items needing to be passed through, such as Stomp extensions for JMS message semantics.Then it's a matter of having access to header option documentation.

[dceejay]

I have pushed a fix so you can pass in msg.headers as an object containing what you want to the output node.
What we do still need to think about is how to also expose it in the UI - especially as that would be the only way to pass in headers to the subscribe side.

[mfeblowitz]

Ok - when/where would I see the fix? I'm curious, as I've just tried a one-line fix that includes msg.headers in the call to node.client.publish (18-stomp.js, line 138).

As for the subscribe side, I don't have an immediate need for any, but the ActiveMQ extensions to Stomp suggest the need. Still, it does seem an ActiveMQ-specific extension, so a UI-specific approach could be confusing. How about just extending stomp-out to look for and process msg.headers on input and documenting that these can be inserted upstream if needed?

[dceejay]

npm update node-red-node-stomp
but yes is the same change (plus some words in the html etc)

no problem with the out node - that's exactly what it does - it's the in (subscribe) node that would be tricky as it has to be done through the UI (and we would then want the out to match - as well as being able to accept msg.headers)

[mfeblowitz]

Yes. npm... :) that, I knew. I was just looking at the file via the git browser and didn't see a change.

And, yes. There is no upstream node for the in (subscribe) node. D'Oh. So, yes, a challenge. It sounds similar to a config node, supplying header contents to both the in and out nodes. In this case, it would supply either a string describing the array of headers (JSON), or perhaps a multi-select, where each selectable option would be a header/value pair?

[dceejay]

Well yes a simple text box to allow a string we parse into JSON would do it... but is ugly and not very helpful. The multi select would be better if we knew all the possible options... which I don't think we do. Need to think some more..
(Fix also pushed to git now)

[mfeblowitz]

Right - I was thinking about something different to the a priori known options. Think about how you would configure host:port as a TCP config - you provide both host and port. Then, you select a single host:port config for the TCP node. What if you could create a number of header:value options and then pick N of them to configure the stomp node (as opposed to one for TCP). It seems like a consistent UI approach, but a rather big ask to support the multi-select interface and config.

[mfeblowitz]

Ok - understanding this better now. And now I'm thinking that having the headers ride in to the out node from the prior node is adequate but ugly. It means that every stomp out will have to be paired with a pass-through node that punches in msg.headers. Or it means I'll have to "wrap" the out node, to get the headers specified. So I'm all for a solution suitable for both in and out, and for it to, at minimum, contain a headers text box or, better, to have a headers config node with same or, even better, to have a headers config node that collects individual header:value pairs or, best, that has same but has "activate" checkboxes on each (seems overkill for this node, for now).

[dceejay]

Well it's only necessary if you need to set the headers... it's a consistent solution with the http node - so not too arduous - cut/paste works quite well... If you want to make it tidier you can always create a subflow node containing the pair you need.

[mfeblowitz]

Yup - good idea. That will suit me fine. Thanks!

[shyam2017]

Able to send the Json message as Text message using below command- Stomp (Python)
conn.send(body=json.dumps(json_content), destination=destination, headers={'amq-msg-type':'text'})

[hardillb]

@shyam2017 This issue was closed over 8 years ago and is specifically to do with sending messages via the Node-RED platform which runs on NodeJS. It really is not clear what link your comment has to any of this.

Please use the Node-RED forum or Slack to ask questions, if you believe you have an actual issue, open a new one, give full details and you can reference this one if needed.