[
https://issues.apache.org/jira/browse/QPID-6872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall updated QPID-6872:
-----------------------------
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.
was:
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-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 {{org.apache.qpid.client.AMQSession#bindQueue()}}. All
> [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]
