[
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: [email protected]
For additional commands, e-mail: [email protected]
