Remove content-length header attribute from MapMessage #7
Conversation
…ded content-length header attribute.
|
Do you have a case this isn't working. Your example was our exact example why we added this as a Bytes message. If any of your data in your map has a NULL (\0) character, your map will not be delivered. Are you hitting a case where the content-length presented is not correct? |
|
Content-length is always correct. The problem is that ActiveMQ (5.11.0 and 5.12.0) threats this MapMessage as a ByteMessage if content-length is present. Why should there be a NULL character inside MapMessage - it's JSON encoded. And why then has TextMessage no content-length? |
|
Null characters happen naturally if you have some binary payload as a value in the map. I'll dig but we may no longer be using the map message and that's why we aren't seeing your problem. |
|
We're actively using Map messages with arbitrary input (may contain nulls), it would be unsafe to merge this. What version of ActiveMQ are you using where you are seeing this behavior? |
|
As mentioned in my previuos post (Sep, 02) I could reproduce this with ActiveMQ 5.11.0 and 5.12.0. |
Sending a map message from PHP to a Java based consumer via ActiveMQ failes because of superfluous content-length attribute in header information. ActiveMQ uses content-length attribute to distinguish ByteMessages from other messages (TextMessage or MapMessage) as described in Stomp implementation on ActiveMQ.