[
https://issues.apache.org/jira/browse/QPID-6872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-6872:
-----------------------------
Affects Version/s: (was: qpid-java-6.0)
0.30
0.32
> [Java Broker] Configured Objects with the same names under one parent can be
> created via management interfaces
> --------------------------------------------------------------------------------------------------------------
>
> Key: QPID-6872
> URL: https://issues.apache.org/jira/browse/QPID-6872
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
> Affects Versions: 0.30, 0.32
> Reporter: Alex Rudyy
> Assignee: Keith Wall
> Priority: Blocker
> Fix For: qpid-java-6.0
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
