[
https://issues.apache.org/jira/browse/QPID-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13048530#comment-13048530
]
[email protected] commented on QPID-3304:
-----------------------------------------------------
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/888/
-----------------------------------------------------------
Review request for Kim van der Riet, Ted Ross and Steve Huston.
Summary
-------
QPID-3304 is essentially a knock-on effect of the rather nasty fix made for
QPID-2670. The original problem is that the headers were being modified in some
cases after the header body was made available for delivery. This meant that
concurrent delivery and modification could cause seg faults.
This patch attempts to solve that original problem more cleanly. The essential
points of the patch are these:
* prevent access to modifiable header frame outside of message; have explicit
modifying methods on the message class itself where correct locking can be
used. (One exception here is that the message class still allows direct access
to the underlying frames, currently used only in management and clustering as
far as I can tell, both of which are safe by inspection).
* remove the copy-on-write in the queue when adding trace id (i.e. revert
previous fix to QPID-2670 that caused QPID-3304).
* have the copy-on-write pattern encapsulated in the message class itself. I.e.
when the frame containing a pointer to the header body has been written, make
sure subsequent modifications happen to a clone of that body (as the body may
still be in use in delivering the frames to a connection).
There are then a few fixes in tests to use the new message scoped modifiers
rather than manipulating the header external to the message class. These fixes
may also be needed in store specific tests.
This addresses bug QPID-3304.
https://issues.apache.org/jira/browse/QPID-3304
Diffs
-----
/trunk/qpid/cpp/src/qpid/broker/DeliveryRecord.cpp 1130102
/trunk/qpid/cpp/src/qpid/broker/Exchange.cpp 1130102
/trunk/qpid/cpp/src/qpid/broker/Message.h 1130102
/trunk/qpid/cpp/src/qpid/broker/Message.cpp 1131084
/trunk/qpid/cpp/src/qpid/broker/Queue.cpp 1130102
/trunk/qpid/cpp/src/qpid/framing/AMQFrame.h 1130102
/trunk/qpid/cpp/src/qpid/framing/AMQFrame.cpp 1130102
/trunk/qpid/cpp/src/qpid/management/ManagementAgent.cpp 1130102
/trunk/qpid/cpp/src/qpid/replication/ReplicatingEventListener.cpp 1130102
/trunk/qpid/cpp/src/qpid/replication/ReplicationExchange.cpp 1130102
/trunk/qpid/cpp/src/tests/ExchangeTest.cpp 1130102
/trunk/qpid/cpp/src/tests/QueueTest.cpp 1130102
/trunk/qpid/cpp/src/tests/TxPublishTest.cpp 1130102
Diff: https://reviews.apache.org/r/888/diff
Testing
-------
Make check passes
Thanks,
Gordon
> Tagged federation messages in a transaction can cause subsequent dequeue to
> fail
> --------------------------------------------------------------------------------
>
> Key: QPID-3304
> URL: https://issues.apache.org/jira/browse/QPID-3304
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
> Affects Versions: 0.10
> Reporter: Gordon Sim
> Fix For: 0.11
>
>
> E.g. with Error dequeuing message, persistence id not set
> (MessageStoreImpl.cpp:1355) (exact error depends on store used).
> To reproduce, bind a durable queue to an exchange with a given binding key
> the set up a route between that same exchange on two brokers with the 'source
> broker' being the one with the durable queue bound to it. Then bind a queue
> on the 'destination' broker with the same binding key as used for the durable
> queue. Then publish a transactional message to the source brokers exchange
> with a matching routing key. The message will be enqueued on both the durable
> queue and the federation routes temporary bridge queue. However the
> persistence id for the message, set when enqueueing on the durable queue is
> lost and subsequent attempts to dequeue to fail.
> The problem is that the copy-on-write strategy used to workaround QPID-2670
> means that the message on which the persistent store id is set is not then
> pushed onto the appropriate queues, the copy is (and the copy may not have
> the persistence id set on it).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
