Hello. After looking at the binary value in the database field, I can see that the 0x0A is present at the end of the message.
I've also tested sending the same payload using a JMS client, and the field is "clean" in this case : it seems that the issue comes from the REST API that modifies the message with this LF. Very strange, since I've been using the same configuration for testing many cases with distinct messages, and only some of them lead to polluted data, perhaps because of their length ? Has someone any experience with the REST API that could confirm similar issues ? Thanks again. Regards. Le mer. 19 juin 2024 à 13:22, Ephemeris Lappis <ephemeris.lap...@gmail.com> a écrit : > > Hello. > > I use postman to test Camel applications that consume JMS messages. > I've already done a lot of tests without any problem, but the last one > produces a strange error. > > When I debug my Camel route, I see that a line feed (0x0a) byte has > been added at the end of the message. The source message length is > 169492 (postman console confirms this length), and is a base64 encoded > value. The unexpected LF produces a base64 decoder failure. > > I don't know if the problem comes from the HTTP API when it receives > the post request, or when the message is read and sent to the JMS > consumer. > > I've tried to inspect messages that are stored in a postgresql > database, but I can't extract information from the column "msg". > > Is there any way to check what is stored for this message ? > > Is this issue already known ? > > Thanks for your help. > > Regards. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@activemq.apache.org For additional commands, e-mail: users-h...@activemq.apache.org For further information, visit: https://activemq.apache.org/contact
