[jira] [Resolved] (QPID-7090) qpidd should not use root as user
[ https://issues.apache.org/jira/browse/QPID-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross resolved QPID-7090. --- Resolution: Fixed > qpidd should not use root as user > - > > Key: QPID-7090 > URL: https://issues.apache.org/jira/browse/QPID-7090 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: qpid-cpp-0.34 > Environment: Debian/Ubuntu >Reporter: Morgan Lindqvist >Assignee: Irina Boverman >Priority: Minor > Labels: features, packaging, security > > When using the testing PPA on https://launchpad.net/~qpid to install qpidd > the daemon is executed using the user id and group id "root". > The user id and group id that should be used is "qpidd". > This will significantly reduce the risk the the daemon can be used to get > root access on the server. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-236) Provide thread sanitizer build option
[ https://issues.apache.org/jira/browse/DISPATCH-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191470#comment-15191470 ] ASF subversion and git services commented on DISPATCH-236: -- Commit c6ccf1e1b49eeb27279dba227dd01627a931e610 in qpid-dispatch's branch refs/heads/master from [~kgiusti] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=c6ccf1e ] DISPATCH-236: Allow the valgrind tool and suppression file to be customized. > Provide thread sanitizer build option > - > > Key: DISPATCH-236 > URL: https://issues.apache.org/jira/browse/DISPATCH-236 > Project: Qpid Dispatch > Issue Type: Test > Components: Router Node >Affects Versions: 0.5 >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Minor > Fix For: 0.6 > > > GNU C versions >= 4.8 add the ability to enable run-time thread checking. > Much like helgrind, but faster as it is built into the run time binary. > Add a cmake configuration option to enable building the executable with > run-time thread checking. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7090) qpidd should not use root as user
[ https://issues.apache.org/jira/browse/QPID-7090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191462#comment-15191462 ] Irina Boverman commented on QPID-7090: -- Resolved in qpid-cpp (0.34-3trusty+qpid1). > qpidd should not use root as user > - > > Key: QPID-7090 > URL: https://issues.apache.org/jira/browse/QPID-7090 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: qpid-cpp-0.34 > Environment: Debian/Ubuntu >Reporter: Morgan Lindqvist >Assignee: Irina Boverman >Priority: Minor > Labels: features, packaging, security > > When using the testing PPA on https://launchpad.net/~qpid to install qpidd > the daemon is executed using the user id and group id "root". > The user id and group id that should be used is "qpidd". > This will significantly reduce the risk the the daemon can be used to get > root access on the server. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-179) Refactor Router Core
[ https://issues.apache.org/jira/browse/DISPATCH-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191225#comment-15191225 ] ASF subversion and git services commented on DISPATCH-179: -- Commit 0a98b3a17522149392708e30805ed2578ea8 in qpid-dispatch's branch refs/heads/tross-DISPATCH-179-1 from [~ganeshmurthy] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=0a98b3a ] DISPATCH-179 - Implemented plumbing for management delete of route objects > Refactor Router Core > > > Key: DISPATCH-179 > URL: https://issues.apache.org/jira/browse/DISPATCH-179 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Reporter: Ted Ross >Assignee: Ted Ross > Fix For: 0.6 > > > Refactor the core router function to clean up the architecture and to fix the > significant lock contention issue that exists in 0.5. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-179) Refactor Router Core
[ https://issues.apache.org/jira/browse/DISPATCH-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191100#comment-15191100 ] ASF subversion and git services commented on DISPATCH-179: -- Commit bd0f5585f7a821f27804acf07572448f297b760c in qpid-dispatch's branch refs/heads/tross-DISPATCH-179-1 from [~tr...@redhat.com] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=bd0f558 ] DISPATCH-179 - Added a core function for invoking custom management methods. > Refactor Router Core > > > Key: DISPATCH-179 > URL: https://issues.apache.org/jira/browse/DISPATCH-179 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Reporter: Ted Ross >Assignee: Ted Ross > Fix For: 0.6 > > > Refactor the core router function to clean up the architecture and to fix the > significant lock contention issue that exists in 0.5. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Issue Comment Deleted] (QPIDJMS-154) Failover mechanism does not handle connection URLs in a predictable way
[
https://issues.apache.org/jira/browse/QPIDJMS-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish updated QPIDJMS-154:
-
Comment: was deleted
(was: When possble it is also helpful to capture a trace of the frames so we
can see what is going on under the covers, there's a bit on that in the docs in
the logging section at the end here:
https://qpid.apache.org/releases/qpid-jms-0.8.0/docs/index.html)
> Failover mechanism does not handle connection URLs in a predictable way
> ---
>
> Key: QPIDJMS-154
> URL: https://issues.apache.org/jira/browse/QPIDJMS-154
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.8.0
>Reporter: Adel Boutros
>Assignee: Timothy Bish
> Attachments: Broker1.png, broker2.png
>
>
> As discussed in this
> [link|http://qpid.2158936.n2.nabble.com/Unhandled-exception-when-using-High-Availabilty-in-Qpid-Java-Broker-6-0-0-td7639896.html],
> if the links provided in the failover URL are ordered in a way to have the
> Replicate first and then the Master. Then the connection will fail and an
> error will be thrown client-side.
> This is because the multi-threading behavior in the FailoverProvider is not
> correct. The main thread will not wait for the connection trial thread to try
> and find the active Master node. If we add a Sleep or debug the main thread
> to give the connection trial thread enough time to find the Master URL then
> the test works
> *_Log in case of failure:_*
> {code}
> 2016-03-11 10:46:31 DEBUG FailoverProvider:160 - Initiating initial
> connection attempt task
> 2016-03-11 10:46:33 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:10352?amqp.vhost=weather in-progress
> 2016-03-11 10:46:34 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 10:46:34 DEBUG FailoverProvider:761 - Failover: the provider
> reports failure: Received error from remote peer without description
> [condition = amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:519 - handling Provider failure:
> Received error from remote peer without description [condition =
> amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:5672?amqp.vhost=weather in-progress
> 2016-03-11 10:46:31 DEBUG FailoverProvider:160 - Initiating initial
> connection attempt task
> 2016-03-11 10:46:33 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:10352?amqp.vhost=weather in-progress
> 2016-03-11 10:46:34 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 10:46:34 DEBUG FailoverProvider:761 - Failover: the provider
> reports failure: Received error from remote peer without description
> [condition = amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:519 - handling Provider failure:
> Received error from remote peer without description [condition =
> amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:5672?amqp.vhost=weather in-progress
> {code}
> *_Logs in case we debug the main thread to allow the connection thread to
> finish:_*
> {code}
> 2016-03-11 11:03:37 DEBUG FailoverProvider:160 - Initiating initial
> connection attempt task
> 2016-03-11 11:04:05 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:10352?amqp.vhost=weather in-progress
> 2016-03-11 11:04:18 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 11:04:18 DEBUG FailoverProvider:985 - Request received error:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:519 - handling Provider failure:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:985 - Request received error:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:761 - Failover: the provider
> reports failure: Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:519 - handling Provider failure:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:519 - handling Provider failure:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:40 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:5672?amqp.vhost=weather in-progress
> 2016-03-11 11:04:41 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 11:04:42 INFO JmsConnection:1114 - Connection
> ID::af28891b-adbe-47f1-9da2-ad03f124a215:1 connected to remote Broker:
> amqp://localhost:5672
> 2016-03-11 11:04:42 DEBUG
[jira] [Commented] (QPIDJMS-154) Failover mechanism does not handle connection URLs in a predictable way
[
https://issues.apache.org/jira/browse/QPIDJMS-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191093#comment-15191093
]
Timothy Bish commented on QPIDJMS-154:
--
When possble it is also helpful to capture a trace of the frames so we can see
what is going on under the covers, there's a bit on that in the docs in the
logging section at the end here:
https://qpid.apache.org/releases/qpid-jms-0.8.0/docs/index.html
> Failover mechanism does not handle connection URLs in a predictable way
> ---
>
> Key: QPIDJMS-154
> URL: https://issues.apache.org/jira/browse/QPIDJMS-154
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.8.0
>Reporter: Adel Boutros
>Assignee: Timothy Bish
> Attachments: Broker1.png, broker2.png
>
>
> As discussed in this
> [link|http://qpid.2158936.n2.nabble.com/Unhandled-exception-when-using-High-Availabilty-in-Qpid-Java-Broker-6-0-0-td7639896.html],
> if the links provided in the failover URL are ordered in a way to have the
> Replicate first and then the Master. Then the connection will fail and an
> error will be thrown client-side.
> This is because the multi-threading behavior in the FailoverProvider is not
> correct. The main thread will not wait for the connection trial thread to try
> and find the active Master node. If we add a Sleep or debug the main thread
> to give the connection trial thread enough time to find the Master URL then
> the test works
> *_Log in case of failure:_*
> {code}
> 2016-03-11 10:46:31 DEBUG FailoverProvider:160 - Initiating initial
> connection attempt task
> 2016-03-11 10:46:33 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:10352?amqp.vhost=weather in-progress
> 2016-03-11 10:46:34 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 10:46:34 DEBUG FailoverProvider:761 - Failover: the provider
> reports failure: Received error from remote peer without description
> [condition = amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:519 - handling Provider failure:
> Received error from remote peer without description [condition =
> amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:5672?amqp.vhost=weather in-progress
> 2016-03-11 10:46:31 DEBUG FailoverProvider:160 - Initiating initial
> connection attempt task
> 2016-03-11 10:46:33 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:10352?amqp.vhost=weather in-progress
> 2016-03-11 10:46:34 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 10:46:34 DEBUG FailoverProvider:761 - Failover: the provider
> reports failure: Received error from remote peer without description
> [condition = amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:519 - handling Provider failure:
> Received error from remote peer without description [condition =
> amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:5672?amqp.vhost=weather in-progress
> {code}
> *_Logs in case we debug the main thread to allow the connection thread to
> finish:_*
> {code}
> 2016-03-11 11:03:37 DEBUG FailoverProvider:160 - Initiating initial
> connection attempt task
> 2016-03-11 11:04:05 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:10352?amqp.vhost=weather in-progress
> 2016-03-11 11:04:18 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 11:04:18 DEBUG FailoverProvider:985 - Request received error:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:519 - handling Provider failure:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:985 - Request received error:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:761 - Failover: the provider
> reports failure: Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:519 - handling Provider failure:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:519 - handling Provider failure:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:40 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:5672?amqp.vhost=weather in-progress
> 2016-03-11 11:04:41 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 11:04:42 INFO JmsConnection:1114 - Connection
> ID::af28891b-adbe-47f1-9da2-ad03f124a215:1 connected to remote Broker:
> amqp://localhost:5672
> 2016-03-11 11:04:42
[jira] [Commented] (QPIDJMS-154) Failover mechanism does not handle connection URLs in a predictable way
[
https://issues.apache.org/jira/browse/QPIDJMS-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191087#comment-15191087
]
Timothy Bish commented on QPIDJMS-154:
--
When possble it is also helpful to capture a trace of the frames so we can see
what is going on under the covers, there's a bit on that in the docs in the
logging section at the end here:
https://qpid.apache.org/releases/qpid-jms-0.8.0/docs/index.html
> Failover mechanism does not handle connection URLs in a predictable way
> ---
>
> Key: QPIDJMS-154
> URL: https://issues.apache.org/jira/browse/QPIDJMS-154
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.8.0
>Reporter: Adel Boutros
>Assignee: Timothy Bish
> Attachments: Broker1.png, broker2.png
>
>
> As discussed in this
> [link|http://qpid.2158936.n2.nabble.com/Unhandled-exception-when-using-High-Availabilty-in-Qpid-Java-Broker-6-0-0-td7639896.html],
> if the links provided in the failover URL are ordered in a way to have the
> Replicate first and then the Master. Then the connection will fail and an
> error will be thrown client-side.
> This is because the multi-threading behavior in the FailoverProvider is not
> correct. The main thread will not wait for the connection trial thread to try
> and find the active Master node. If we add a Sleep or debug the main thread
> to give the connection trial thread enough time to find the Master URL then
> the test works
> *_Log in case of failure:_*
> {code}
> 2016-03-11 10:46:31 DEBUG FailoverProvider:160 - Initiating initial
> connection attempt task
> 2016-03-11 10:46:33 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:10352?amqp.vhost=weather in-progress
> 2016-03-11 10:46:34 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 10:46:34 DEBUG FailoverProvider:761 - Failover: the provider
> reports failure: Received error from remote peer without description
> [condition = amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:519 - handling Provider failure:
> Received error from remote peer without description [condition =
> amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:5672?amqp.vhost=weather in-progress
> 2016-03-11 10:46:31 DEBUG FailoverProvider:160 - Initiating initial
> connection attempt task
> 2016-03-11 10:46:33 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:10352?amqp.vhost=weather in-progress
> 2016-03-11 10:46:34 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 10:46:34 DEBUG FailoverProvider:761 - Failover: the provider
> reports failure: Received error from remote peer without description
> [condition = amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:519 - handling Provider failure:
> Received error from remote peer without description [condition =
> amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:5672?amqp.vhost=weather in-progress
> {code}
> *_Logs in case we debug the main thread to allow the connection thread to
> finish:_*
> {code}
> 2016-03-11 11:03:37 DEBUG FailoverProvider:160 - Initiating initial
> connection attempt task
> 2016-03-11 11:04:05 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:10352?amqp.vhost=weather in-progress
> 2016-03-11 11:04:18 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 11:04:18 DEBUG FailoverProvider:985 - Request received error:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:519 - handling Provider failure:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:985 - Request received error:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:761 - Failover: the provider
> reports failure: Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:519 - handling Provider failure:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:519 - handling Provider failure:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:40 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:5672?amqp.vhost=weather in-progress
> 2016-03-11 11:04:41 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 11:04:42 INFO JmsConnection:1114 - Connection
> ID::af28891b-adbe-47f1-9da2-ad03f124a215:1 connected to remote Broker:
> amqp://localhost:5672
> 2016-03-11 11:04:42
[jira] [Assigned] (QPIDJMS-154) Failover mechanism does not handle connection URLs in a predictable way
[
https://issues.apache.org/jira/browse/QPIDJMS-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Timothy Bish reassigned QPIDJMS-154:
Assignee: Timothy Bish
> Failover mechanism does not handle connection URLs in a predictable way
> ---
>
> Key: QPIDJMS-154
> URL: https://issues.apache.org/jira/browse/QPIDJMS-154
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.8.0
>Reporter: Adel Boutros
>Assignee: Timothy Bish
> Attachments: Broker1.png, broker2.png
>
>
> As discussed in this
> [link|http://qpid.2158936.n2.nabble.com/Unhandled-exception-when-using-High-Availabilty-in-Qpid-Java-Broker-6-0-0-td7639896.html],
> if the links provided in the failover URL are ordered in a way to have the
> Replicate first and then the Master. Then the connection will fail and an
> error will be thrown client-side.
> This is because the multi-threading behavior in the FailoverProvider is not
> correct. The main thread will not wait for the connection trial thread to try
> and find the active Master node. If we add a Sleep or debug the main thread
> to give the connection trial thread enough time to find the Master URL then
> the test works
> *_Log in case of failure:_*
> {code}
> 2016-03-11 10:46:31 DEBUG FailoverProvider:160 - Initiating initial
> connection attempt task
> 2016-03-11 10:46:33 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:10352?amqp.vhost=weather in-progress
> 2016-03-11 10:46:34 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 10:46:34 DEBUG FailoverProvider:761 - Failover: the provider
> reports failure: Received error from remote peer without description
> [condition = amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:519 - handling Provider failure:
> Received error from remote peer without description [condition =
> amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:5672?amqp.vhost=weather in-progress
> 2016-03-11 10:46:31 DEBUG FailoverProvider:160 - Initiating initial
> connection attempt task
> 2016-03-11 10:46:33 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:10352?amqp.vhost=weather in-progress
> 2016-03-11 10:46:34 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 10:46:34 DEBUG FailoverProvider:761 - Failover: the provider
> reports failure: Received error from remote peer without description
> [condition = amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:519 - handling Provider failure:
> Received error from remote peer without description [condition =
> amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:5672?amqp.vhost=weather in-progress
> {code}
> *_Logs in case we debug the main thread to allow the connection thread to
> finish:_*
> {code}
> 2016-03-11 11:03:37 DEBUG FailoverProvider:160 - Initiating initial
> connection attempt task
> 2016-03-11 11:04:05 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:10352?amqp.vhost=weather in-progress
> 2016-03-11 11:04:18 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 11:04:18 DEBUG FailoverProvider:985 - Request received error:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:519 - handling Provider failure:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:985 - Request received error:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:761 - Failover: the provider
> reports failure: Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:519 - handling Provider failure:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:519 - handling Provider failure:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:40 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:5672?amqp.vhost=weather in-progress
> 2016-03-11 11:04:41 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 11:04:42 INFO JmsConnection:1114 - Connection
> ID::af28891b-adbe-47f1-9da2-ad03f124a215:1 connected to remote Broker:
> amqp://localhost:5672
> 2016-03-11 11:04:42 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsSessionInfo {} (2)
> {code}
> *_Test code:_*
> {code:java}
> @Test
> public void testScalabilityReversedOrder() throws JMSException {
> String brokerUrl =
>
[jira] [Commented] (DISPATCH-179) Refactor Router Core
[ https://issues.apache.org/jira/browse/DISPATCH-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15191032#comment-15191032 ] ASF subversion and git services commented on DISPATCH-179: -- Commit 90775af4126f32ed75ab7323234a997611d685b0 in qpid-dispatch's branch refs/heads/tross-DISPATCH-179-1 from [~ganeshmurthy] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=90775af ] DISPATCH-179 - Removed wrong comment on ConnectorEntity delete. Cut and paste mistake > Refactor Router Core > > > Key: DISPATCH-179 > URL: https://issues.apache.org/jira/browse/DISPATCH-179 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Router Node >Reporter: Ted Ross >Assignee: Ted Ross > Fix For: 0.6 > > > Refactor the core router function to clean up the architecture and to fix the > significant lock contention issue that exists in 0.5. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-232) Add capability to delete listeners and connectors via the qdmanage DELETE operation
[ https://issues.apache.org/jira/browse/DISPATCH-232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved DISPATCH-232. --- Resolution: Fixed Fix Version/s: 0.6 > Add capability to delete listeners and connectors via the qdmanage DELETE > operation > --- > > Key: DISPATCH-232 > URL: https://issues.apache.org/jira/browse/DISPATCH-232 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 0.5 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy > Fix For: 0.6 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-232) Add capability to delete listeners and connectors via the qdmanage DELETE operation
[ https://issues.apache.org/jira/browse/DISPATCH-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15190984#comment-15190984 ] ASF GitHub Bot commented on DISPATCH-232: - Github user ganeshmurthy closed the pull request at: https://github.com/apache/qpid-dispatch/pull/55 > Add capability to delete listeners and connectors via the qdmanage DELETE > operation > --- > > Key: DISPATCH-232 > URL: https://issues.apache.org/jira/browse/DISPATCH-232 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 0.5 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request: DISPATCH-232 - Add capability to delet...
Github user ganeshmurthy closed the pull request at: https://github.com/apache/qpid-dispatch/pull/55 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-232) Add capability to delete listeners and connectors via the qdmanage DELETE operation
[ https://issues.apache.org/jira/browse/DISPATCH-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15190976#comment-15190976 ] ASF subversion and git services commented on DISPATCH-232: -- Commit 68aab3815919a549fae4d44014fbce813ac57704 in qpid-dispatch's branch refs/heads/tross-DISPATCH-179-1 from [~ganeshmurthy] [ https://git-wip-us.apache.org/repos/asf?p=qpid-dispatch.git;h=68aab38 ] DISPATCH-232 - Add capability to delete listeners and connectors via the qdmanage DELETE operation > Add capability to delete listeners and connectors via the qdmanage DELETE > operation > --- > > Key: DISPATCH-232 > URL: https://issues.apache.org/jira/browse/DISPATCH-232 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 0.5 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] qpid-dispatch pull request: DISPATCH-232 - Add capability to delet...
Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/58 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-232) Add capability to delete listeners and connectors via the qdmanage DELETE operation
[ https://issues.apache.org/jira/browse/DISPATCH-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15190977#comment-15190977 ] ASF GitHub Bot commented on DISPATCH-232: - Github user asfgit closed the pull request at: https://github.com/apache/qpid-dispatch/pull/58 > Add capability to delete listeners and connectors via the qdmanage DELETE > operation > --- > > Key: DISPATCH-232 > URL: https://issues.apache.org/jira/browse/DISPATCH-232 > Project: Qpid Dispatch > Issue Type: Improvement > Components: Container >Affects Versions: 0.5 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy > -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-7113) [Java Broker] Add ability to select cipher suite during TLS negotiation based on Broker side cipher suite order
[ https://issues.apache.org/jira/browse/QPID-7113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy resolved QPID-7113. -- Resolution: Fixed The changes look reasonable. I would consider inclusion of implemented changes into 6.0.x branch for 6.0.2 release > [Java Broker] Add ability to select cipher suite during TLS negotiation based > on Broker side cipher suite order > --- > > Key: QPID-7113 > URL: https://issues.apache.org/jira/browse/QPID-7113 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Alex Rudyy > Fix For: qpid-java-6.1 > > > During TLS handshaking, the client requests to negotiate a cipher suite from > a list of cryptographic options that it supports, starting with its first > preference. Then, the server selects a single cipher suite from the list of > cipher suites requested by the client. Normally, the selection honors the > client's preference. > Broker should be able to select cipher suites based on its own preference > rather than the client's preference in order to mitigate the risks of using > weak cipher suites. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7092) User identity must be unique
[ https://issues.apache.org/jira/browse/QPID-7092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15190862#comment-15190862 ] Keith Wall commented on QPID-7092: -- https://cwiki.apache.org/confluence/display/qpid/Identity+in+the+Java+Broker > User identity must be unique > > > Key: QPID-7092 > URL: https://issues.apache.org/jira/browse/QPID-7092 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall > Fix For: qpid-java-6.1 > > > The Java Broker's model has an authentication provider associated with each > port. This means that a single Broker may be configured to use more than > authentication provider at once. For instance, it would be possible to use > LDAP authentication for messaging connections and use OAUTH2 for management. > Currently a user's identity within the Broker represented by a simple name > (string). This approach gives rise to the possibility of a conflict: a user > 'fred' from an authentication provider A may not be the same person as user > 'fred' from authentication system B. At the moment the group provider > implementations and access control can not distinguish. > Authentication providers need to have the ability to produce a unique stable > identifier for each user.Group providers and access control providers > need a mechanism ability to act for only identities from a particular > authentication provider source(s). -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7113) [Java Broker] Add ability to select cipher suite during TLS negotiation based on Broker side cipher suite order
[ https://issues.apache.org/jira/browse/QPID-7113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15190844#comment-15190844 ] ASF subversion and git services commented on QPID-7113: --- Commit 1734542 from [~godfrer] in branch 'java/trunk' [ https://svn.apache.org/r1734542 ] QPID-7113 : Also set cipher order on WebSocket provider > [Java Broker] Add ability to select cipher suite during TLS negotiation based > on Broker side cipher suite order > --- > > Key: QPID-7113 > URL: https://issues.apache.org/jira/browse/QPID-7113 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Alex Rudyy > Fix For: qpid-java-6.1 > > > During TLS handshaking, the client requests to negotiate a cipher suite from > a list of cryptographic options that it supports, starting with its first > preference. Then, the server selects a single cipher suite from the list of > cipher suites requested by the client. Normally, the selection honors the > client's preference. > Broker should be able to select cipher suites based on its own preference > rather than the client's preference in order to mitigate the risks of using > weak cipher suites. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7113) [Java Broker] Add ability to select cipher suite during TLS negotiation based on Broker side cipher suite order
[ https://issues.apache.org/jira/browse/QPID-7113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15190832#comment-15190832 ] ASF subversion and git services commented on QPID-7113: --- Commit 1734541 from [~godfrer] in branch 'java/trunk' [ https://svn.apache.org/r1734541 ] QPID-7113 : Fix typos in field name > [Java Broker] Add ability to select cipher suite during TLS negotiation based > on Broker side cipher suite order > --- > > Key: QPID-7113 > URL: https://issues.apache.org/jira/browse/QPID-7113 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Alex Rudyy > Fix For: qpid-java-6.1 > > > During TLS handshaking, the client requests to negotiate a cipher suite from > a list of cryptographic options that it supports, starting with its first > preference. Then, the server selects a single cipher suite from the list of > cipher suites requested by the client. Normally, the selection honors the > client's preference. > Broker should be able to select cipher suites based on its own preference > rather than the client's preference in order to mitigate the risks of using > weak cipher suites. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-154) Failover mechanism does not handle connection URLs in a predictable way
[
https://issues.apache.org/jira/browse/QPIDJMS-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adel Boutros updated QPIDJMS-154:
-
Attachment: broker2.png
Broker1.png
Broker's configuration
> Failover mechanism does not handle connection URLs in a predictable way
> ---
>
> Key: QPIDJMS-154
> URL: https://issues.apache.org/jira/browse/QPIDJMS-154
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.8.0
>Reporter: Adel Boutros
> Attachments: Broker1.png, broker2.png
>
>
> As discussed in this
> [link|http://qpid.2158936.n2.nabble.com/Unhandled-exception-when-using-High-Availabilty-in-Qpid-Java-Broker-6-0-0-td7639896.html],
> if the links provided in the failover URL are ordered in a way to have the
> Replicate first and then the Master. Then the connection will fail and an
> error will be thrown client-side.
> This is because the multi-threading behavior in the FailoverProvider is not
> correct. The main thread will not wait for the connection trial thread to try
> and find the active Master node. If we add a Sleep or debug the main thread
> to give the connection trial thread enough time to find the Master URL then
> the test works
> *_Log in case of failure:_*
> {code}
> 2016-03-11 10:46:31 DEBUG FailoverProvider:160 - Initiating initial
> connection attempt task
> 2016-03-11 10:46:33 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:10352?amqp.vhost=weather in-progress
> 2016-03-11 10:46:34 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 10:46:34 DEBUG FailoverProvider:761 - Failover: the provider
> reports failure: Received error from remote peer without description
> [condition = amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:519 - handling Provider failure:
> Received error from remote peer without description [condition =
> amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:5672?amqp.vhost=weather in-progress
> 2016-03-11 10:46:31 DEBUG FailoverProvider:160 - Initiating initial
> connection attempt task
> 2016-03-11 10:46:33 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:10352?amqp.vhost=weather in-progress
> 2016-03-11 10:46:34 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 10:46:34 DEBUG FailoverProvider:761 - Failover: the provider
> reports failure: Received error from remote peer without description
> [condition = amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:519 - handling Provider failure:
> Received error from remote peer without description [condition =
> amqp:not-found]
> 2016-03-11 10:46:34 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:5672?amqp.vhost=weather in-progress
> {code}
> *_Logs in case we debug the main thread to allow the connection thread to
> finish:_*
> {code}
> 2016-03-11 11:03:37 DEBUG FailoverProvider:160 - Initiating initial
> connection attempt task
> 2016-03-11 11:04:05 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:10352?amqp.vhost=weather in-progress
> 2016-03-11 11:04:18 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 11:04:18 DEBUG FailoverProvider:985 - Request received error:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:519 - handling Provider failure:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:985 - Request received error:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:761 - Failover: the provider
> reports failure: Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:519 - handling Provider failure:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:18 DEBUG FailoverProvider:519 - handling Provider failure:
> Cannot send to a non-connected transport.
> 2016-03-11 11:04:40 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
> amqp://localhost:5672?amqp.vhost=weather in-progress
> 2016-03-11 11:04:41 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsConnectionInfo {} (1)
> 2016-03-11 11:04:42 INFO JmsConnection:1114 - Connection
> ID::af28891b-adbe-47f1-9da2-ad03f124a215:1 connected to remote Broker:
> amqp://localhost:5672
> 2016-03-11 11:04:42 DEBUG FailoverProvider:963 - Executing Failover Task:
> create -> JmsSessionInfo {} (2)
> {code}
> *_Test code:_*
> {code:java}
> @Test
> public void testScalabilityReversedOrder() throws JMSException {
> String brokerUrl =
>
[jira] [Created] (QPIDJMS-154) Failover mechanism does not handle connection URLs in a predictable way
Adel Boutros created QPIDJMS-154:
Summary: Failover mechanism does not handle connection URLs in a
predictable way
Key: QPIDJMS-154
URL: https://issues.apache.org/jira/browse/QPIDJMS-154
Project: Qpid JMS
Issue Type: Bug
Components: qpid-jms-client
Affects Versions: 0.8.0
Reporter: Adel Boutros
As discussed in this
[link|http://qpid.2158936.n2.nabble.com/Unhandled-exception-when-using-High-Availabilty-in-Qpid-Java-Broker-6-0-0-td7639896.html],
if the links provided in the failover URL are ordered in a way to have the
Replicate first and then the Master. Then the connection will fail and an error
will be thrown client-side.
This is because the multi-threading behavior in the FailoverProvider is not
correct. The main thread will not wait for the connection trial thread to try
and find the active Master node. If we add a Sleep or debug the main thread to
give the connection trial thread enough time to find the Master URL then the
test works
*_Log in case of failure:_*
{code}
2016-03-11 10:46:31 DEBUG FailoverProvider:160 - Initiating initial connection
attempt task
2016-03-11 10:46:33 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
amqp://localhost:10352?amqp.vhost=weather in-progress
2016-03-11 10:46:34 DEBUG FailoverProvider:963 - Executing Failover Task:
create -> JmsConnectionInfo {} (1)
2016-03-11 10:46:34 DEBUG FailoverProvider:761 - Failover: the provider reports
failure: Received error from remote peer without description [condition =
amqp:not-found]
2016-03-11 10:46:34 DEBUG FailoverProvider:519 - handling Provider failure:
Received error from remote peer without description [condition = amqp:not-found]
2016-03-11 10:46:34 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
amqp://localhost:5672?amqp.vhost=weather in-progress
2016-03-11 10:46:31 DEBUG FailoverProvider:160 - Initiating initial connection
attempt task
2016-03-11 10:46:33 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
amqp://localhost:10352?amqp.vhost=weather in-progress
2016-03-11 10:46:34 DEBUG FailoverProvider:963 - Executing Failover Task:
create -> JmsConnectionInfo {} (1)
2016-03-11 10:46:34 DEBUG FailoverProvider:761 - Failover: the provider reports
failure: Received error from remote peer without description [condition =
amqp:not-found]
2016-03-11 10:46:34 DEBUG FailoverProvider:519 - handling Provider failure:
Received error from remote peer without description [condition = amqp:not-found]
2016-03-11 10:46:34 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
amqp://localhost:5672?amqp.vhost=weather in-progress
{code}
*_Logs in case we debug the main thread to allow the connection thread to
finish:_*
{code}
2016-03-11 11:03:37 DEBUG FailoverProvider:160 - Initiating initial connection
attempt task
2016-03-11 11:04:05 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
amqp://localhost:10352?amqp.vhost=weather in-progress
2016-03-11 11:04:18 DEBUG FailoverProvider:963 - Executing Failover Task:
create -> JmsConnectionInfo {} (1)
2016-03-11 11:04:18 DEBUG FailoverProvider:985 - Request received error: Cannot
send to a non-connected transport.
2016-03-11 11:04:18 DEBUG FailoverProvider:519 - handling Provider failure:
Cannot send to a non-connected transport.
2016-03-11 11:04:18 DEBUG FailoverProvider:985 - Request received error: Cannot
send to a non-connected transport.
2016-03-11 11:04:18 DEBUG FailoverProvider:761 - Failover: the provider reports
failure: Cannot send to a non-connected transport.
2016-03-11 11:04:18 DEBUG FailoverProvider:519 - handling Provider failure:
Cannot send to a non-connected transport.
2016-03-11 11:04:18 DEBUG FailoverProvider:519 - handling Provider failure:
Cannot send to a non-connected transport.
2016-03-11 11:04:40 DEBUG FailoverProvider:653 - Connection attempt:[1] to:
amqp://localhost:5672?amqp.vhost=weather in-progress
2016-03-11 11:04:41 DEBUG FailoverProvider:963 - Executing Failover Task:
create -> JmsConnectionInfo {} (1)
2016-03-11 11:04:42 INFO JmsConnection:1114 - Connection
ID::af28891b-adbe-47f1-9da2-ad03f124a215:1 connected to remote Broker:
amqp://localhost:5672
2016-03-11 11:04:42 DEBUG FailoverProvider:963 - Executing Failover Task:
create -> JmsSessionInfo {} (2)
{code}
*_Test code:_*
{code:java}
@Test
public void testScalabilityReversedOrder() throws JMSException {
String brokerUrl =
"failover:(amqp://localhost:10352,amqp://localhost:5672)?failover.nested.amqp.vhost=weather";
ConnectionFactory connectionFactory = new JmsConnectionFactory(brokerUrl);
Connection connection = connectionFactory.createConnection();
Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail:
[jira] [Commented] (QPID-6958) [Java Broker] A confusing exception is reported for Virtual Host type declared in the configuration store but with implementation not available in the classpath
[
https://issues.apache.org/jira/browse/QPID-6958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15190760#comment-15190760
]
ASF subversion and git services commented on QPID-6958:
---
Commit 1734520 from [~godfrer] in branch 'java/trunk'
[ https://svn.apache.org/r1734520 ]
QPID-6958 : Change to take acount of the fact that COTR fails to initialise if
a ConditionallyAvailable implementation is not actually available
> [Java Broker] A confusing exception is reported for Virtual Host type
> declared in the configuration store but with implementation not available in
> the classpath
>
>
> Key: QPID-6958
> URL: https://issues.apache.org/jira/browse/QPID-6958
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker
>Affects Versions: qpid-java-6.0
>Reporter: Alex Rudyy
>Assignee: Rob Godfrey
>Priority: Minor
>
> When Virtual Host of certain type is declared in the configuration store but
> its implementation is not present in the classpath Broker evaluates Virtual
> Host type as Provided and throws Exception as below:
> {noformat}
> 2015-12-21 10:05:57,422 ERROR [Broker-Config]
> (o.a.q.s.m.AbstractConfiguredObject) - Failed to open object with name
> 'default'. Object will be put into ERROR state.
> org.apache.qpid.server.configuration.IllegalConfigurationException: Provided
> type is BDB but calculated type is ProvidedStore
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.(AbstractConfiguredObject.java:263)
> [qpid-broker-core-6.0.0.jar:6.0.0]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.(AbstractConfiguredObject.java:204)
> [qpid-broker-core-6.0.0.jar:6.0.0]
> at
> org.apache.qpid.server.model.AbstractConfiguredObject.(AbstractConfiguredObject.java:196)
> [qpid-broker-core-6.0.0.jar:6.0.0]
> at
> org.apache.qpid.server.virtualhost.AbstractVirtualHost.(AbstractVirtualHost.java:210)
> ~[qpid-broker-core-6.0.0.jar:6.0.0]
> at
> org.apache.qpid.server.virtualhost.ProvidedStoreVirtualHostImpl.(ProvidedStoreVirtualHostImpl.java:50)
> ~[qpid-broker-core-6.0.0.jar:6.0.0]
> at
> org.apache.qpid.server.virtualhost.ProvidedStoreVirtualHostImplFactory.createInstance(ProvidedStoreVirtualHostImplFactory.java:39)
> ~[qpid-broker-core-6.0.0.jar:6.0.0]
> at
> org.apache.qpid.server.virtualhost.ProvidedStoreVirtualHostImplFactory.createInstance(ProvidedStoreVirtualHostImplFactory.java:28)
> ~[qpid-broker-core-6.0.0.jar:6.0.0]
> at
> org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory$GenericUnresolvedConfiguredObject.resolve(AbstractConfiguredObjectTypeFactory.java:145)
> ~[qpid-broker-core-6.0.0.jar:6.0.0]
> at
> org.apache.qpid.server.model.AbstractConfiguredObjectTypeFactory$GenericUnresolvedConfiguredObject.resolve(AbstractConfiguredObjectTypeFactory.java:125)
> ~[qpid-broker-core-6.0.0.jar:6.0.0]
> at
> org.apache.qpid.server.store.GenericRecoverer.resolveObjects(GenericRecoverer.java:186)
> ~[qpid-broker-core-6.0.0.jar:6.0.0]
> at
> org.apache.qpid.server.store.GenericRecoverer.performRecover(GenericRecoverer.java:91)
> ~[qpid-broker-core-6.0.0.jar:6.0.0]
> at
> org.apache.qpid.server.store.GenericRecoverer.access$000(GenericRecoverer.java:41)
> ~[qpid-broker-core-6.0.0.jar:6.0.0]
> at
> org.apache.qpid.server.store.GenericRecoverer$1.execute(GenericRecoverer.java:59)
> ~[qpid-broker-core-6.0.0.jar:6.0.0]
> at
> org.apache.qpid.server.store.GenericRecoverer$1.execute(GenericRecoverer.java:55)
> ~[qpid-broker-core-6.0.0.jar:6.0.0]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl$TaskLoggingWrapper.execute(TaskExecutorImpl.java:270)
> [qpid-broker-core-6.0.0.jar:6.0.0]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.submitWrappedTask(TaskExecutorImpl.java:154)
> [qpid-broker-core-6.0.0.jar:6.0.0]
> at
> org.apache.qpid.server.configuration.updater.TaskExecutorImpl.run(TaskExecutorImpl.java:182)
> [qpid-broker-core-6.0.0.jar:6.0.0]
> at
> org.apache.qpid.server.store.GenericRecoverer.recover(GenericRecoverer.java:54)
> ~[qpid-broker-core-6.0.0.jar:6.0.0]
> at
> org.apache.qpid.server.store.VirtualHostStoreUpgraderAndRecoverer.perform(VirtualHostStoreUpgraderAndRecoverer.java:551)
> ~[qpid-broker-core-6.0.0.jar:6.0.0]
> at
> org.apache.qpid.server.virtualhostnode.AbstractStandardVirtualHostNode.activate(AbstractStandardVirtualHostNode.java:104)
> ~[qpid-broker-core-6.0.0.jar:6.0.0]
> at
>
