Re: Qpid Java Client with RabbitMQ

[Robbie Gemmell <ro...@gmail.com>]

Hi Julien,

This is as you deduced the result of the RabbitMQ federation adding a
header that the client doenst understand, specifically a Field Array
judging by the thode (41 / 'A' ). Although the particular property being
retrieved at the time of the stacktrace was 'JMS_QPID_DESTTYPE', this is
likely only because it is the first property retrieved and so provokes
decoding the header FieldTable, which the client then discovers contains
the FieldArray which it doesnt understand and leads to an exception being
thrown. By catching that exception you could be masking that it has also
failed to decode a bunch of other subsequent headers, so it probably isn't
a viable general approach. The correct thing would probably be to add
enough support for the client to either decode the array fully (though
there is no real way of exposing such headers except going outwith the JMS
spec) or at least skip it 'properly' by simply reading the appropriate
bytes before continuing to decode the rest. I am unlikely to find time for
this in the near term, but if it is something you wanted to pursue please
feel free to raise a JIRA and attach a patch and I will try to look at it.

Regards,
Robbie


On 29 November 2013 08:50, Julien Poirier <jp...@hotmail.fr> wrote:

> Hi,
> I am trying to use Qpid Java Client 0.26-Snapshot with RabbitMQ 3.1.3
> (using AMQP 0.9-1). I’ve followed this thread to complete my task :
>
> http://qpid.2158936.n2.nabble.com/Null-Pointer-exception-in-Qpid-Java-CLient-0-24-td7599126.html
> It’s running well. In my environnement I’ve two brokers. The one (the A)
> when the QPID client is connected, an other one (The B) that is collecting
> data and forward them to the A using federation. When a message is coming
> from the B to the A the client break with this stack :
> 1 Nov 2013 13:40:01,595 ERROR BasicMessageConsumer : Caught exception
> (dump follows) - ignoring... java.lang.IllegalArgumentException: no such
> type code: 41        at
> org.apache.qpid.framing.AMQTypeMap.getType(AMQTypeMap.java:46)        at
> org.apache.qpid.framing.AMQTypedValue.readFromBuffer(AMQTypedValue.java:211)
>        at
> org.apache.qpid.framing.FieldTable.setFromBuffer(FieldTable.java:1078)
>    at
> org.apache.qpid.framing.FieldTable.populateFromBuffer(FieldTable.java:131)
>        at
> org.apache.qpid.framing.FieldTable.getProperty(FieldTable.java:112)
>  at org.apache.qpid.framing.FieldTable.getInteger(FieldTable.java:266)
>    at
> org.apache.qpid.client.message.AMQMessageDelegate_0_8.<init>(AMQMessageDelegate_0_8.java:104)
>        at
> org.apache.qpid.client.message.AbstractJMSMessageFactory.create08MessageWithBody(AbstractJMSMessageFactory.java:103)
>        at
> org.apache.qpid.client.message.AbstractJMSMessageFactory.createMessage(AbstractJMSMessageFactory.java:160)
>        at
> org.apache.qpid.client.message.MessageFactoryRegistry.createMessage(MessageFactoryRegistry.java:127)
>        at
> org.apache.qpid.client.BasicMessageConsumer_0_8.createJMSMessageFromUnprocessedMessage(BasicMessageConsumer_0_8.java:118)
>        at
> org.apache.qpid.client.BasicMessageConsumer_0_8.createJMSMessageFromUnprocessedMessage(BasicMessageConsumer_0_8.java:44)
>        at
> org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:712)
>        at
> org.apache.qpid.client.AMQSession$Dispatcher.notifyConsumer(AMQSession.java:3388)
>        at
> org.apache.qpid.client.AMQSession$Dispatcher.dispatchMessage(AMQSession.java:3327)
>        at
> org.apache.qpid.client.AMQSession$Dispatcher.access$900(AMQSession.java:3114)
>        at org.apache.qpid.client.AMQSession.dispatch(AMQSession.java:3107)
>        at
> org.apache.qpid.client.message.UnprocessedMessage.dispatch(UnprocessedMessage.java:54)
>        at
> org.apache.qpid.client.AMQSession$Dispatcher.run(AMQSession.java:3250)
>    at java.lang.Thread.run(Thread.java:722)
> This is caused by some header that the RabbitMQ broker set (x-federation).
> And because the RabbitMQ broker manage types that are not supported by the
> Qpid client I’ve modified the the AMQMessageDelegate_0_8 class and put a
> try catch block :try {                   type =
> contentHeader.getHeaders().getInteger(
> CustomJMSXProperty.JMS_QPID_DESTTYPE.getShortStringName());
>                 } catch (Exception e) {                 …               }
> With my rabbitMQ architecture the type is 100% null. In case of federation
> between two RabbitMQ brokers I’ve managed to let the type to null and block
> the throwed exception. The delivred body content is correct. I don’t know
> if it could be a good thing to add this try/catch in a Qpid broker/Qpid
> client situation. If you think that this is ok to bypass some header that
> are not parseable, perhaps you can add this to you current dev version.
> If not I hope this message will help people trying to do the same thing.
> Julian