You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Keith Wall (JIRA)" <ji...@apache.org> on 2017/05/07 16:38:04 UTC
[jira] [Comment Edited] (QPID-7769) [AMQP 0-8..0-91] Support
decoding of type codes u (unsigned short) and B (unsigned byte) to maximise
compatibility with other AMQP implementations
[ https://issues.apache.org/jira/browse/QPID-7769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15999931#comment-15999931 ]
Keith Wall edited comment on QPID-7769 at 5/7/17 4:37 PM:
----------------------------------------------------------
Commit 75be65b adds support to the Broker to understand the {{u}} and {{B}} type codes. I took a look at the public available AMQP 0-91 implementations (RabbitMQ's Java and .NET client and squaremo's amqplib) and found that they no longer use either, nor does the Qpid Python 0-9 codec. The only client I can see of that was capable of producing the B type encoding was the old Qpid .NET v0.8 client, which I know to be still in production use. Following the robustness principle, I think it reasonable for the Broker to understand {{u}} and {{B}} type codes but should not use these encodings when converting messages for 0-8..0-91 clients. I think there is a argument for the Qpid JMS 0-x client to understand them too.
There is a separate wider question about how the Broker should handle messages that it has ingested successfully only to later discover they are somehow bad. To crash seems unreasonable.
was (Author: k-wall):
Commit 75be65b adds support to the Broker to understand the {u} and {B} type codes. I took a look at the public available AMQP 0-91 implementations (RabbitMQ's Java and .NET client and squaremo's amqplib) and found that they no longer use either, nor does the Qpid Python 0-9 codec. The only client I can see of that was capable of producing the B type encoding was the old Qpid .NET v0.8 client, which I know to be still in production use. Following the robustness principle, I think it reasonable for the Broker to understand {u} and {B} type codes but should not use these encodings when converting messages for 0-8..0-91 clients. I think there is a argument for the Qpid JMS 0-x client to understand them too.
There is a separate wider question about how the Broker should handle messages that it has ingested successfully only to later discover they are somehow bad. To crash seems unreasonable.
> [AMQP 0-8..0-91] Support decoding of type codes u (unsigned short) and B (unsigned byte) to maximise compatibility with other AMQP implementations
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: QPID-7769
> URL: https://issues.apache.org/jira/browse/QPID-7769
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
> Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> Currently the Broker fails on some paths if it tries to decode message headers using type codes u (unsigned short) and B (unsigned byte). It should understand these too.
> Flow to disk path fails like so:
> {noformat}
> 2017-05-02 20:21:34,515 ERROR [IO-/127.0.0.1:35664] (o.a.q.s.Main) - Uncaught exception, shutting down.
> java.lang.IllegalArgumentException: no such type code: 42
> at org.apache.qpid.server.protocol.v0_8.AMQTypeMap.getType(AMQTypeMap.java:47)
> at org.apache.qpid.server.protocol.v0_8.AMQTypedValue.readFromBuffer(AMQTypedValue.java:201)
> at org.apache.qpid.server.protocol.v0_8.FieldTable.setFromBuffer(FieldTable.java:1163)
> at org.apache.qpid.server.protocol.v0_8.FieldTable.populateFromBuffer(FieldTable.java:128)
> at org.apache.qpid.server.protocol.v0_8.FieldTable.clearEncodedForm(FieldTable.java:933)
> at org.apache.qpid.server.protocol.v0_8.transport.BasicContentHeaderProperties.clearEncodedForm(BasicContentHeaderProperties.java:959)
> at org.apache.qpid.server.protocol.v0_8.transport.ContentHeaderBody.clearEncodedForm(ContentHeaderBody.java:195)
> at org.apache.qpid.server.protocol.v0_8.MessageMetaData.clearEncodedForm(MessageMetaData.java:140)
> at org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$MessageDataSoftRef.clear(AbstractBDBMessageStore.java:986)
> at org.apache.qpid.server.store.berkeleydb.AbstractBDBMessageStore$StoredBDBMessage.flowToDisk(AbstractBDBMessageStore.java:1263)
> at org.apache.qpid.server.queue.AbstractQueue$FlowToDiskChecker.flowToDiskIfNecessary(AbstractQueue.java:3342)
> at org.apache.qpid.server.queue.AbstractQueue$FlowToDiskChecker.flowToDiskAndReportIfNecessary(AbstractQueue.java:3350)
> at org.apache.qpid.server.queue.AbstractQueue.enqueue(AbstractQueue.java:1105)
> at org.apache.qpid.server.message.RoutingResult$1.postCommit(RoutingResult.java:136)
> at org.apache.qpid.server.txn.LocalTransaction$4.postCommit(LocalTransaction.java:304)
> at org.apache.qpid.server.txn.LocalTransaction.doPostTransactionActions(LocalTransaction.java:433)
> at org.apache.qpid.server.txn.LocalTransaction.commitAsync(LocalTransaction.java:417)
> at org.apache.qpid.server.protocol.v0_8.AMQChannel.commit(AMQChannel.java:1132)
> at org.apache.qpid.server.protocol.v0_8.AMQChannel.receiveTxCommit(AMQChannel.java:3407)
> at org.apache.qpid.server.protocol.v0_8.ServerDecoder.processMethod(ServerDecoder.java:229)
> at org.apache.qpid.server.protocol.v0_8.AMQDecoder.processFrame(AMQDecoder.java:203)
> at org.apache.qpid.server.protocol.v0_8.BrokerDecoder.doProcessFrame(BrokerDecoder.java:141)
> at org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processFrame(BrokerDecoder.java:65)
> at org.apache.qpid.server.protocol.v0_8.AMQDecoder.processInput(AMQDecoder.java:185)
> at org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:104)
> at org.apache.qpid.server.protocol.v0_8.BrokerDecoder$1.run(BrokerDecoder.java:97)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.apache.qpid.server.protocol.v0_8.BrokerDecoder.processAMQPFrames(BrokerDecoder.java:96)
> at org.apache.qpid.server.protocol.v0_8.AMQDecoder.decode(AMQDecoder.java:118)
> at org.apache.qpid.server.protocol.v0_8.ServerDecoder.decodeBuffer(ServerDecoder.java:44)
> at org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:247)
> at org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl$1.run(AMQPConnection_0_8Impl.java:239)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.apache.qpid.server.protocol.v0_8.AMQPConnection_0_8Impl.received(AMQPConnection_0_8Impl.java:238)
> at org.apache.qpid.server.transport.MultiVersionProtocolEngine.received(MultiVersionProtocolEngine.java:130)
> at org.apache.qpid.server.transport.NonBlockingConnection.processAmqpData(NonBlockingConnection.java:593)
> at org.apache.qpid.server.transport.NonBlockingConnectionPlainDelegate.processData(NonBlockingConnectionPlainDelegate.java:58)
> at org.apache.qpid.server.transport.NonBlockingConnection.doRead(NonBlockingConnection.java:483)
> at org.apache.qpid.server.transport.NonBlockingConnection.doWork(NonBlockingConnection.java:270)
> at org.apache.qpid.server.transport.NetworkConnectionScheduler.processConnection(NetworkConnectionScheduler.java:124)
> at org.apache.qpid.server.transport.SelectorThread$ConnectionProcessor.processConnection(SelectorThread.java:563)
> at org.apache.qpid.server.transport.SelectorThread$SelectionTask.performSelect(SelectorThread.java:354)
> at org.apache.qpid.server.transport.SelectorThread$SelectionTask.run(SelectorThread.java:97)
> at org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:521)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> If a consumer is using a different protocol (i.e. 0-10 and 1.0), the attempt to convert the message headers fails and this cause the Broker to crash. If a consumer is using a selector, the message headers need to be decoded to evaluate the header. This too causes the Broker to crash.
> If the message is observed from Management (AMQP or HTTP), the exception is caught and an error returned to the caller. The Broker does not crash. However, internally the FieldTable object's 'map' backing view is left in an incomplete state and a QBB slice is left undisposed. Any properties that followed the property with the unknown type in the encoded form will be absent from the backing map. This will mean that any future observation made by Management will apparently succeed but give incomplete results. Furthermore once the Management observation is made, the message could be delivered to a 0-10/1.0 consuming client but with incomplete headers.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org