[jira] [Created] (QPID-4289) [Java Client 0-8/0-9.x] Failover functionality does not restore the connection
Alex Rudyy created QPID-4289: Summary: [Java Client 0-8/0-9.x] Failover functionality does not restore the connection Key: QPID-4289 URL: https://issues.apache.org/jira/browse/QPID-4289 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.18, 0.16, 0.19 Reporter: Alex Rudyy Assignee: Alex Rudyy Fix For: 0.19 Failover functionality on 0-8/0-9.x java client does not restore the connection in the following scenarios: * when on initial establishing of the connectivity the connection object is marked as closed after to not being able to connect to the first brokers from the broker list but managed to connect to the one of the following brokers from the broker list * there are racing condition between waking up the connection state waiters and closing the phisical connection. As result, waiters are notified, new connection is created and closed afterwards. * on killing the broker when no IOException is thrown from socket input/output streams but -1 is returned by read operation instead, the failover starts but IoSender thread is left running. As result, on multiple reconnection attempts the thread resources can be exhausted and that can potentially result in OOME. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4289) [Java Client 0-8/0-9.x] Failover functionality does not restore the connection
[ https://issues.apache.org/jira/browse/QPID-4289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-4289: - Status: Ready To Review (was: In Progress) [Java Client 0-8/0-9.x] Failover functionality does not restore the connection -- Key: QPID-4289 URL: https://issues.apache.org/jira/browse/QPID-4289 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.16, 0.18, 0.19 Reporter: Alex Rudyy Assignee: Alex Rudyy Fix For: 0.19 Attachments: 0001-QPID-4289-Fix-failover-issues.patch Failover functionality on 0-8/0-9.x java client does not restore the connection in the following scenarios: * when on initial establishing of the connectivity the connection object is marked as closed after to not being able to connect to the first brokers from the broker list but managed to connect to the one of the following brokers from the broker list * there are racing condition between waking up the connection state waiters and closing the phisical connection. As result, waiters are notified, new connection is created and closed afterwards. * on killing the broker when no IOException is thrown from socket input/output streams but -1 is returned by read operation instead, the failover starts but IoSender thread is left running. As result, on multiple reconnection attempts the thread resources can be exhausted and that can potentially result in OOME. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4289) [Java Client 0-8/0-9.x] Failover functionality does not restore the connection
[ https://issues.apache.org/jira/browse/QPID-4289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-4289: - Attachment: 0001-QPID-4289-Fix-failover-issues.patch Attached a patch resolving the failover faunctionality issues on 0-9.x/0-8 path [Java Client 0-8/0-9.x] Failover functionality does not restore the connection -- Key: QPID-4289 URL: https://issues.apache.org/jira/browse/QPID-4289 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.16, 0.18, 0.19 Reporter: Alex Rudyy Assignee: Alex Rudyy Fix For: 0.19 Attachments: 0001-QPID-4289-Fix-failover-issues.patch Failover functionality on 0-8/0-9.x java client does not restore the connection in the following scenarios: * when on initial establishing of the connectivity the connection object is marked as closed after to not being able to connect to the first brokers from the broker list but managed to connect to the one of the following brokers from the broker list * there are racing condition between waking up the connection state waiters and closing the phisical connection. As result, waiters are notified, new connection is created and closed afterwards. * on killing the broker when no IOException is thrown from socket input/output streams but -1 is returned by read operation instead, the failover starts but IoSender thread is left running. As result, on multiple reconnection attempts the thread resources can be exhausted and that can potentially result in OOME. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-4289) [Java Client 0-8/0-9.x] Failover functionality does not restore the connection
[ https://issues.apache.org/jira/browse/QPID-4289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy reassigned QPID-4289: Assignee: Robbie Gemmell (was: Alex Rudyy) Robbie, Could you please review and commit the patch attached? [Java Client 0-8/0-9.x] Failover functionality does not restore the connection -- Key: QPID-4289 URL: https://issues.apache.org/jira/browse/QPID-4289 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.16, 0.18, 0.19 Reporter: Alex Rudyy Assignee: Robbie Gemmell Fix For: 0.19 Attachments: 0001-QPID-4289-Fix-failover-issues.patch Failover functionality on 0-8/0-9.x java client does not restore the connection in the following scenarios: * when on initial establishing of the connectivity the connection object is marked as closed after to not being able to connect to the first brokers from the broker list but managed to connect to the one of the following brokers from the broker list * there are racing condition between waking up the connection state waiters and closing the phisical connection. As result, waiters are notified, new connection is created and closed afterwards. * on killing the broker when no IOException is thrown from socket input/output streams but -1 is returned by read operation instead, the failover starts but IoSender thread is left running. As result, on multiple reconnection attempts the thread resources can be exhausted and that can potentially result in OOME. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4289) [Java Client 0-8/0-9.x] Failover functionality does not restore the connection
[ https://issues.apache.org/jira/browse/QPID-4289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-4289: - Description: Failover functionality on 0-8/0-9.x java client does not restore the connection in the following scenarios: * when on initial establishing of the connectivity the connection object is marked as closed after not being able to connect to the first brokers from the broker list but at the end it manages to connect to the one of the following brokers from the broker list * there is a racing condition between waking up the connection state waiter and closing the phisical connection on receiving ConnectionClose command from the broker. As result, waiters are notified, new connection is created and closed afterwards. * on killing the broker when no IOException is thrown from socket input/output streams but instead -1 is returned by read operation, the failover starts but IoSender thread is left running. As result, on multiple reconnection attempts the thread resources can be exhausted and that can potentially result in OOME. was: Failover functionality on 0-8/0-9.x java client does not restore the connection in the following scenarios: * when on initial establishing of the connectivity the connection object is marked as closed after to not being able to connect to the first brokers from the broker list but managed to connect to the one of the following brokers from the broker list * there are racing condition between waking up the connection state waiters and closing the phisical connection. As result, waiters are notified, new connection is created and closed afterwards. * on killing the broker when no IOException is thrown from socket input/output streams but -1 is returned by read operation instead, the failover starts but IoSender thread is left running. As result, on multiple reconnection attempts the thread resources can be exhausted and that can potentially result in OOME. [Java Client 0-8/0-9.x] Failover functionality does not restore the connection -- Key: QPID-4289 URL: https://issues.apache.org/jira/browse/QPID-4289 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.16, 0.18, 0.19 Reporter: Alex Rudyy Assignee: Robbie Gemmell Fix For: 0.19 Attachments: 0001-QPID-4289-Fix-failover-issues.patch Failover functionality on 0-8/0-9.x java client does not restore the connection in the following scenarios: * when on initial establishing of the connectivity the connection object is marked as closed after not being able to connect to the first brokers from the broker list but at the end it manages to connect to the one of the following brokers from the broker list * there is a racing condition between waking up the connection state waiter and closing the phisical connection on receiving ConnectionClose command from the broker. As result, waiters are notified, new connection is created and closed afterwards. * on killing the broker when no IOException is thrown from socket input/output streams but instead -1 is returned by read operation, the failover starts but IoSender thread is left running. As result, on multiple reconnection attempts the thread resources can be exhausted and that can potentially result in OOME. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-4261) [Java client] add options to Binding URLs to allow specifying exchange properties when using custom exchanges
[ https://issues.apache.org/jira/browse/QPID-4261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey reassigned QPID-4261: - Assignee: Rob Godfrey (was: Robbie Gemmell) [Java client] add options to Binding URLs to allow specifying exchange properties when using custom exchanges - Key: QPID-4261 URL: https://issues.apache.org/jira/browse/QPID-4261 Project: Qpid Issue Type: Improvement Components: Java Client Reporter: Robbie Gemmell Assignee: Rob Godfrey Fix For: 0.19 Add options to Binding URLs to allow specifying exchange properties when using custom exchanges. When using AMQP 0-8/0-9/0-9-1 it is necessary to use the BindingURL destination format. Due to the clients historic silo'd use of the mandatory amq.direct and amq.topic for Queues and Topics respectively, the BindingURL syntax doesn't provide any means to specify the properties of the exchanges for which the client implicitly sends exchange-declare commands during producer/consumer creation. This severely limits the clients ability to use custom exchanges and interact with systems which already do. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-4261) [Java client] add options to Binding URLs to allow specifying exchange properties when using custom exchanges
[ https://issues.apache.org/jira/browse/QPID-4261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey resolved QPID-4261. --- Resolution: Fixed Change looks good to me - note that it also removes some dead methods from the MessageProducer interface and it's implementations. [Java client] add options to Binding URLs to allow specifying exchange properties when using custom exchanges - Key: QPID-4261 URL: https://issues.apache.org/jira/browse/QPID-4261 Project: Qpid Issue Type: Improvement Components: Java Client Reporter: Robbie Gemmell Assignee: Rob Godfrey Fix For: 0.19 Add options to Binding URLs to allow specifying exchange properties when using custom exchanges. When using AMQP 0-8/0-9/0-9-1 it is necessary to use the BindingURL destination format. Due to the clients historic silo'd use of the mandatory amq.direct and amq.topic for Queues and Topics respectively, the BindingURL syntax doesn't provide any means to specify the properties of the exchanges for which the client implicitly sends exchange-declare commands during producer/consumer creation. This severely limits the clients ability to use custom exchanges and interact with systems which already do. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
RE: FW: problems starting the version 18 broker and its Crash
Hi,
Thanks for the information. I started doing some investigation on the new
release mainly because I could not see what we were ( if possible) doing wrong
with the release. The broker would start executing and immediately one was
getting an assert as shown below in the output I generated with running it
under GDB. It asserts because it fails the test in file types.cpp in qpid/ha
line 38 ( assert(value count). I noticed that this is happening as a result
of the call from the HaBroker::initialize() function line 90 in the
HaBroker.cpp file where a QPID_LOG is being invoked.
I believe the root of the problem is the BrokerInfo class constructor is not
initializing the private class data called BrokerStatus status which is
defined in file BrokerInfo.h . BrokerStatus is defined in types.h as an enum as
follows
enum BrokerStatus {
JOINING,/// New broker, looking for primary
CATCHUP,/// Backup: Connected to primary, catching up
on state.
READY, /// Backup: Caught up, ready to take over.
RECOVERING, /// Primary: waiting for backups to connect
sync
ACTIVE, /// Primary: actively serving clients.
STANDALONE /// Not part of a cluster.
};
It seems like the assert happens on the second call to EnumBase::str() in
types.cpp. The count was 6 and the value was some large uninitialized value.
I initialized the status variable in the constructor to STANDALONE and the
broker came up and worked fine.
*I assume we are going to need a patch or an update for the broker to be
used.
NOTE:: If I start the broker with the --log-enable warning or for that matter
others like notice, the broker comes up and works fine. But, if the broker is
started with no log-enable parameters, IT CRASHES. This seems pretty strange as
I thought you guys would have seen this.
I am running the broker on a CentOs 6.2 system. We have been using version 16
to date. The images are created a new and loaded on a VM, so the VM has no
remnants of the version 16, so it is clean version 18 load and use.
If I wish to continue using this release, can someone tell me what the correct
process for getting a patch is? Alternatively, what is the patch I should
apply, meaning can I add a initialize of the status parameter and what is the
CORRECT enum value to set it to?
Nitin
Ps let me know if there any other information you need
Thanks
(gdb) where
#0 0x758b58a5 in raise () from /lib64/libc.so.6
#1 0x758b7085 in abort () from /lib64/libc.so.6
#2 0x758aea1e in __assert_fail_base () from /lib64/libc.so.6
#3 0x758aeae0 in __assert_fail () from /lib64/libc.so.6
#4 0x750464fb in qpid::ha::EnumBase::str (this=value optimized out)
at qpid/ha/types.cpp:38
#5 0x75046533 in qpid::ha::operator (o=..., e=...) at
qpid/ha/types.cpp:64
#6 0x75013a5a in qpid::ha::operator (o=value optimized out,
b=value optimized out)
at qpid/ha/BrokerInfo.cpp:99
#7 0x75029fb4 in operator qpid::ha::BrokerInfo (this=0x6507b0) at
../include/qpid/Msg.h:63
#8 qpid::ha::HaBroker::initialize (this=0x6507b0) at qpid/ha/HaBroker.cpp:90
#9 0x775d4861 in operator() (f=value optimized out)
at /usr/include/boost/bind/mem_fn_template.hpp:162
#10 operator()boost::_mfi::mf1void, qpid::Plugin, qpid::Plugin::Target,
boost::_bi::list1qpid::Plugin* const (f=value optimized out) at
/usr/include/boost/bind/bind.hpp:306
#11 operator()qpid::Plugin* (f=value optimized out) at
/usr/include/boost/bind/bind_template.hpp:47
#12 for_each__gnu_cxx::__normal_iteratorqpid::Plugin* const*,
std::vectorqpid::Plugin*, std::allocatorqpid::Plugin* ,
boost::_bi::bind_tvoid, boost::_mfi::mf1void, qpid::Plugin,
qpid::Plugin::Target, boost::_bi::list2boost::arg1,
boost::reference_wrapperqpid::Plugin::Target(f=value optimized out)
at
/usr/lib/gcc/x86_64-redhat-linux/4.4.6/../../../../include/c++/4.4.6/bits/stl_algo.h:4200
#13 qpid::(anonymous namespace)::each_pluginboost::_bi::bind_tvoid,
boost::_mfi::mf1void, qpid::Plugin, qpid::Plugin::Target,
boost::_bi::list2boost::arg1, boost::reference_wrapperqpid::Plugin::Target
(
f=value optimized out) at qpid/Plugin.cpp:73
#14 0x775d48a2 in qpid::Plugin::initializeAll (t=value optimized out)
at qpid/Plugin.cpp:91
-Original Message-
From: Gordon Sim [mailto:g...@redhat.com]
Sent: Wednesday, September 05, 2012 12:29 PM
To: dev@qpid.apache.org
Subject: Re: FW: problems starting the version 18 broker
Can you run it with full tracing on? i.e. --log-enable trace+
What platform are you running on? Did make check pass when building? Did you
build and install from source on that machine; did you uninstall the
0.16 release first or are they both installed in different locations?
The second error appears to be coming from the HA module, possibly related to
the options. Could you be
[jira] [Created] (QPID-4290) ReplicatingSubscription counts as a consumer and doesn't allow auto-delete queues to be deleted
Andy Goldstein created QPID-4290: Summary: ReplicatingSubscription counts as a consumer and doesn't allow auto-delete queues to be deleted Key: QPID-4290 URL: https://issues.apache.org/jira/browse/QPID-4290 Project: Qpid Issue Type: Bug Components: C++ Clustering Reporter: Andy Goldstein Assignee: Alan Conway Attachments: qpid-4290.patch If you create an auto-delete queue, the ReplicatingSubscription that backs it up is included in the Queue's consumerCount, so auto-deletion never occurs because consumerCount is always 0. ReplicatingSubscriptions should not be counted as consumers so auto deletion can succeed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4290) ReplicatingSubscription counts as a consumer and doesn't allow auto-delete queues to be deleted
[ https://issues.apache.org/jira/browse/QPID-4290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Goldstein updated QPID-4290: - Attachment: qpid-4290.patch Diff against 0.18 ReplicatingSubscription counts as a consumer and doesn't allow auto-delete queues to be deleted --- Key: QPID-4290 URL: https://issues.apache.org/jira/browse/QPID-4290 Project: Qpid Issue Type: Bug Components: C++ Clustering Reporter: Andy Goldstein Assignee: Alan Conway Attachments: qpid-4290.patch If you create an auto-delete queue, the ReplicatingSubscription that backs it up is included in the Queue's consumerCount, so auto-deletion never occurs because consumerCount is always 0. ReplicatingSubscriptions should not be counted as consumers so auto deletion can succeed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: FW: problems starting the version 18 broker and its Crash
On 09/07/2012 02:43 PM, Nitin Shah wrote:
Hi,
Thanks for the information. I started doing some investigation on the
new release mainly because I could not see what we were ( if
possible) doing wrong with the release. The broker would start
executing and immediately one was getting an assert as shown below in
the output I generated with running it under GDB. It asserts because
it fails the test in file types.cpp in qpid/ha line 38 ( assert(value
count). I noticed that this is happening as a result of the call
from the HaBroker::initialize() function line 90 in the HaBroker.cpp
file where a QPID_LOG is being invoked.
I believe the root of the problem is the BrokerInfo class constructor
is not initializing the private class data called BrokerStatus
status which is defined in file BrokerInfo.h .
Good analysis; thanks!
*I assume we are going to need a patch or an update for the
broker to be used.
NOTE:: If I start the broker with the --log-enable warning or for
that matter others like notice, the broker comes up and works fine.
But, if the broker is started with no log-enable parameters, IT
CRASHES. This seems pretty strange as I thought you guys would have
seen this.
It actually works fine for me for repeated restarts, though if I run
under valgrind the uninitialised value is reported and of course by
inspection of the code you have correctly identified a problem.
I guess we have just been unlucky in not hitting the problem...
I am running the broker on a CentOs 6.2 system. We have been using
version 16 to date. The images are created a new and loaded on a VM,
so the VM has no remnants of the version 16, so it is clean version
18 load and use.
If I wish to continue using this release, can someone tell me what
the correct process for getting a patch is? Alternatively, what is
the patch I should apply, meaning can I add a initialize of the
status parameter and what is the CORRECT enum value to set it to?
The attached patch should take care of the crash. I believe the status
is correctly set later on, just not in time for the logging statement.
Index: cpp/src/qpid/ha/BrokerInfo.cpp
===
--- cpp/src/qpid/ha/BrokerInfo.cpp (revision 1382034)
+++ cpp/src/qpid/ha/BrokerInfo.cpp (working copy)
@@ -44,7 +44,7 @@
using framing::FieldTable;
BrokerInfo::BrokerInfo(const std::string host, uint16_t port_, const types::Uuid id) :
-hostName(host), port(port_), systemId(id)
+hostName(host), port(port_), systemId(id), status(JOINING)
{
updateLogId();
}
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-4291) Renamed the Ruby gemfile to qpid_messaging
Darryl L. Pierce created QPID-4291: -- Summary: Renamed the Ruby gemfile to qpid_messaging Key: QPID-4291 URL: https://issues.apache.org/jira/browse/QPID-4291 Project: Qpid Issue Type: Improvement Components: Ruby Client, Ruby Test Suite Affects Versions: 0.18 Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce Fix For: 0.18 Attachments: 0001-Some-cleanup-on-the-rdoc-generation-and-markups.patch, 0002-Renamed-the-gemfile-to-qpid_messaging.patch, 0003-Added-ruby_gemfile-as-a-build-target.patch Since the name qpid is already claimed on Rubygems.org, we've had to change the name of our gem to qpid_messaging. This patch set includes changes needed in the internals for the Qpid Ruby bindings to use this new naming. Users will need to change: require qpid to: require qpid_messaging to avoid any potential name collisions. Otherwise, no other changes are required to their code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4291) Renamed the Ruby gemfile to qpid_messaging
[ https://issues.apache.org/jira/browse/QPID-4291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce updated QPID-4291: --- Attachment: 0003-Added-ruby_gemfile-as-a-build-target.patch 0002-Renamed-the-gemfile-to-qpid_messaging.patch 0001-Some-cleanup-on-the-rdoc-generation-and-markups.patch Renamed the Ruby gemfile to qpid_messaging Key: QPID-4291 URL: https://issues.apache.org/jira/browse/QPID-4291 Project: Qpid Issue Type: Improvement Components: Ruby Client, Ruby Test Suite Affects Versions: 0.18 Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce Fix For: 0.18 Attachments: 0001-Some-cleanup-on-the-rdoc-generation-and-markups.patch, 0002-Renamed-the-gemfile-to-qpid_messaging.patch, 0003-Added-ruby_gemfile-as-a-build-target.patch Since the name qpid is already claimed on Rubygems.org, we've had to change the name of our gem to qpid_messaging. This patch set includes changes needed in the internals for the Qpid Ruby bindings to use this new naming. Users will need to change: require qpid to: require qpid_messaging to avoid any potential name collisions. Otherwise, no other changes are required to their code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4291) Renamed the Ruby gemfile to qpid_messaging
[ https://issues.apache.org/jira/browse/QPID-4291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce updated QPID-4291: --- Attachment: (was: 0003-Added-ruby_gemfile-as-a-build-target.patch) Renamed the Ruby gemfile to qpid_messaging Key: QPID-4291 URL: https://issues.apache.org/jira/browse/QPID-4291 Project: Qpid Issue Type: Improvement Components: Ruby Client, Ruby Test Suite Affects Versions: 0.18 Reporter: Darryl L. Pierce Assignee: Darryl L. Pierce Fix For: 0.18 Attachments: 0001-Some-cleanup-on-the-rdoc-generation-and-markups.patch, 0002-Renamed-the-gemfile-to-qpid_messaging.patch Since the name qpid is already claimed on Rubygems.org, we've had to change the name of our gem to qpid_messaging. This patch set includes changes needed in the internals for the Qpid Ruby bindings to use this new naming. Users will need to change: require qpid to: require qpid_messaging to avoid any potential name collisions. Otherwise, no other changes are required to their code. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-4292) add ACL rule to authorise access to the web management UI
Keith Wall created QPID-4292: Summary: add ACL rule to authorise access to the web management UI Key: QPID-4292 URL: https://issues.apache.org/jira/browse/QPID-4292 Project: Qpid Issue Type: Bug Components: Java Broker Reporter: Keith Wall Assignee: Keith Wall Fix For: 0.19 Extend the ACLs rules to allow users to be denied access to the two management UIs (JMX and Web). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4275) Java Performance Tests - race condition between closing test consumer and test connection
[ https://issues.apache.org/jira/browse/QPID-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-4275: - Status: Ready To Review (was: In Progress) Java Performance Tests - race condition between closing test consumer and test connection - Key: QPID-4275 URL: https://issues.apache.org/jira/browse/QPID-4275 Project: Qpid Issue Type: Bug Components: Java Performance Tests Reporter: Philip Harvey Assignee: Keith Wall Priority: Minor Fix For: 0.19 Attachments: QPID-4275-now-releasing-participant-resources-befor.patch In the new performance test framework, the ParticipantExecutor does these two things at the end when the participant has completed: # Send the results # Tell the participant to release its resources. When this is done in the order listed, the client may receive a TEAR_DOWN_TEST command, which causes the connection to be closed, while it is inside releseResources(). This provokes the client deadlock reported in QPID-4276. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-4275) Java Performance Tests - race condition between closing test consumer and test connection
[ https://issues.apache.org/jira/browse/QPID-4275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall resolved QPID-4275. -- Resolution: Fixed Reviewed, no comments. Patch applied Java Performance Tests - race condition between closing test consumer and test connection - Key: QPID-4275 URL: https://issues.apache.org/jira/browse/QPID-4275 Project: Qpid Issue Type: Bug Components: Java Performance Tests Reporter: Philip Harvey Assignee: Keith Wall Priority: Minor Fix For: 0.19 Attachments: QPID-4275-now-releasing-participant-resources-befor.patch In the new performance test framework, the ParticipantExecutor does these two things at the end when the participant has completed: # Send the results # Tell the participant to release its resources. When this is done in the order listed, the client may receive a TEAR_DOWN_TEST command, which causes the connection to be closed, while it is inside releseResources(). This provokes the client deadlock reported in QPID-4276. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4289) [Java Client 0-8/0-9.x] Failover functionality does not restore the connection
[ https://issues.apache.org/jira/browse/QPID-4289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-4289: - Attachment: (was: 0001-QPID-4289-Fix-failover-issues.patch) [Java Client 0-8/0-9.x] Failover functionality does not restore the connection -- Key: QPID-4289 URL: https://issues.apache.org/jira/browse/QPID-4289 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.16, 0.18, 0.19 Reporter: Alex Rudyy Assignee: Robbie Gemmell Fix For: 0.19 Attachments: 0001-QPID-4289-Fix-failover-issues.patch Failover functionality on 0-8/0-9.x java client does not restore the connection in the following scenarios: * when on initial establishing of the connectivity the connection object is marked as closed after not being able to connect to the first brokers from the broker list but at the end it manages to connect to the one of the following brokers from the broker list * there is a racing condition between waking up the connection state waiter and closing the phisical connection on receiving ConnectionClose command from the broker. As result, waiters are notified, new connection is created and closed afterwards. * on killing the broker when no IOException is thrown from socket input/output streams but instead -1 is returned by read operation, the failover starts but IoSender thread is left running. As result, on multiple reconnection attempts the thread resources can be exhausted and that can potentially result in OOME. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4289) [Java Client 0-8/0-9.x] Failover functionality does not restore the connection
[ https://issues.apache.org/jira/browse/QPID-4289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-4289: - Attachment: 0001-QPID-4289-Fix-failover-issues.patch [Java Client 0-8/0-9.x] Failover functionality does not restore the connection -- Key: QPID-4289 URL: https://issues.apache.org/jira/browse/QPID-4289 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.16, 0.18, 0.19 Reporter: Alex Rudyy Assignee: Robbie Gemmell Fix For: 0.19 Attachments: 0001-QPID-4289-Fix-failover-issues.patch Failover functionality on 0-8/0-9.x java client does not restore the connection in the following scenarios: * when on initial establishing of the connectivity the connection object is marked as closed after not being able to connect to the first brokers from the broker list but at the end it manages to connect to the one of the following brokers from the broker list * there is a racing condition between waking up the connection state waiter and closing the phisical connection on receiving ConnectionClose command from the broker. As result, waiters are notified, new connection is created and closed afterwards. * on killing the broker when no IOException is thrown from socket input/output streams but instead -1 is returned by read operation, the failover starts but IoSender thread is left running. As result, on multiple reconnection attempts the thread resources can be exhausted and that can potentially result in OOME. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Review Request: Add the properties list from the remote client to the client events generated by the broker.
---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/6955/
---
Review request for qpid, Ted Ross and Pavel Moravec.
Description
---
Here's a modified version of Pavel's original patch that includes the full
properties list as provided by the client when the connection is created.
Using qpid-printevents, you can see the property map in the event:
Fetched Message(properties={u'qmf.agent':
u'apache.org:qpidd:a2ff61bc-19b2-4078-8a7e-9c007151c79c',
'x-amqp-0-10.routing-key':
u'agent.ind.event.org_apache_qpid_broker.clientConnect.info.apache_org.qpidd.a2ff61bc-19b2-4078-8a7e-9c007151c79c',
'x-amqp-0-10.app-id': 'qmf2', u'qmf.content': u'_event', u'qmf.opcode':
u'_data_indication', u'method': u'indication'}, content=[{u'_schema_id':
{u'_package_name': 'org.apache.qpid.broker', u'_class_name': 'clientConnect',
u'_type': '_event', u'_hash': UUID('476930ed-01dd-9629-7f84-f42b4b0bc410')},
u'_timestamp': 1347032560197086881, u'_values': {u'user': 'anonymous',
u'properties': {u'qpid.session_flow': 1, u'qpid.client_ppid': 26139,
u'qpid.client_pid': 26876, u'qpid.client_process': u'spout'}, u'rhost':
'127.0.0.1:5672-127.0.0.1:43276'}, u'_severity': 6}])
Fri Sep 7 15:42:40 2012 org.apache.qpid.broker:clientConnect user=anonymous
properties={u'qpid.session_flow': 1, u'qpid.client_ppid': 26139,
u'qpid.client_pid': 26876, u'qpid.client_process': u'spout'}
rhost=127.0.0.1:5672-127.0.0.1:43276
Fetched Message(properties={u'qmf.agent':
u'apache.org:qpidd:a2ff61bc-19b2-4078-8a7e-9c007151c79c',
'x-amqp-0-10.routing-key':
u'agent.ind.event.org_apache_qpid_broker.clientDisconnect.info.apache_org.qpidd.a2ff61bc-19b2-4078-8a7e-9c007151c79c',
'x-amqp-0-10.app-id': 'qmf2', u'qmf.content': u'_event', u'qmf.opcode':
u'_data_indication', u'method': u'indication'}, content=[{u'_schema_id':
{u'_package_name': 'org.apache.qpid.broker', u'_class_name':
'clientDisconnect', u'_type': '_event', u'_hash':
UUID('e7603e45-c89b-ea2f-3335-48c0980369db')}, u'_timestamp':
1347032560239676462, u'_values': {u'user': 'anonymous', u'properties':
{u'qpid.session_flow': 1, u'qpid.client_ppid': 26139, u'qpid.client_pid':
26876, u'qpid.client_process': u'spout'}, u'rhost':
'127.0.0.1:5672-127.0.0.1:43276'}, u'_severity': 6}])
Fri Sep 7 15:42:40 2012 org.apache.qpid.broker:clientDisconnect user=anonymous
properties={u'qpid.session_flow': 1, u'qpid.client_ppid': 26139,
u'qpid.client_pid': 26876, u'qpid.client_process': u'spout'}
rhost=127.0.0.1:5672-127.0.0.1:43276
This addresses bug qpid-4174.
https://issues.apache.org/jira/browse/qpid-4174
Diffs
-
/trunk/qpid/cpp/src/qpid/broker/Connection.cpp 1382075
/trunk/qpid/cpp/src/qpid/broker/ConnectionHandler.cpp 1382075
/trunk/qpid/specs/management-schema.xml 1382075
Diff: https://reviews.apache.org/r/6955/diff/
Testing
---
Just checked the new event contents with qpid-printevents
Thanks,
Kenneth Giusti
[jira] [Updated] (QPID-4292) add ACL rule to authorise access to the web management UI
[ https://issues.apache.org/jira/browse/QPID-4292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-4292: - Attachment: 0001-QPID-4292.patch Tests passing. Uploaded for safe keeping. Tests with external SSO provider pending add ACL rule to authorise access to the web management UI - Key: QPID-4292 URL: https://issues.apache.org/jira/browse/QPID-4292 Project: Qpid Issue Type: Bug Components: Java Broker Reporter: Keith Wall Assignee: Keith Wall Fix For: 0.19 Attachments: 0001-QPID-4292.patch Extend the ACLs rules to allow users to be denied access to the two management UIs (JMX and Web). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4289) [Java Client 0-8/0-9.x] Failover functionality does not restore the connection
[ https://issues.apache.org/jira/browse/QPID-4289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-4289: - Attachment: (was: 0001-QPID-4289-Fix-failover-issues.patch) [Java Client 0-8/0-9.x] Failover functionality does not restore the connection -- Key: QPID-4289 URL: https://issues.apache.org/jira/browse/QPID-4289 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.16, 0.18, 0.19 Reporter: Alex Rudyy Assignee: Robbie Gemmell Fix For: 0.19 Attachments: 0001-QPID-4289-Fix-failover-issues.patch Failover functionality on 0-8/0-9.x java client does not restore the connection in the following scenarios: * when on initial establishing of the connectivity the connection object is marked as closed after not being able to connect to the first brokers from the broker list but at the end it manages to connect to the one of the following brokers from the broker list * there is a racing condition between waking up the connection state waiter and closing the phisical connection on receiving ConnectionClose command from the broker. As result, waiters are notified, new connection is created and closed afterwards. * on killing the broker when no IOException is thrown from socket input/output streams but instead -1 is returned by read operation, the failover starts but IoSender thread is left running. As result, on multiple reconnection attempts the thread resources can be exhausted and that can potentially result in OOME. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-4289) [Java Client 0-8/0-9.x] Failover functionality does not restore the connection
[ https://issues.apache.org/jira/browse/QPID-4289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-4289: - Attachment: 0001-QPID-4289-Fix-failover-issues.patch [Java Client 0-8/0-9.x] Failover functionality does not restore the connection -- Key: QPID-4289 URL: https://issues.apache.org/jira/browse/QPID-4289 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.16, 0.18, 0.19 Reporter: Alex Rudyy Assignee: Robbie Gemmell Fix For: 0.19 Attachments: 0001-QPID-4289-Fix-failover-issues.patch Failover functionality on 0-8/0-9.x java client does not restore the connection in the following scenarios: * when on initial establishing of the connectivity the connection object is marked as closed after not being able to connect to the first brokers from the broker list but at the end it manages to connect to the one of the following brokers from the broker list * there is a racing condition between waking up the connection state waiter and closing the phisical connection on receiving ConnectionClose command from the broker. As result, waiters are notified, new connection is created and closed afterwards. * on killing the broker when no IOException is thrown from socket input/output streams but instead -1 is returned by read operation, the failover starts but IoSender thread is left running. As result, on multiple reconnection attempts the thread resources can be exhausted and that can potentially result in OOME. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-4268) C++ Broker needs Acl support for limiting on-disk store
[ https://issues.apache.org/jira/browse/QPID-4268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved QPID-4268. --- Resolution: Fixed Fix Version/s: 0.19 Fixed with r1382095 C++ Broker needs Acl support for limiting on-disk store --- Key: QPID-4268 URL: https://issues.apache.org/jira/browse/QPID-4268 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.18 Reporter: Chuck Rolke Assignee: Chuck Rolke Fix For: 0.19 The C++ Broker currently has Acl support for limiting the in-memory size of a queue and the maximum number of messages that the queue may contain. When creating a queue a user may specify options qpid.max_size and qpid.max_count. Acl support exists to specify properties: queuemaxsizeupperlimit, queuemaxsizelowerlimit, queuemaxcountupperlimit, queuemaxcountlowerlimit to constrain the bounds of a queue that a user may create. This jira issue adds similar support for options qpid.file_size and qpid.file_count. The Acl support shall add properties: filemaxsizeupperlimit, filemaxsizelowerlimit, filemaxcountupperlimit, filemaxcountlowerlimit to similarly constrain the file store settings. This jira does NOT add new options to queue creation. Tool qpid-config already specifies these options and the broker and store process them. The jira simply provides a method for administrators to constrain users file settings. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-4257) Windows+SSL: Client hang on broker close, broker memory leak
[ https://issues.apache.org/jira/browse/QPID-4257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved QPID-4257. --- Resolution: Fixed Fixed with r1382026 Windows+SSL: Client hang on broker close, broker memory leak Key: QPID-4257 URL: https://issues.apache.org/jira/browse/QPID-4257 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Client Affects Versions: 0.12, 0.13, 0.14, 0.15, 0.16, 0.17, 0.18, 0.19 Environment: Windows client on Windows 7, Windows broker on Server 2K8, using SSL. Reporter: Kerry Bonin Labels: patch Fix For: 0.19 Attachments: windows_ssl_hang_r1377724.patch Original Estimate: 168h Remaining Estimate: 168h Windows clients hang when broker dies via SSL connection - fetch never returns even w/ IMMEDIATE timeout. Windows broker memory grows linearly with SSL connection count, leak per connection, until broker exhausts memory and crashes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4263) HA broker can crash due to priority queue corruption
[ https://issues.apache.org/jira/browse/QPID-4263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450928#comment-13450928 ] Alan Conway commented on QPID-4263: --- MessageDeque::setPosition(n) only erases messages *after* n. According to the precondition for setPosition, there cannot be any un-deleted messages after n so this is OK. HA broker can crash due to priority queue corruption Key: QPID-4263 URL: https://issues.apache.org/jira/browse/QPID-4263 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.18 Reporter: Jason Dillaman Similar to QPID-4262 and discovered via code review while investigating the other issue, it appears that it is possible for the priority queue's messages deques to become out-of-sync with their backing fifo deque if PriorityQueue::setPosition is invoked. That method will delete messages from the backing MessageDeque collection without removing the pointers to the deleted messages from the PriorityQueue. The HA and replication plugins can both invoke this method on a queue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-4263) HA broker can crash due to priority queue corruption
[ https://issues.apache.org/jira/browse/QPID-4263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved QPID-4263. --- Resolution: Not A Problem Assignee: Alan Conway HA broker can crash due to priority queue corruption Key: QPID-4263 URL: https://issues.apache.org/jira/browse/QPID-4263 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.18 Reporter: Jason Dillaman Assignee: Alan Conway Similar to QPID-4262 and discovered via code review while investigating the other issue, it appears that it is possible for the priority queue's messages deques to become out-of-sync with their backing fifo deque if PriorityQueue::setPosition is invoked. That method will delete messages from the backing MessageDeque collection without removing the pointers to the deleted messages from the PriorityQueue. The HA and replication plugins can both invoke this method on a queue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-4263) HA broker can crash due to priority queue corruption
[ https://issues.apache.org/jira/browse/QPID-4263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13450928#comment-13450928 ] Alan Conway edited comment on QPID-4263 at 9/8/12 7:05 AM: --- MessageDeque::setPosition only erases messages *after* the position. According to the precondition for setPosition, there cannot be any un-deleted messages after the position so this is OK. was (Author: aconway): MessageDeque::setPosition(n) only erases messages *after* n. According to the precondition for setPosition, there cannot be any un-deleted messages after n so this is OK. HA broker can crash due to priority queue corruption Key: QPID-4263 URL: https://issues.apache.org/jira/browse/QPID-4263 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.18 Reporter: Jason Dillaman Assignee: Alan Conway Similar to QPID-4262 and discovered via code review while investigating the other issue, it appears that it is possible for the priority queue's messages deques to become out-of-sync with their backing fifo deque if PriorityQueue::setPosition is invoked. That method will delete messages from the backing MessageDeque collection without removing the pointers to the deleted messages from the PriorityQueue. The HA and replication plugins can both invoke this method on a queue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-4142) C++ broker connection counting username error when used in ha cluster and auth is EXTERNAL
[ https://issues.apache.org/jira/browse/QPID-4142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke closed QPID-4142. - This patch was for 0.18 only. Since it has been merged to the 0.18 branch it has no business on trunk. Checkin r1382155 reverts the change in trunk. C++ broker connection counting username error when used in ha cluster and auth is EXTERNAL -- Key: QPID-4142 URL: https://issues.apache.org/jira/browse/QPID-4142 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.18 Reporter: Chuck Rolke Assignee: Chuck Rolke Fix For: 0.18 In a cluster setup with auth enabled and set to EXTERNAL then the Acl connection counting does not get the correct username associated with a shadowed connection. The cluster member that accepts the connection accounts for the correct user name. Other cluster members that receive shadow connections see user name 'anonymous'. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
