Details
-
Bug
-
Status: Resolved
-
Blocker
-
Resolution: Fixed
-
0.30, 0.32
-
None
Description
On testing web management console I managed to created 2 kesytores with name "test". First I created FileKeystore with name "test" and then I tried to create AutoGeneratedSelfSigned keystore with the same name "test". Creation of AutoGeneratedSelfSigned resulted in ERROR reported by the broker about existence of an object with the same name but AutoGeneratedSelfSigned keystore with name "test" was created anyway and stored in configuration store.
(Updated k-wall 2015-12-18) The regression was introduced at 0.30 (work of QPID-5710). Problem is general and affects all child types including queues and exchanges. As the Qpid client's default behaviour is to declare/bind queues on creation of a JMS consumer, it is possible that an user may see this defect when an application that creates competing consumers is started up for the first time. The consumers would race to create the same queue and in an unlucky case two or more would get to call o.a.q.c.AMQSession#bindQueue(). The queue (child) creation is single threaded server side, so the first would create the queue, the second would fail with a QueueExistsException internally which o.a.q.s.p.v0_8.AMQChannel#receiveQueueDeclare would ultimately interpret as success and send a queue-declare-ok back to the client. However, on the server side, the configuration would be corrupted in the way described above, meaning the Broker would fail to restart. The user could recover (if using a JSON based VHN), by editing the store and removing the duplicate queue entry. Message lose would not occur.