[jira] [Resolved] (PROTON-1925) [proton-j] Add some enums to Section and DeliveryState to make type determination simpler
[ https://issues.apache.org/jira/browse/PROTON-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Bish resolved PROTON-1925. -- Resolution: Fixed > [proton-j] Add some enums to Section and DeliveryState to make type > determination simpler > - > > Key: PROTON-1925 > URL: https://issues.apache.org/jira/browse/PROTON-1925 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: proton-j-0.29.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Trivial > Fix For: proton-j-0.30.0 > > > Add enums for the known Section and DeliveryState types to allow for easier > identification of the types when writing code to process the events for > incoming messages and delivery state updates. Right now we are forced to use > many instanceof calls to decide what the types are in order to react. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1925) [proton-j] Add some enums to Section and DeliveryState to make type determination simpler
[ https://issues.apache.org/jira/browse/PROTON-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597746#comment-16597746 ] ASF subversion and git services commented on PROTON-1925: - Commit 3be632d436c52373a53e8ae0c27aac1643960021 in qpid-proton-j's branch refs/heads/master from [~tabish121] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton-j.git;h=3be632d ] PROTON-1925 Add enum values for know Section and DeliveryState Allows for simpler identification and processing using switch or other logic instead of instanceof checks for all types. > [proton-j] Add some enums to Section and DeliveryState to make type > determination simpler > - > > Key: PROTON-1925 > URL: https://issues.apache.org/jira/browse/PROTON-1925 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-j >Affects Versions: proton-j-0.29.0 >Reporter: Timothy Bish >Assignee: Timothy Bish >Priority: Trivial > Fix For: proton-j-0.30.0 > > > Add enums for the known Section and DeliveryState types to allow for easier > identification of the types when writing code to process the events for > incoming messages and delivery state updates. Right now we are forced to use > many instanceof calls to decide what the types are in order to react. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-1925) [proton-j] Add some enums to Section and DeliveryState to make type determination simpler
Timothy Bish created PROTON-1925: Summary: [proton-j] Add some enums to Section and DeliveryState to make type determination simpler Key: PROTON-1925 URL: https://issues.apache.org/jira/browse/PROTON-1925 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: proton-j-0.29.0 Reporter: Timothy Bish Assignee: Timothy Bish Fix For: proton-j-0.30.0 Add enums for the known Section and DeliveryState types to allow for easier identification of the types when writing code to process the events for incoming messages and delivery state updates. Right now we are forced to use many instanceof calls to decide what the types are in order to react. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-1110) Intermittent router hang while running QIT's AMQP large content test
[
https://issues.apache.org/jira/browse/DISPATCH-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet updated DISPATCH-1110:
---
Description:
When running the Qpid Interop Test's AMQP large content test, a stand-alone
router will intermittently hang and cause the test to time out.
The failure appears to be limited to either the AMQP list or map types, and
usually with the C++ client as the message sender. The C++, Python2 and
Python3 as receiver clients have all seen this failure, but the Python2
receiver client seems to reproduce more readily on my hardware.
In all cases, the test fails when the router sends what I suppose is the final
transfer of a large message (I have not added up/counted the bytes of the many
preceding transfers) to the consumer. The consumer then sends a disposition,
but the router does not respond again until the test times out. The consumer
can be seen to send heartbeats to the router, but the router does not send any
of its own.
{noformat}
... (plenty of 65550-sized frames R->C)
R->C 5976 3.454766::1 ::1 AMQP65550
R->C 5977 3.454775::1 ::1 AMQP65550
R->C 5978 3.454783::1 ::1 AMQP48171
C->R 5982 3.529881::1 ::1 AMQP115 disposition
C->R 5984 7.530704::1 ::1 AMQP94 (empty)
C->R 5986 11.532306 ::1 ::1 AMQP94 (empty)
...{noformat}
There are no errors to be seen in the router logs other than when the consuming
client is killed owing to the test timeout.
{noformat}
...
2018-08-29 12:50:23.191754 -0400 SERVER (info) [14]: Accepted connection to
::1:amqp from ::1:37262
2018-08-29 12:51:19.562695 -0400 SERVER (info) [14]: Connection from ::1:37262
(to ::1:amqp) failed: amqp:connection:framing-error connection aborted
{noformat}
The reproducer is not very tight on this, and the error occurs about 50% of the
time on my hardware.
was:
When running the Qpid Interop Test's AMQP large content test, a stand-alone
router will intermittently hang and cause the test to time out.
The failure appears to be limited to either the AMQP list or map types, and
usually with the message producer being the C++ client. Both C++, Python2 and
Python3 consumer clients have all seen this failure, but the Python2 client
seems to reproduce more readily on my hardware.
In all cases, the test fails when the router sends what I suppose is the final
transfer of a large message (I have not added up/counted the bytes of the many
preceding transfers) to the consumer. The consumer then sends a disposition,
but the router does not respond again until the test times out. The consumer
can be seen to send heartbeats to the router, but the router does not send any
of its own.
{noformat}
... (plenty of 65550-sized frames R->C)
R->C 5976 3.454766::1 ::1 AMQP65550
R->C 5977 3.454775::1 ::1 AMQP65550
R->C 5978 3.454783::1 ::1 AMQP48171
C->R 5982 3.529881::1 ::1 AMQP115 disposition
C->R 5984 7.530704::1 ::1 AMQP94 (empty)
C->R 5986 11.532306 ::1 ::1 AMQP94 (empty)
...{noformat}
There are no errors to be seen in the router logs other than when the consuming
client is killed owing to the test timeout.
{noformat}
...
2018-08-29 12:50:23.191754 -0400 SERVER (info) [14]: Accepted connection to
::1:amqp from ::1:37262
2018-08-29 12:51:19.562695 -0400 SERVER (info) [14]: Connection from ::1:37262
(to ::1:amqp) failed: amqp:connection:framing-error connection aborted
{noformat}
The reproducer is not very tight on this, and the error occurs about 50% of the
time on my hardware.
> Intermittent router hang while running QIT's AMQP large content test
>
>
> Key: DISPATCH-1110
> URL: https://issues.apache.org/jira/browse/DISPATCH-1110
> Project: Qpid Dispatch
> Issue Type: Bug
> Environment: Standard QIT environment.
> Once QIT is built and installed, the environment is set using the config.sh
> file. See QUICKSTART for details.
>Reporter: Kim van der Riet
>Priority: Major
> Attachments: qdrouterd.conf
>
>
> When running the Qpid Interop Test's AMQP large content test, a stand-alone
> router will intermittently hang and cause the test to time out.
> The failure appears to be limited to either the AMQP list or map types, and
> usually with the C++ client as the message sender. The C++, Python2 and
> Python3 as receiver clients have all seen this failure, but the Python2
> receiver client seems to reproduce more readily on my hardware.
> In all cases, the test fails when the router sends what I suppose is the
> final transfer of a
[jira] [Updated] (DISPATCH-1110) Intermittent router hang while running QIT's AMQP large content test
[
https://issues.apache.org/jira/browse/DISPATCH-1110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kim van der Riet updated DISPATCH-1110:
---
Description:
When running the Qpid Interop Test's AMQP large content test, a stand-alone
router will intermittently hang and cause the test to time out.
The failure appears to be limited to either the AMQP list or map types, and
usually with the message producer being the C++ client. Both C++, Python2 and
Python3 consumer clients have all seen this failure, but the Python2 client
seems to reproduce more readily on my hardware.
In all cases, the test fails when the router sends what I suppose is the final
transfer of a large message (I have not added up/counted the bytes of the many
preceding transfers) to the consumer. The consumer then sends a disposition,
but the router does not respond again until the test times out. The consumer
can be seen to send heartbeats to the router, but the router does not send any
of its own.
{noformat}
... (plenty of 65550-sized frames R->C)
R->C 5976 3.454766::1 ::1 AMQP65550
R->C 5977 3.454775::1 ::1 AMQP65550
R->C 5978 3.454783::1 ::1 AMQP48171
C->R 5982 3.529881::1 ::1 AMQP115 disposition
C->R 5984 7.530704::1 ::1 AMQP94 (empty)
C->R 5986 11.532306 ::1 ::1 AMQP94 (empty)
...{noformat}
There are no errors to be seen in the router logs other than when the consuming
client is killed owing to the test timeout.
{noformat}
...
2018-08-29 12:50:23.191754 -0400 SERVER (info) [14]: Accepted connection to
::1:amqp from ::1:37262
2018-08-29 12:51:19.562695 -0400 SERVER (info) [14]: Connection from ::1:37262
(to ::1:amqp) failed: amqp:connection:framing-error connection aborted
{noformat}
The reproducer is not very tight on this, and the error occurs about 50% of the
time on my hardware.
was:
When running the Qpid Interop Test's AMQP large content test, a stand-alone
router will intermittently hang and cause the test to time out.
The failure appears to be limited to either the AMQP list or map types, and
usually with the producer being the C++ client. Both C++, Python2 and Python3
clients have all seen this failure, but the Python2 client seems to reproduce
more readily on my hardware.
In all cases, the test fails when the router sends what I suppose is the final
transfer of a large message (I have not added up/counted the bytes of the many
preceding transfers) to the consumer. The consumer then sends a disposition,
but the router does not respond again until the test times out. The consumer
can be seen to send heartbeats to the router, but the router does not send any
of its own.
{noformat}
... (plenty of 65550-sized frames R->C)
R->C 5976 3.454766::1 ::1 AMQP65550
R->C 5977 3.454775::1 ::1 AMQP65550
R->C 5978 3.454783::1 ::1 AMQP48171
C->R 5982 3.529881::1 ::1 AMQP115 disposition
C->R 5984 7.530704::1 ::1 AMQP94 (empty)
C->R 5986 11.532306 ::1 ::1 AMQP94 (empty)
...{noformat}
There are no errors to be seen in the router logs other than when the consuming
client is killed owing to the test timeout.
{noformat}
...
2018-08-29 12:50:23.191754 -0400 SERVER (info) [14]: Accepted connection to
::1:amqp from ::1:37262
2018-08-29 12:51:19.562695 -0400 SERVER (info) [14]: Connection from ::1:37262
(to ::1:amqp) failed: amqp:connection:framing-error connection aborted
{noformat}
The reproducer is not very tight on this, and the error occurs about 50% of the
time on my hardware.
> Intermittent router hang while running QIT's AMQP large content test
>
>
> Key: DISPATCH-1110
> URL: https://issues.apache.org/jira/browse/DISPATCH-1110
> Project: Qpid Dispatch
> Issue Type: Bug
> Environment: Standard QIT environment.
> Once QIT is built and installed, the environment is set using the config.sh
> file. See QUICKSTART for details.
>Reporter: Kim van der Riet
>Priority: Major
> Attachments: qdrouterd.conf
>
>
> When running the Qpid Interop Test's AMQP large content test, a stand-alone
> router will intermittently hang and cause the test to time out.
> The failure appears to be limited to either the AMQP list or map types, and
> usually with the message producer being the C++ client. Both C++, Python2
> and Python3 consumer clients have all seen this failure, but the Python2
> client seems to reproduce more readily on my hardware.
> In all cases, the test fails when the router sends what I suppose is the
> final transfer of a large message (I have not
[jira] [Resolved] (QPID-8229) [Broker-J][6.x] Queue bindings are not removed on queue deletion when BDB/DERBY/JDBC configuration stores are used
[
https://issues.apache.org/jira/browse/QPID-8229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall resolved QPID-8229.
--
Resolution: Fixed
> [Broker-J][6.x] Queue bindings are not removed on queue deletion when
> BDB/DERBY/JDBC configuration stores are used
> --
>
> Key: QPID-8229
> URL: https://issues.apache.org/jira/browse/QPID-8229
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-6.1, qpid-java-6.1.2,
> qpid-java-6.1.3, qpid-java-6.1.4, qpid-java-6.1.5
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-6.1.7
>
>
> Queue bindings can be left behind in BDB/DERBY/JDBC configuration stores on
> queue deletion. When virtual host with a deleted queue and orphaned binding
> is restarted, the Virtual Host startup fails with error "422 - No parent of
> class Queue found.". The following warning is reported into the logs:
> {noformat}
> WARN [HttpManagement-HTTP-379] (o.a.q.s.m.p.s.r.RestServlet) -
> IllegalArgumentException processing request
> http://localhost:8080/api/latest/virtualhost/tmp2/tmp2 from user
> '[/0:0:0:0:0:0:0:1:61279, admin]': No parent of class Queue found.
> {noformat}
> The work-around for the issue would a deletion of all queue bindings prior
> queue deletion. There is no work around which would allow to delete orphaned
> bindings and recover Virtual Host configuration apart from changing store
> data directly which is not feasible in case of BDB.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8229) [Broker-J][6.x] Queue bindings are not removed on queue deletion when BDB/DERBY/JDBC configuration stores are used
[
https://issues.apache.org/jira/browse/QPID-8229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597162#comment-16597162
]
Keith Wall commented on QPID-8229:
--
Seems okay to me.
> [Broker-J][6.x] Queue bindings are not removed on queue deletion when
> BDB/DERBY/JDBC configuration stores are used
> --
>
> Key: QPID-8229
> URL: https://issues.apache.org/jira/browse/QPID-8229
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, qpid-java-6.1, qpid-java-6.1.2,
> qpid-java-6.1.3, qpid-java-6.1.4, qpid-java-6.1.5
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Critical
> Fix For: qpid-java-6.1.7
>
>
> Queue bindings can be left behind in BDB/DERBY/JDBC configuration stores on
> queue deletion. When virtual host with a deleted queue and orphaned binding
> is restarted, the Virtual Host startup fails with error "422 - No parent of
> class Queue found.". The following warning is reported into the logs:
> {noformat}
> WARN [HttpManagement-HTTP-379] (o.a.q.s.m.p.s.r.RestServlet) -
> IllegalArgumentException processing request
> http://localhost:8080/api/latest/virtualhost/tmp2/tmp2 from user
> '[/0:0:0:0:0:0:0:1:61279, admin]': No parent of class Queue found.
> {noformat}
> The work-around for the issue would a deletion of all queue bindings prior
> queue deletion. There is no work around which would allow to delete orphaned
> bindings and recover Virtual Host configuration apart from changing store
> data directly which is not feasible in case of BDB.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8236) [Broker-J] Changing of group name, address or node name in BDB HA virtual host node should be disallowed
[
https://issues.apache.org/jira/browse/QPID-8236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keith Wall resolved QPID-8236.
--
Resolution: Fixed
> [Broker-J] Changing of group name, address or node name in BDB HA virtual
> host node should be disallowed
> -
>
> Key: QPID-8236
> URL: https://issues.apache.org/jira/browse/QPID-8236
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, 0.32, qpid-java-6.0.8,
> qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-6.1.7, qpid-java-broker-7.1.0,
> qpid-java-broker-7.0.7
>
>
> The BDB HA Virtual Host Node group name, address or node name can be changed
> using management interfaces, for example REST API. However, the change of
> this attributes is not reflected in the underlying BDB JE infrastructure. In
> fact, the change of group name, address or node name is unsupported by BDB
> JE. The only way any of them can be changed is by resetting the group
> information using BDB JE utility {{DbResetRepGroup}} which resets the group
> to a single node.
> The Qpid Broker should not allow to change group name, address or node name
> attributes in BDB HA Virtual Host node via management API.
> If group is changed, on next broker restart the impacted {{VHN}} fails to
> start with the following error logged into broker logs:
> {noformat}
> ERROR [qtp699327636-161] (o.a.q.s.m.p.f.ExceptionHandlingFilter) - Unexpected
> exception in servlet '/api/latest/virtualhostnode/node1':
> java.lang.RuntimeException: Unexpected exception on environment creation
> at
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.createEnvironmentInSeparateThread(ReplicatedEnvironmentFacade.java:1578)
> at
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.createEnvironment(ReplicatedEnvironmentFacade.java:1526)
> at
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.(ReplicatedEnvironmentFacade.java:288)
> at
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacadeFactory.createEnvironmentFacade(ReplicatedEnvironmentFacadeFactory.java:130)
> at
> org.apache.qpid.server.store.berkeleydb.BDBConfigurationStore.init(BDBConfigurationStore.java:120)
> at
> org.apache.qpid.server.virtualhostnode.berkeleydb.BDBHAVirtualHostNodeImpl.activate(BDBHAVirtualHostNodeImpl.java:338)
> at
> org.apache.qpid.server.virtualhostnode.AbstractVirtualHostNode.doActivate(AbstractVirtualHostNode.java:169)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1526)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1505)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainStateIfOpenedOrReopenFailed(AbstractConfiguredObject.java:1489)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.access$1700(AbstractConfiguredObject.java:97)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$15.execute(AbstractConfiguredObject.java:1716)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$15.execute(AbstractConfiguredObject.java:1678)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:639)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:632)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:248)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper$1.run(TaskExecutorImpl.java:320)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper.call(TaskExecutorImpl.java:313)
> at
> com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:111)
> at
> com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:58)
> at
>
[jira] [Commented] (QPID-8236) [Broker-J] Changing of group name, address or node name in BDB HA virtual host node should be disallowed
[
https://issues.apache.org/jira/browse/QPID-8236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16597154#comment-16597154
]
Keith Wall commented on QPID-8236:
--
Change looks reasonable to me.
> [Broker-J] Changing of group name, address or node name in BDB HA virtual
> host node should be disallowed
> -
>
> Key: QPID-8236
> URL: https://issues.apache.org/jira/browse/QPID-8236
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-6.1.6, 0.32, qpid-java-6.0.8,
> qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Assignee: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-6.1.7, qpid-java-broker-7.1.0,
> qpid-java-broker-7.0.7
>
>
> The BDB HA Virtual Host Node group name, address or node name can be changed
> using management interfaces, for example REST API. However, the change of
> this attributes is not reflected in the underlying BDB JE infrastructure. In
> fact, the change of group name, address or node name is unsupported by BDB
> JE. The only way any of them can be changed is by resetting the group
> information using BDB JE utility {{DbResetRepGroup}} which resets the group
> to a single node.
> The Qpid Broker should not allow to change group name, address or node name
> attributes in BDB HA Virtual Host node via management API.
> If group is changed, on next broker restart the impacted {{VHN}} fails to
> start with the following error logged into broker logs:
> {noformat}
> ERROR [qtp699327636-161] (o.a.q.s.m.p.f.ExceptionHandlingFilter) - Unexpected
> exception in servlet '/api/latest/virtualhostnode/node1':
> java.lang.RuntimeException: Unexpected exception on environment creation
> at
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.createEnvironmentInSeparateThread(ReplicatedEnvironmentFacade.java:1578)
> at
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.createEnvironment(ReplicatedEnvironmentFacade.java:1526)
> at
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacade.(ReplicatedEnvironmentFacade.java:288)
> at
> org.apache.qpid.server.store.berkeleydb.replication.ReplicatedEnvironmentFacadeFactory.createEnvironmentFacade(ReplicatedEnvironmentFacadeFactory.java:130)
> at
> org.apache.qpid.server.store.berkeleydb.BDBConfigurationStore.init(BDBConfigurationStore.java:120)
> at
> org.apache.qpid.server.virtualhostnode.berkeleydb.BDBHAVirtualHostNodeImpl.activate(BDBHAVirtualHostNodeImpl.java:338)
> at
> org.apache.qpid.server.virtualhostnode.AbstractVirtualHostNode.doActivate(AbstractVirtualHostNode.java:169)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1526)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainState(AbstractConfiguredObject.java:1505)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.attainStateIfOpenedOrReopenFailed(AbstractConfiguredObject.java:1489)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.access$1700(AbstractConfiguredObject.java:97)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$15.execute(AbstractConfiguredObject.java:1716)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$15.execute(AbstractConfiguredObject.java:1678)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:639)
> at
> org.apache.qpid.server.model.AbstractConfiguredObject$2.execute(AbstractConfiguredObject.java:632)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:248)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper$1.run(TaskExecutorImpl.java:320)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:360)
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$CallableWrapper.call(TaskExecutorImpl.java:313)
> at
> com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:111)
> at
>
