JMS plugin - "invalid stream header"

[Kyle Marino]

Hello all-- any help would be appreciated.

I'm attempting to hook up a third-party JMS application to RabbitMQ through the JMS plugin. As it is third-party, I am unable to look under the hood to see what's happening. I have already reached out to their support line.

I am able to successfully send and retrieve messages to my queue, but I am only able to receive those same messages that are sent by the application. 

When I try to publish a message to the queue via the web management console, I am able to successfully publish. However, when I try to get the message off the queue with the JMS application, I get an error message, "invalid stream header - {hex of first bit of the message I'm trying to get}".

This leads me to believe that I'm somehow trying to retrieve an AMQP message instead of running it through the plugin... but I'm not sure exactly how to do that. The queue is bound to the jms.durable.queues exchange, and I'm able to send the message to that queue just fine.

What am I missing here?

Thank you!

[Michael Klishin]

It would help immensely if you provided

 * An actual stack trace and error message

 * The version of the tool used

 * The JMS API version targeted by the tool

 * Server logs

We cannot suggest anything without the above information.

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/569264e0-b5c0-4492-ae7c-041ef532b2a7%40googlegroups.com.

--

MK

Staff Software Engineer, Pivotal/RabbitMQ

[Kyle Marino]

I apologize for the delay--

I have attached a stack trace file, and copied it below

The tool is the latest version of the JMS-Topic-Selector plugin, and we're running RabbitMQ 3.7.16. 

Unfortunately, I am unable to copy over server logs, but to my knowledge we're not seeing anything abnormal.

As the trace shows, we are successfully pulling data off of the queue... it's just apparently in the wrong format. I'm not sure if this is a formatting issue (pulling AMQP data instead of JMS formatted?) or if our third-party application, GoAnywhere MFT 5.6.2, requires a specific custom format.

Thank you!

com.linoma.dpa.ExecutionException: [8098 - GetMessage] invalid stream header: 476F416E 

at com.linoma.ga.projects.ProjectUtilities.getExecutionException(Unknown Source)

at com.linoma.ga.projects.impl.GoAnywhereProjectUtilities.getExecutionException(Unknown Source)

at com.linoma.ga.projects.tasks.mq.RetrieveMessageTask.execute(Unknown Source)

at com.linoma.ga.projects.ModuleV2.execute(Unknown Source)

at com.linoma.ga.projects.Project.execute(Unknown Source)

at com.linoma.ga.projects.runtime.Job.executeProject(Unknown Source)

at com.linoma.ga.projects.runtime.Job.run(Unknown Source)

at com.linoma.ga.projects.runtime.Runtime.executeProject(Unknown Source)

at com.linoma.ga.projects.runtime.Runtime.executeProject(Unknown Source)

at com.linoma.ga.projects.runtime.Runtime.executeProject(Unknown Source)

at com.linoma.ga.ui.admin.projects.designer.ConfigureProjectForm.execute(Unknown Source)

at com.linoma.ga.ui.admin.projects.designer.ConfigureProjectForm.executeProject(Unknown Source)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)

at java.lang.reflect.Method.invoke(Unknown Source)

at org.apache.el.parser.AstValue.invoke(AstValue.java:279)

at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:273)

at org.apache.myfaces.view.facelets.el.ContextAwareTagMethodExpression.invoke(ContextAwareTagMethodExpression.java:96)

at org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:74)

at org.primefaces.application.DialogActionListener.processAction(DialogActionListener.java:45)

at javax.faces.component.UICommand.broadcast(UICommand.java:120)

at javax.faces.component.UIViewRoot._broadcastAll(UIViewRoot.java:1172)

at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:365)

at javax.faces.component.UIViewRoot._process(UIViewRoot.java:1658)

at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:862)

at org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:42)

at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:196)

at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:143)

at javax.faces.webapp.FacesServlet.service(FacesServlet.java:198)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)

at com.linoma.ga.core.upload.FileUploadFilter.doFilter(Unknown Source)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)

at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)

at com.linoma.dpa.security.SecurityFilter.doFilter(Unknown Source)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)

at com.linoma.ga.ui.core.filter.IFrameEmbeddingFilter.doFilter(Unknown Source)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)

at com.linoma.ga.ui.core.filter.NoCacheFilter.doFilter(Unknown Source)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)

at com.linoma.ga.ui.core.filter.IECompatibilityModeFilter.doFilter(Unknown Source)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)

at com.linoma.dpa.j2ee.AdminRedirectFilter.doFilter(Unknown Source)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:218)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:110)

at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:506)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169)

at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:445)

at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1115)

at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637)

at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:318)

at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)

at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

at java.lang.Thread.run(Unknown Source)

Caused by: com.rabbitmq.jms.util.RMQJMSException: invalid stream header: 476F416E

at com.rabbitmq.jms.client.RMQMessage.fromMessage(RMQMessage.java:1128)

at com.rabbitmq.jms.client.RMQMessage.convertJmsMessage(RMQMessage.java:901)

at com.rabbitmq.jms.client.RMQMessage.convertMessage(RMQMessage.java:895)

at com.rabbitmq.jms.client.RMQMessageConsumer.receive(RMQMessageConsumer.java:354)

at com.rabbitmq.jms.client.RMQMessageConsumer.receiveNoWait(RMQMessageConsumer.java:386)

... 65 more

Caused by: java.io.StreamCorruptedException: invalid stream header: 476F416E

at java.io.ObjectInputStream.readStreamHeader(Unknown Source)

at java.io.ObjectInputStream.<init>(Unknown Source)

at com.rabbitmq.jms.util.WhiteListObjectInputStream.<init>(WhiteListObjectInputStream.java:90)

at com.rabbitmq.jms.client.RMQMessage.fromMessage(RMQMessage.java:1102)

... 69 more

On Thursday, August 22, 2019 at 11:44:14 PM UTC-4, Michael Klishin wrote:

It would help immensely if you provided

 * An actual stack trace and error message

 * The version of the tool used

 * The JMS API version targeted by the tool

 * Server logs

We cannot suggest anything without the above information.

On Fri, Aug 23, 2019 at 6:24 AM Kyle Marino <marin...@gmail.com> wrote:

Hello all-- any help would be appreciated.

I'm attempting to hook up a third-party JMS application to RabbitMQ through the JMS plugin. As it is third-party, I am unable to look under the hood to see what's happening. I have already reached out to their support line.

I am able to successfully send and retrieve messages to my queue, but I am only able to receive those same messages that are sent by the application. 

When I try to publish a message to the queue via the web management console, I am able to successfully publish. However, when I try to get the message off the queue with the JMS application, I get an error message, "invalid stream header - {hex of first bit of the message I'm trying to get}".

This leads me to believe that I'm somehow trying to retrieve an AMQP message instead of running it through the plugin... but I'm not sure exactly how to do that. The queue is bound to the jms.durable.queues exchange, and I'm able to send the message to that queue just fine.

What am I missing here?

Thank you!

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to rabbitm...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/569264e0-b5c0-4492-ae7c-041ef532b2a7%40googlegroups.com.

[Arnaud Cogoluègnes]

The JMS Topic Exchange plugin is required only when using topic
selectors [1]. It's unlikely it's the cause of the problem. If topic
selectors are not in use, JMS messages go through the usual
exchange-binding-queue routes, only the way the messages are
interpreted by the JMS client matters.

If the JMS client consumes from a JMS destination that is not marked
as an AMQP one, messages must be sent from another (or the same
instance) JMS client, because messages are encoded in a certain way.
If you send AMQP messages on this queue, the JMS consumer freaks out
about the invalid header (this is mostly guessing, you didn't specify
what kind of messages are sent to the queue).

The JMS destination the JMS client consumes from can be marked as AMQP
(amqp property set to true) and the JMS consumer will just create JMS
BytesMessage instance from the body of AMQP messages or TextMessage
instances if the JMSType header of the AMQP message is set to
TextMessage. This is covered in the "Consuming Messages From an AMQP
Queue" section of the interoperability section of the documentation
[2].

To sum up, you should use the JMS client for both sending and
publishing to avoid interoperability problems, or follow the
interoperability rules if publishing AMQP messages and consuming from
JMS.

[1] https://www.rabbitmq.com/jms-client.html#plugin
[2] https://www.rabbitmq.com/jms-client.html#destination-interoperability

> To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/b36ae078-c2f8-4a5a-b211-10ecc70e5e75%40googlegroups.com.

[Kyle Marino]

Thank you so much! After a review of the documentation yesterday, it became apparent that I was mistaken in thinking that the JMS client and the topic selector plugin were the same thing. 

I think your confirmation and explanation is exactly what I needed to understand the moving parts here.

Thank you!

> To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/b36ae078-c2f8-4a5a-b211-10ecc70e5e75%40googlegroups.com.

[Kyle Marino]

Replying back on the original post to post the (unhappy) resolution:

The resolution to this normally would have been to define a queue as AMQP in the JNDI bindings file. However, the third-party application in question uses the javax.jms.Session.createQueue() method, and so ignores any defined destinations or queues in the bindings file. As such, it was never possible to use this application in the way we wanted to, and we will need to explore alternate configurations. 

Thank you all for your help!