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 <[email protected]> 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
