[jira] [Created] (QPID-5942) qpid HA cluster may end-up in joining state after HA primary is killed
Alan Conway created QPID-5942: - Summary: qpid HA cluster may end-up in joining state after HA primary is killed Key: QPID-5942 URL: https://issues.apache.org/jira/browse/QPID-5942 Project: Qpid Issue Type: Bug Components: C++ Clustering Affects Versions: 0.28 Reporter: Alan Conway Assignee: Alan Conway See also: https://bugzilla.redhat.com/show_bug.cgi?id=1117823 Description of problem: qpid HA cluster may end-up in joining state after HA primary is killed. Test scenario. Let's have 3 node qpid HA cluster, all three nodes are operational. Then a sender is executed and sending to queue (pure transactional with durable messages and durable queue address). During that process primary broker is killed multiple times. After N'th primary broker kill cluster is no longer functional as qpid brokers are ending all in joining states: [root@dhcp-lab-216 ~]# qpid-ha status --all 192.168.6.60:5672 joining 192.168.6.61:5672 joining 192.168.6.62:5672 joining [root@dhcp-x-216 ~]# clustat Cluster Status for dtests_ha @ Wed Jul 9 14:38:44 2014 Member Status: Quorate Member Name ID Status -- -- 192.168.6.60 1 Online, Local, rgmanager 192.168.6.61 2 Online, rgmanager 192.168.6.62 3 Online, rgmanager Service Name Owner (Last) State --- - -- - service:qpidd_1 192.168.6.60 started service:qpidd_2 192.168.6.61 started service:qpidd_3 192.168.6.62 started service:qpidd_primary(192.168.6.62) stopped [root@dhcp-x-165 ~]# qpid-ha status --all 192.168.6.60:5672 joining 192.168.6.61:5672 joining 192.168.6.62:5672 joining [root@dhcp-x-218 ~]# qpid-ha status --all 192.168.6.60:5672 joining 192.168.6.61:5672 joining 192.168.6.62:5672 joining I believe the key to hit the issue is to kill the newly promoted primary soon after it starts appearing in starting/started state in clustat. My current understanding is that if we have 3 node cluster then applying any failures to single node at one time should be handled by HA. This is what the testing scenario does: ABC (nodes) pri bck bck kill bck pri bck kill bck bck pri kill ... pri bck bck kill bck bck bck It looks to me that there is short time when promoting new primary when kill causes (of such primary newbee) causes promotion procedure to stuck in all joining. I haven't seen such behavior in past, either we are now more sensitive to such case (after -STOP case fixes) or the durability turned on rapidly raises the probability. Version-Release number of selected component (if applicable): # rpm -qa | grep qpid | sort perl-qpid-0.22-13.el6.i686 perl-qpid-debuginfo-0.22-13.el6.i686 python-qpid-0.22-15.el6.noarch python-qpid-proton-doc-0.5-9.el6.noarch python-qpid-qmf-0.22-33.el6.i686 qpid-cpp-client-0.22-42.el6.i686 qpid-cpp-client-devel-0.22-42.el6.i686 qpid-cpp-client-devel-docs-0.22-42.el6.noarch qpid-cpp-client-rdma-0.22-42.el6.i686 qpid-cpp-debuginfo-0.22-42.el6.i686 qpid-cpp-server-0.22-42.el6.i686 qpid-cpp-server-devel-0.22-42.el6.i686 qpid-cpp-server-ha-0.22-42.el6.i686 qpid-cpp-server-linearstore-0.22-42.el6.i686 qpid-cpp-server-rdma-0.22-42.el6.i686 qpid-cpp-server-xml-0.22-42.el6.i686 qpid-java-client-0.22-6.el6.noarch qpid-java-common-0.22-6.el6.noarch qpid-java-example-0.22-6.el6.noarch qpid-jca-0.22-2.el6.noarch qpid-jca-xarecovery-0.22-2.el6.noarch qpid-jca-zip-0.22-2.el6.noarch qpid-proton-c-0.7-2.el6.i686 qpid-proton-c-devel-0.7-2.el6.i686 qpid-proton-c-devel-doc-0.5-9.el6.noarch qpid-proton-debuginfo-0.7-2.el6.i686 qpid-qmf-0.22-33.el6.i686 qpid-qmf-debuginfo-0.22-33.el6.i686 qpid-qmf-devel-0.22-33.el6.i686 qpid-snmpd-1.0.0-16.el6.i686 qpid-snmpd-debuginfo-1.0.0-16.el6.i686 qpid-tests-0.22-15.el6.noarch qpid-tools-0.22-13.el6.noarch ruby-qpid-qmf-0.22-33.el6.i686 How reproducible: rarely, timing is the key Steps to Reproduce: 1. have configured 3 node cluster 2. start the whole cluster up 3. execute transactional sender to durable queue address with durable messages and reconnect 4. repeatedly kill the primary broker once it is promoted Actual results: After few kills cluster ends up not functional all in joining. Ability to bring qpid HA down by inserting single isolated failures to newly being promoted brokers. Expected results: Qpid HA should be single failure at one time tolerant. Additional info: Details on failur
[jira] [Commented] (QPID-5941) Set sensible default build type
[ https://issues.apache.org/jira/browse/QPID-5941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14078261#comment-14078261 ] ASF subversion and git services commented on QPID-5941: --- Commit 1614472 from [~aconway] in branch 'qpid/trunk' [ https://svn.apache.org/r1614472 ] QPID-5941: Set sensible default build type: default is RelWithDebInfo. > Set sensible default build type > --- > > Key: QPID-5941 > URL: https://issues.apache.org/jira/browse/QPID-5941 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.28 >Reporter: Alan Conway >Assignee: Alan Conway > > The cmake default build type is a sort of "didn't bother with flags" build - > it has neither debugging symbols nor optimization and so is not well suited > to anything. > - Make the default one of the standard build types: Release, Debug, > RelWithDebInfo and MinRel. > - Mention all the available build types in the INSTALL file. > - Mention the default build type in the initial cmake output. > Based on the discussion here: > http://qpid.2158936.n2.nabble.com/How-to-test-the-performance-quid-c-broker-td7610614i20.html#a7611007 > the majority opinion is to use RelWithDebInfo. It was not unanimous, but > this is only the default so people can change it towhatever they like and the > doc. will make that clear. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5941) Set sensible default build type
Alan Conway created QPID-5941: - Summary: Set sensible default build type Key: QPID-5941 URL: https://issues.apache.org/jira/browse/QPID-5941 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.28 Reporter: Alan Conway Assignee: Alan Conway The cmake default build type is a sort of "didn't bother with flags" build - it has neither debugging symbols nor optimization and so is not well suited to anything. - Make the default one of the standard build types: Release, Debug, RelWithDebInfo and MinRel. - Mention all the available build types in the INSTALL file. - Mention the default build type in the initial cmake output. Based on the discussion here: http://qpid.2158936.n2.nabble.com/How-to-test-the-performance-quid-c-broker-td7610614i20.html#a7611007 the majority opinion is to use RelWithDebInfo. It was not unanimous, but this is only the default so people can change it towhatever they like and the doc. will make that clear. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5920) Connecting Kaazing to ActiveMQ using quid amqp 1.0 client cause topic subscription issues
[
https://issues.apache.org/jira/browse/QPID-5920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14077986#comment-14077986
]
Josh Carlson commented on QPID-5920:
The default configuration isn't using AMQP but openwire and isn't using the
QPID client.
I just tried the example, Hello, program that is shipped with the client,
changed the Queue used to a Topic and I see the same behavior. So I'm not sure
this is anything Kaazing specific. I think it might actually be how it works
with AMQP but I'm not sure.
> Connecting Kaazing to ActiveMQ using quid amqp 1.0 client cause topic
> subscription issues
> -
>
> Key: QPID-5920
> URL: https://issues.apache.org/jira/browse/QPID-5920
> Project: Qpid
> Issue Type: Bug
> Components: JMS AMQP 1.0 Client
> Environment: mac osx ML
>Reporter: are
>Priority: Blocker
> Labels: javascript
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> Registering a new topic from kaazing and connecting to ActiveMQ using jms
> amqp 1.0 client. When looked into ActiveMQ web console and you will see topic
> gets registered under Queues, any reason. Also, if we use default JMS
> configuration all works well.?
> ConnectionFactory
>
> dynamicTopics/%s
>
> dynamicQueues/%s
>
> org.apache.activemq.jndi.ActiveMQInitialContextFactory
>
> tcp://${gateway.hostname}:61616
>
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5940) [Java Broker] Add meta-data servlet to allow UI to discover default values
Rob Godfrey created QPID-5940: - Summary: [Java Broker] Add meta-data servlet to allow UI to discover default values Key: QPID-5940 URL: https://issues.apache.org/jira/browse/QPID-5940 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Rob Godfrey Assignee: Rob Godfrey Fix For: 0.29 Metadata servlet can should use meta-data from the configured object type registry -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5940) [Java Broker] Add meta-data servlet to allow UI to discover default values
[ https://issues.apache.org/jira/browse/QPID-5940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14077781#comment-14077781 ] ASF subversion and git services commented on QPID-5940: --- Commit 1614370 from [~godfrer] in branch 'qpid/trunk' [ https://svn.apache.org/r1614370 ] QPID-5940 : [Java Broker] Add meta-data servlet > [Java Broker] Add meta-data servlet to allow UI to discover default values > -- > > Key: QPID-5940 > URL: https://issues.apache.org/jira/browse/QPID-5940 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: 0.29 > > > Metadata servlet can should use meta-data from the configured object type > registry -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5939) missing Sender's/Receiver's get_address() method
Darryl L. Pierce created QPID-5939:
--
Summary: missing Sender's/Receiver's get_address() method
Key: QPID-5939
URL: https://issues.apache.org/jira/browse/QPID-5939
Project: Qpid
Issue Type: Bug
Components: Perl Client
Reporter: Darryl L. Pierce
Assignee: Darryl L. Pierce
Over amqp1.0, the name for nodes starting with a '#' character is determined by
the server. In this case the name assigned needs to be communicated back to the
application when the attach succeeds. To handle that a new accessor -
getAddress() - has been added to both Sender and Receiver.
Perl binding shall provide these accessors. Otherwise there is no way how to
determine the name assigned by the server.
please see additional info for suggested solution and description how this
issue affect our client/server example clients.
Version-Release number of selected component (if applicable):
perl-qpid-0.22-13
How reproducible:
100%
Steps to Reproduce:
1. create a node starting with a '#' character over amqp1.0
2. determine the assigned name from the apllication
3. not possible
Actual results:
Senders's/Receiver's get_address() api method NOT available
Expected results:
Senders's/Receiver's get_address() api method available
Additional info:
Note: this also effectively breaks the server/client example:
# ./server.pl localhost "{protocol:amqp1.0}"
# ./client.pl localhost "{protocol:amqp1.0}"
Delete policies not supported over AMQP 1.0. at
/usr/lib64/perl5/vendor_perl/qpid/messaging/Session.pm line 314.
When we workaround this issue with the following client change:
-"#response-queue; {create:always, delete:always}");
+"#response-queue; {create:always}");
then we get following error from the server:
Link detached by peer with amqp:not-found: Node not found:
df88d9b3-5f63-4be7-a942-59feae18190b#response-queue at
/usr/lib64/perl5/vendor_perl/qpid/messaging/Session.pm line 246.
This error may be fixed by providing access to the get_address() method and
related client code change, ie:
-my $responseQueue = new qpid::messaging::Address(
-"#response-queue; {create:always, delete:always}");
-my $receiver = $session->create_receiver($responseQueue);
+my $receiver = $session->create_receiver("#");
+my $responseQueue = $receiver->get_address();
===
Suggested code change:
Following change in the Sender.pm/Receiver.pm will solve the issue.
+ =pod
+
+ =over
+
+ =item $session = $receiver->get_address
+
+ Returns the B instance
+
+ =back
+
+ =cut
+
+ sub get_address {
+ my ($self) = @_;
+ my $impl = $self->{_impl};
+
+ return $impl->getAddress;
+ }
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5938) qpid-stat: remove dead code relevant to active-active cluster
Pavel Moravec created QPID-5938: --- Summary: qpid-stat: remove dead code relevant to active-active cluster Key: QPID-5938 URL: https://issues.apache.org/jira/browse/QPID-5938 Project: Qpid Issue Type: Improvement Components: Python Tools Affects Versions: 0.28 Reporter: Pavel Moravec Assignee: Pavel Moravec Priority: Trivial qpid-stat has some dead code relevant to old active-active clustering. That code is worth removal also as it calls gethostbyname method that is not thread safe, and thus potential re-usage of the code could bring thread safety problems. Dead code is: - class IpAddr - methods _getCluster and _getHostList -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5937) [Java Broker] Add parameters to REST servlet to allow return of actual vs. effective attribute values
[ https://issues.apache.org/jira/browse/QPID-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14077720#comment-14077720 ] ASF subversion and git services commented on QPID-5937: --- Commit 1614353 from [~godfrer] in branch 'qpid/trunk' [ https://svn.apache.org/r1614353 ] QPID-5937 : [Java Broker] Add parameters to REST servlet to allow return of actual vs. effective attribute values > [Java Broker] Add parameters to REST servlet to allow return of actual vs. > effective attribute values > - > > Key: QPID-5937 > URL: https://issues.apache.org/jira/browse/QPID-5937 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: 0.29 > > > Add parameters to the REST servlet to allow control over the retrieval of the > effective values of parameters, versus the "actual" values (which may need > interpolation or be inherited). -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5933) Python client infinite recursion if connection dropped
[
https://issues.apache.org/jira/browse/QPID-5933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14077716#comment-14077716
]
Alan Conway commented on QPID-5933:
---
Yep, your fix is fine, I marked this a duplicate.
> Python client infinite recursion if connection dropped
> --
>
> Key: QPID-5933
> URL: https://issues.apache.org/jira/browse/QPID-5933
> Project: Qpid
> Issue Type: Bug
> Components: Python Client
>Affects Versions: 0.28
>Reporter: Alan Conway
>Assignee: Alan Conway
>
> The python client goes into an infinite recursion if the connection is
> dropped at the wrong moment. This script demonstrates:
>
> import subprocess, qpid.messaging as qm, time
> out = open("qpidd.log", "w")
> broker = subprocess.Popen(["qpidd", "--auth=no"],
> stdout=out, stderr=subprocess.STDOUT)
> time.sleep(2)
> c = qm.Connection.establish("0.0.0.0")
> s = c.session()
> broker.kill()
> s.receiver("q")
>
> The recursion looks like this;
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 644, in receiver
> receiver._ewait(lambda: receiver.linked)
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 1010, in _ewait
> result = self.session._ewait(lambda: self.error or predicate(), timeout)
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 594, in _ewait
> result = self.connection._ewait(lambda: self.error or predicate(),
> timeout)
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 233, in _ewait
> self.check_error()
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 225, in check_error
> self.close()
> File "", line 6, in close
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 344, in close
> ssn.close(timeout=timeout)
> File "", line 6, in close
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 768, in close
> self.sync(timeout=timeout)
> File "", line 6, in sync
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 759, in sync
> if not self._ewait(lambda: not self.outgoing and not self.acked,
> timeout=timeout):
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 594, in _ewait
> result = self.connection._ewait(lambda: self.error or predicate(),
> timeout)
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 233, in _ewait
> self.check_error()
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 225, in check_error
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-5924) [linearstore] Qpidd Will Not Start with Large Number of Queues
[ https://issues.apache.org/jira/browse/QPID-5924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet updated QPID-5924: --- Summary: [linearstore] Qpidd Will Not Start with Large Number of Queues (was: Qpidd Will Not Start with Large Number of Queues) > [linearstore] Qpidd Will Not Start with Large Number of Queues > -- > > Key: QPID-5924 > URL: https://issues.apache.org/jira/browse/QPID-5924 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.22 > Environment: qpid-cpp-server-0.22-42 > qpid-cpp-server-linearstore-0.22-42 >Reporter: Brian Bouterse >Assignee: Kim van der Riet >Priority: Critical > > Pulp is an open source project that uses Qpidd. Pulp has need for a large > number of queues 10K+, and these queues need to be durable. When creating a > large number of queues (thousands), if you restart qpidd, it won't start. > Here is how to reproduce: > 1. Install qpid-cpp-server and qpid-cpp-server-store > 2. Start qpidd > 3. Create a crazy number of unique queues (10K) with durability > 4. Restart Qpidd > 5. Observe an error message such as the following > Starting Qpid AMQP daemon: Daemon startup failed: Queue > pulp.agent.5752dc04-7536-4e5c-b406-a0cd5d9c9119: recoverMessages() failed: > jexception 0x0104 RecoveryManager::getFile() threw JERR__FILEIO: File read or > write failure. > (/var/lib/qpidd/qls/jrnl/pulp.agent.5752dc04-7536-4e5c-b406-a0cd5d9c9119/818fa4b0-3319-4478-b2b0-d2195f90f695.jrnl) > > (/builddir/build/BUILD/qpid-0.22/cpp/src/qpid/linearstore/MessageStoreImpl.cpp:1004) > Looking at /var/lib/qpidd/qls/jrnl/ directory there is 2676 jrnl files, 2640 > of them start with pulp.agent. In our case the lots of queues are named > 'pulp.agent.'. > The expected behavior is that qpidd would start and run awesome with a crazy > number of queues (1 Million +). > Raising the number of file descriptors is a viable workaround, but eventually > those will run out too. It would be an architectural win if a constant number > of file descriptors were used that are not affected by the number of queues > qpidd is managing. > Perhaps this could be introduced as a new journal type that would run slower > but be more scalable. It could be introduced as > qpid-cpp-server-crazy-scalable-but-slower-store. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-5924) Qpidd Will Not Start with Large Number of Queues
[ https://issues.apache.org/jira/browse/QPID-5924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kim van der Riet reassigned QPID-5924: -- Assignee: Kim van der Riet > Qpidd Will Not Start with Large Number of Queues > > > Key: QPID-5924 > URL: https://issues.apache.org/jira/browse/QPID-5924 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.22 > Environment: qpid-cpp-server-0.22-42 > qpid-cpp-server-linearstore-0.22-42 >Reporter: Brian Bouterse >Assignee: Kim van der Riet >Priority: Critical > > Pulp is an open source project that uses Qpidd. Pulp has need for a large > number of queues 10K+, and these queues need to be durable. When creating a > large number of queues (thousands), if you restart qpidd, it won't start. > Here is how to reproduce: > 1. Install qpid-cpp-server and qpid-cpp-server-store > 2. Start qpidd > 3. Create a crazy number of unique queues (10K) with durability > 4. Restart Qpidd > 5. Observe an error message such as the following > Starting Qpid AMQP daemon: Daemon startup failed: Queue > pulp.agent.5752dc04-7536-4e5c-b406-a0cd5d9c9119: recoverMessages() failed: > jexception 0x0104 RecoveryManager::getFile() threw JERR__FILEIO: File read or > write failure. > (/var/lib/qpidd/qls/jrnl/pulp.agent.5752dc04-7536-4e5c-b406-a0cd5d9c9119/818fa4b0-3319-4478-b2b0-d2195f90f695.jrnl) > > (/builddir/build/BUILD/qpid-0.22/cpp/src/qpid/linearstore/MessageStoreImpl.cpp:1004) > Looking at /var/lib/qpidd/qls/jrnl/ directory there is 2676 jrnl files, 2640 > of them start with pulp.agent. In our case the lots of queues are named > 'pulp.agent.'. > The expected behavior is that qpidd would start and run awesome with a crazy > number of queues (1 Million +). > Raising the number of file descriptors is a viable workaround, but eventually > those will run out too. It would be an architectural win if a constant number > of file descriptors were used that are not affected by the number of queues > qpidd is managing. > Perhaps this could be introduced as a new journal type that would run slower > but be more scalable. It could be introduced as > qpid-cpp-server-crazy-scalable-but-slower-store. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-5933) Python client infinite recursion if connection dropped
[
https://issues.apache.org/jira/browse/QPID-5933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan Conway resolved QPID-5933.
---
Resolution: Fixed
> Python client infinite recursion if connection dropped
> --
>
> Key: QPID-5933
> URL: https://issues.apache.org/jira/browse/QPID-5933
> Project: Qpid
> Issue Type: Bug
> Components: Python Client
>Affects Versions: 0.28
>Reporter: Alan Conway
>Assignee: Alan Conway
>
> The python client goes into an infinite recursion if the connection is
> dropped at the wrong moment. This script demonstrates:
>
> import subprocess, qpid.messaging as qm, time
> out = open("qpidd.log", "w")
> broker = subprocess.Popen(["qpidd", "--auth=no"],
> stdout=out, stderr=subprocess.STDOUT)
> time.sleep(2)
> c = qm.Connection.establish("0.0.0.0")
> s = c.session()
> broker.kill()
> s.receiver("q")
>
> The recursion looks like this;
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 644, in receiver
> receiver._ewait(lambda: receiver.linked)
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 1010, in _ewait
> result = self.session._ewait(lambda: self.error or predicate(), timeout)
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 594, in _ewait
> result = self.connection._ewait(lambda: self.error or predicate(),
> timeout)
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 233, in _ewait
> self.check_error()
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 225, in check_error
> self.close()
> File "", line 6, in close
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 344, in close
> ssn.close(timeout=timeout)
> File "", line 6, in close
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 768, in close
> self.sync(timeout=timeout)
> File "", line 6, in sync
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 759, in sync
> if not self._ewait(lambda: not self.outgoing and not self.acked,
> timeout=timeout):
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 594, in _ewait
> result = self.connection._ewait(lambda: self.error or predicate(),
> timeout)
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 233, in _ewait
> self.check_error()
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 225, in check_error
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5932) Python console's sendMethodRequest() should handle arguments that have default values in the schema
[ https://issues.apache.org/jira/browse/QPID-5932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14077689#comment-14077689 ] ASF subversion and git services commented on QPID-5932: --- Commit 1614334 from [~kgiusti] in branch 'qpid/trunk' [ https://svn.apache.org/r1614334 ] QPID-5932: tweak patch to support older versions of python. > Python console's sendMethodRequest() should handle arguments that have > default values in the schema > > > Key: QPID-5932 > URL: https://issues.apache.org/jira/browse/QPID-5932 > Project: Qpid > Issue Type: Bug > Components: Python Client >Affects Versions: 0.22 >Reporter: Ernest Allen >Assignee: Ken Giusti >Priority: Minor > Attachments: bz1120081.svn.patch > > > The python console's sendMethodRequest() should handle some cases where the > number of arguments supplied do not match the number of arguments required by > the schema. > When there are too many arguments supplied, the assumption is that the client > is aware of a new argument, but the broker isn't. This is currently the case > when qpid-route is dealing with an older broker and calls link.bridge(). The > console will look for a named argument that was supplied, but isn't in the > broker's schema. If one is found, it is removed. This requires that the new > argument be named when it is passed to console. Otherwise we would have to > assume the last argument supplied was the extra one, and that would be risky. > When there are too few arguments supplied, the assumption is that client is > out of date and isn't aware a new argument that the schema requires. This is > currently the case when an old qpid-route is dealing with a new broker and > calls link.bridge(). The console will look for arguments in the schema that > have default values (starting at the end of the schema). If one is found, it > is added with the default value. This requires that all new arguments be > given a default value in the schema. > -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5937) [Java Broker] Add parameters to REST servlet to allow return of actual vs. effective attribute values
[ https://issues.apache.org/jira/browse/QPID-5937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14077681#comment-14077681 ] ASF subversion and git services commented on QPID-5937: --- Commit 1614333 from [~godfrer] in branch 'qpid/trunk' [ https://svn.apache.org/r1614333 ] QPID-5937 : [Java Broker] Add parameters to REST servlet to allow return of actual vs. effective attribute values > [Java Broker] Add parameters to REST servlet to allow return of actual vs. > effective attribute values > - > > Key: QPID-5937 > URL: https://issues.apache.org/jira/browse/QPID-5937 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Rob Godfrey >Assignee: Rob Godfrey > Fix For: 0.29 > > > Add parameters to the REST servlet to allow control over the retrieval of the > effective values of parameters, versus the "actual" values (which may need > interpolation or be inherited). -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5888) transaction should always be aborted on failover
[ https://issues.apache.org/jira/browse/QPID-5888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14077677#comment-14077677 ] ASF subversion and git services commented on QPID-5888: --- Commit 1614331 from [~aconway] in branch 'qpid/trunk' [ https://svn.apache.org/r1614331 ] QPID-5888: Fix test to ignore occasional TransactionAborted failures on connection.close. > transaction should always be aborted on failover > > > Key: QPID-5888 > URL: https://issues.apache.org/jira/browse/QPID-5888 > Project: Qpid > Issue Type: Bug > Components: Python Client >Affects Versions: 0.29 >Reporter: Gordon Sim >Assignee: Alan Conway > Fix For: 0.29 > > Attachments: qpid-txtest2.cpp.diff > > > At present, failover is entirely hidden from the client which is the wrong > thing to do for a transactional session. > The client should always abort the transaction on a failed session, and not > try to failover transparently. This is what would happen if the commit failed > due to some internal error on the broker (e.g. no space on disk or whatever). -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5937) [Java Broker] Add parameters to REST servlet to allow return of actual vs. effective attribute values
Rob Godfrey created QPID-5937: - Summary: [Java Broker] Add parameters to REST servlet to allow return of actual vs. effective attribute values Key: QPID-5937 URL: https://issues.apache.org/jira/browse/QPID-5937 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Rob Godfrey Assignee: Rob Godfrey Fix For: 0.29 Add parameters to the REST servlet to allow control over the retrieval of the effective values of parameters, versus the "actual" values (which may need interpolation or be inherited). -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (QPID-5932) Python console's sendMethodRequest() should handle arguments that have default values in the schema
[ https://issues.apache.org/jira/browse/QPID-5932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reopened QPID-5932: -- Patch can be refactored to support versions of python < 2.5 > Python console's sendMethodRequest() should handle arguments that have > default values in the schema > > > Key: QPID-5932 > URL: https://issues.apache.org/jira/browse/QPID-5932 > Project: Qpid > Issue Type: Bug > Components: Python Client >Affects Versions: 0.22 >Reporter: Ernest Allen >Assignee: Ken Giusti >Priority: Minor > Attachments: bz1120081.svn.patch > > > The python console's sendMethodRequest() should handle some cases where the > number of arguments supplied do not match the number of arguments required by > the schema. > When there are too many arguments supplied, the assumption is that the client > is aware of a new argument, but the broker isn't. This is currently the case > when qpid-route is dealing with an older broker and calls link.bridge(). The > console will look for a named argument that was supplied, but isn't in the > broker's schema. If one is found, it is removed. This requires that the new > argument be named when it is passed to console. Otherwise we would have to > assume the last argument supplied was the extra one, and that would be risky. > When there are too few arguments supplied, the assumption is that client is > out of date and isn't aware a new argument that the schema requires. This is > currently the case when an old qpid-route is dealing with a new broker and > calls link.bridge(). The console will look for arguments in the schema that > have default values (starting at the end of the schema). If one is found, it > is added with the default value. This requires that all new arguments be > given a default value in the schema. > -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-5936) Tests from suite VirtualHostMessageStoreTest are failing on json test profiles when BDB VH is used
[ https://issues.apache.org/jira/browse/QPID-5936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy reassigned QPID-5936: Assignee: Andrew MacBean (was: Alex Rudyy) > Tests from suite VirtualHostMessageStoreTest are failing on json test > profiles when BDB VH is used > -- > > Key: QPID-5936 > URL: https://issues.apache.org/jira/browse/QPID-5936 > Project: Qpid > Issue Type: Bug > Components: Java Tests >Reporter: Alex Rudyy >Assignee: Andrew MacBean > Fix For: 0.29 > > > In the test suite VirtualHostMessageStoreTest VH configuration store is > created in the same location as a message store. BDB message store requires a > sub-folder. JSON configuration store is stored in a file now. As result, > sub-folder for BDB message store cannot be created in JSON configuration > store location -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-5936) Tests from suite VirtualHostMessageStoreTest are failing on json test profiles when BDB VH is used
[ https://issues.apache.org/jira/browse/QPID-5936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew MacBean resolved QPID-5936. -- Resolution: Fixed > Tests from suite VirtualHostMessageStoreTest are failing on json test > profiles when BDB VH is used > -- > > Key: QPID-5936 > URL: https://issues.apache.org/jira/browse/QPID-5936 > Project: Qpid > Issue Type: Bug > Components: Java Tests >Reporter: Alex Rudyy >Assignee: Alex Rudyy > Fix For: 0.29 > > > In the test suite VirtualHostMessageStoreTest VH configuration store is > created in the same location as a message store. BDB message store requires a > sub-folder. JSON configuration store is stored in a file now. As result, > sub-folder for BDB message store cannot be created in JSON configuration > store location -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-5936) Tests from suite VirtualHostMessageStoreTest are failing on json test profiles when BDB VH is used
[ https://issues.apache.org/jira/browse/QPID-5936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alex Rudyy updated QPID-5936: - Status: Reviewable (was: In Progress) > Tests from suite VirtualHostMessageStoreTest are failing on json test > profiles when BDB VH is used > -- > > Key: QPID-5936 > URL: https://issues.apache.org/jira/browse/QPID-5936 > Project: Qpid > Issue Type: Bug > Components: Java Tests >Reporter: Alex Rudyy >Assignee: Alex Rudyy > Fix For: 0.29 > > > In the test suite VirtualHostMessageStoreTest VH configuration store is > created in the same location as a message store. BDB message store requires a > sub-folder. JSON configuration store is stored in a file now. As result, > sub-folder for BDB message store cannot be created in JSON configuration > store location -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-5925) Requesting qpid-python on PyPi has 2 patches backported
[ https://issues.apache.org/jira/browse/QPID-5925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce resolved QPID-5925. Resolution: Fixed Fix Version/s: 0.26 Assignee: Darryl L. Pierce I've applied the patches from QPID-5557 and QPID-5637 and generated a new source tarball, 0.26.1. It's now pushed to PyPI. https://pypi.python.org/pypi/qpid-python > Requesting qpid-python on PyPi has 2 patches backported > --- > > Key: QPID-5925 > URL: https://issues.apache.org/jira/browse/QPID-5925 > Project: Qpid > Issue Type: Bug > Components: Python Client >Affects Versions: 0.26 > Environment: https://pypi.python.org/pypi/qpid-python >Reporter: Brian Bouterse >Assignee: Darryl L. Pierce >Priority: Minor > Fix For: 0.26 > > > It would be really great if the patches associated with QPID-5637 and > QPID-5557 were applied to the Qpid 0.26 client bits offered through the > qpid-python package. Currently my Kombu code monkey patches qpid.messaging > for these two patches; it would be great to stop doing that. Some > environments get their qpid bits from PyPi as a dependency for this Kombu > code. > qpid-python is available on PyPi [0], and currently has 0.26, but those two > patches were not merged until the 0.28 release. Please apply the patches onto > the package, and re-upload to PyPi. I'm not sure how PyPi handles multiple > versions of the same release, but a new release of the same version (0.26) > should be made. > Once updated on PyPi, leave a comment and I can test it. > [0]: https://pypi.python.org/pypi/qpid-python -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5936) Tests from suite VirtualHostMessageStoreTest are failing on json test profiles when BDB VH is used
[ https://issues.apache.org/jira/browse/QPID-5936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14077651#comment-14077651 ] ASF subversion and git services commented on QPID-5936: --- Commit 1614320 from oru...@apache.org in branch 'qpid/trunk' [ https://svn.apache.org/r1614320 ] QPID-5936: Fix VirtualHostMessageStoreTest failing on json test profiles > Tests from suite VirtualHostMessageStoreTest are failing on json test > profiles when BDB VH is used > -- > > Key: QPID-5936 > URL: https://issues.apache.org/jira/browse/QPID-5936 > Project: Qpid > Issue Type: Bug > Components: Java Tests >Reporter: Alex Rudyy >Assignee: Alex Rudyy > Fix For: 0.29 > > > In the test suite VirtualHostMessageStoreTest VH configuration store is > created in the same location as a message store. BDB message store requires a > sub-folder. JSON configuration store is stored in a file now. As result, > sub-folder for BDB message store cannot be created in JSON configuration > store location -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5936) Tests from suite VirtualHostMessageStoreTest are failing on json test profiles when BDB VH is used
Alex Rudyy created QPID-5936: Summary: Tests from suite VirtualHostMessageStoreTest are failing on json test profiles when BDB VH is used Key: QPID-5936 URL: https://issues.apache.org/jira/browse/QPID-5936 Project: Qpid Issue Type: Bug Components: Java Tests Reporter: Alex Rudyy Assignee: Alex Rudyy Fix For: 0.29 In the test suite VirtualHostMessageStoreTest VH configuration store is created in the same location as a message store. BDB message store requires a sub-folder. JSON configuration store is stored in a file now. As result, sub-folder for BDB message store cannot be created in JSON configuration store location -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5932) Python console's sendMethodRequest() should handle arguments that have default values in the schema
[
https://issues.apache.org/jira/browse/QPID-5932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14077621#comment-14077621
]
Keith Wall commented on QPID-5932:
--
Hi Ken,
That patch, specifically the following line, brings a requirement for Python
2.5. We still test the Python client on 2.4, so this commit has broken our
Jenkins job. Could this be refactored to avoid the 2.5 dependency?
return objs[0]._sendMethodRequest(name, argList, {}) if objs else None
Thanks, Keith.
> Python console's sendMethodRequest() should handle arguments that have
> default values in the schema
>
>
> Key: QPID-5932
> URL: https://issues.apache.org/jira/browse/QPID-5932
> Project: Qpid
> Issue Type: Bug
> Components: Python Client
>Affects Versions: 0.22
>Reporter: Ernest Allen
>Assignee: Ken Giusti
>Priority: Minor
> Attachments: bz1120081.svn.patch
>
>
> The python console's sendMethodRequest() should handle some cases where the
> number of arguments supplied do not match the number of arguments required by
> the schema.
> When there are too many arguments supplied, the assumption is that the client
> is aware of a new argument, but the broker isn't. This is currently the case
> when qpid-route is dealing with an older broker and calls link.bridge(). The
> console will look for a named argument that was supplied, but isn't in the
> broker's schema. If one is found, it is removed. This requires that the new
> argument be named when it is passed to console. Otherwise we would have to
> assume the last argument supplied was the extra one, and that would be risky.
> When there are too few arguments supplied, the assumption is that client is
> out of date and isn't aware a new argument that the schema requires. This is
> currently the case when an old qpid-route is dealing with a new broker and
> calls link.bridge(). The console will look for arguments in the schema that
> have default values (starting at the end of the schema). If one is found, it
> is added with the default value. This requires that all new arguments be
> given a default value in the schema.
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5933) Python client infinite recursion if connection dropped
[
https://issues.apache.org/jira/browse/QPID-5933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14077594#comment-14077594
]
Pavel Moravec commented on QPID-5933:
-
There was a regression caused by wrong fix of QPID-5852 (in r1605855) that was
properly fixed and regression removed in r1613270.
Could you try the script prior both commits or after both? (both commits change
just one place in one file, trivial to revert).
As on trunk, I get expected output:
~~~
Traceback (most recent call last):
File "test.py", line 9, in
s.receiver("q")
File "", line 6, in receiver
File "/home/pmoravec/qpid-trunk/qpid/python/qpid/messaging/endpoints.py",
line 645, in receiver
receiver._ewait(lambda: receiver.linked)
File "/home/pmoravec/qpid-trunk/qpid/python/qpid/messaging/endpoints.py",
line 1011, in _ewait
result = self.session._ewait(lambda: self.error or predicate(), timeout)
File "/home/pmoravec/qpid-trunk/qpid/python/qpid/messaging/endpoints.py",
line 595, in _ewait
result = self.connection._ewait(lambda: self.error or predicate(), timeout)
File "/home/pmoravec/qpid-trunk/qpid/python/qpid/messaging/endpoints.py",
line 234, in _ewait
self.check_error()
File "/home/pmoravec/qpid-trunk/qpid/python/qpid/messaging/endpoints.py",
line 227, in check_error
raise e
qpid.messaging.exceptions.ConnectionError: [Errno 104] Connection reset by peer
~~~
> Python client infinite recursion if connection dropped
> --
>
> Key: QPID-5933
> URL: https://issues.apache.org/jira/browse/QPID-5933
> Project: Qpid
> Issue Type: Bug
> Components: Python Client
>Affects Versions: 0.28
>Reporter: Alan Conway
>Assignee: Alan Conway
>
> The python client goes into an infinite recursion if the connection is
> dropped at the wrong moment. This script demonstrates:
>
> import subprocess, qpid.messaging as qm, time
> out = open("qpidd.log", "w")
> broker = subprocess.Popen(["qpidd", "--auth=no"],
> stdout=out, stderr=subprocess.STDOUT)
> time.sleep(2)
> c = qm.Connection.establish("0.0.0.0")
> s = c.session()
> broker.kill()
> s.receiver("q")
>
> The recursion looks like this;
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 644, in receiver
> receiver._ewait(lambda: receiver.linked)
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 1010, in _ewait
> result = self.session._ewait(lambda: self.error or predicate(), timeout)
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 594, in _ewait
> result = self.connection._ewait(lambda: self.error or predicate(),
> timeout)
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 233, in _ewait
> self.check_error()
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 225, in check_error
> self.close()
> File "", line 6, in close
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 344, in close
> ssn.close(timeout=timeout)
> File "", line 6, in close
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 768, in close
> self.sync(timeout=timeout)
> File "", line 6, in sync
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 759, in sync
> if not self._ewait(lambda: not self.outgoing and not self.acked,
> timeout=timeout):
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 594, in _ewait
> result = self.connection._ewait(lambda: self.error or predicate(),
> timeout)
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 233, in _ewait
> self.check_error()
> File "/usr/local/lib/python2.6/site-packages/qpid/messaging/endpoints.py",
> line 225, in check_error
--
This message was sent by Atlassian JIRA
(v6.2#6252)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-5929) [C++ broker] Mark deprecated QMF fields as Deprecated in management-schema.xml
[ https://issues.apache.org/jira/browse/QPID-5929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Moravec resolved QPID-5929. - Resolution: Fixed Fix Version/s: Future Committed as r1614301. > [C++ broker] Mark deprecated QMF fields as Deprecated in management-schema.xml > -- > > Key: QPID-5929 > URL: https://issues.apache.org/jira/browse/QPID-5929 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: 0.28 >Reporter: Pavel Moravec >Assignee: Pavel Moravec >Priority: Minor > Fix For: Future > > > QMF schema contains various deprecated fields (properties and statistics) > that have been deprecated and are left in the broker just for backward > compatibility. Many of them lack any sign they were deprecated, what makes > users confusing. > Some code cleanup can be done based on that as well, as there are calls to > update deprecated field like Connection shadow property. > List of deprecated QMF fields: > - class Broker: > msgFtdEnqueues > msgFtdDequeues > byteFtdEnqueues > byteFtdDequeues > msgFtdDepth > byteFtdDepth > stagingThreshold > - class Queue: > msgFtdEnqueues > msgFtdDequeues > byteFtdEnqueues > byteFtdDequeues > msgFtdDepth > byteFtdDepth > unackedMessages > messageLatency > - class Exchange: > producerCount > - class Connection: > SystemConnection > userProxyAuth > federationLink > shadow > - class Session: > clientCredit > framesOutstanding > detachedLifespan > maxClientRate > - class ManagementSetupState: > objectNum > bootSequence > - class (linear)Store: > tplOutstandingAIOs > - class (linear)Journal: > freeFileCount > availableFileCount > writeWaitFailures > writeBusyFailures > readRecordCount > readBusyFailures > writePageCacheDepth > readPageCacheDepth > baseFileName > writePageSize > writePages > readPageSize > readPages > - class (legacy)Store: > tplOutstandingAIOs > - class (legacy)Journal: > freeFileCount > availableFileCount > writeWaitFailures > writeBusyFailures > readRecordCount > readBusyFailures > writePageCacheDepth > readPageCacheDepth > autoExpand > maxFileCount -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Closed] (QPID-5929) [C++ broker] Mark deprecated QMF fields as Deprecated in management-schema.xml
[ https://issues.apache.org/jira/browse/QPID-5929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Moravec closed QPID-5929. --- > [C++ broker] Mark deprecated QMF fields as Deprecated in management-schema.xml > -- > > Key: QPID-5929 > URL: https://issues.apache.org/jira/browse/QPID-5929 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: 0.28 >Reporter: Pavel Moravec >Assignee: Pavel Moravec >Priority: Minor > Fix For: Future > > > QMF schema contains various deprecated fields (properties and statistics) > that have been deprecated and are left in the broker just for backward > compatibility. Many of them lack any sign they were deprecated, what makes > users confusing. > Some code cleanup can be done based on that as well, as there are calls to > update deprecated field like Connection shadow property. > List of deprecated QMF fields: > - class Broker: > msgFtdEnqueues > msgFtdDequeues > byteFtdEnqueues > byteFtdDequeues > msgFtdDepth > byteFtdDepth > stagingThreshold > - class Queue: > msgFtdEnqueues > msgFtdDequeues > byteFtdEnqueues > byteFtdDequeues > msgFtdDepth > byteFtdDepth > unackedMessages > messageLatency > - class Exchange: > producerCount > - class Connection: > SystemConnection > userProxyAuth > federationLink > shadow > - class Session: > clientCredit > framesOutstanding > detachedLifespan > maxClientRate > - class ManagementSetupState: > objectNum > bootSequence > - class (linear)Store: > tplOutstandingAIOs > - class (linear)Journal: > freeFileCount > availableFileCount > writeWaitFailures > writeBusyFailures > readRecordCount > readBusyFailures > writePageCacheDepth > readPageCacheDepth > baseFileName > writePageSize > writePages > readPageSize > readPages > - class (legacy)Store: > tplOutstandingAIOs > - class (legacy)Journal: > freeFileCount > availableFileCount > writeWaitFailures > writeBusyFailures > readRecordCount > readBusyFailures > writePageCacheDepth > readPageCacheDepth > autoExpand > maxFileCount -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5929) [C++ broker] Mark deprecated QMF fields as Deprecated in management-schema.xml
[ https://issues.apache.org/jira/browse/QPID-5929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14077581#comment-14077581 ] ASF subversion and git services commented on QPID-5929: --- Commit 1614301 from [~pmoravec] in branch 'qpid/trunk' [ https://svn.apache.org/r1614301 ] [QPID-5929]: Mark deprecated QMF fields as Deprecated and do some relevant code cleanup > [C++ broker] Mark deprecated QMF fields as Deprecated in management-schema.xml > -- > > Key: QPID-5929 > URL: https://issues.apache.org/jira/browse/QPID-5929 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: 0.28 >Reporter: Pavel Moravec >Assignee: Pavel Moravec >Priority: Minor > > QMF schema contains various deprecated fields (properties and statistics) > that have been deprecated and are left in the broker just for backward > compatibility. Many of them lack any sign they were deprecated, what makes > users confusing. > Some code cleanup can be done based on that as well, as there are calls to > update deprecated field like Connection shadow property. > List of deprecated QMF fields: > - class Broker: > msgFtdEnqueues > msgFtdDequeues > byteFtdEnqueues > byteFtdDequeues > msgFtdDepth > byteFtdDepth > stagingThreshold > - class Queue: > msgFtdEnqueues > msgFtdDequeues > byteFtdEnqueues > byteFtdDequeues > msgFtdDepth > byteFtdDepth > unackedMessages > messageLatency > - class Exchange: > producerCount > - class Connection: > SystemConnection > userProxyAuth > federationLink > shadow > - class Session: > clientCredit > framesOutstanding > detachedLifespan > maxClientRate > - class ManagementSetupState: > objectNum > bootSequence > - class (linear)Store: > tplOutstandingAIOs > - class (linear)Journal: > freeFileCount > availableFileCount > writeWaitFailures > writeBusyFailures > readRecordCount > readBusyFailures > writePageCacheDepth > readPageCacheDepth > baseFileName > writePageSize > writePages > readPageSize > readPages > - class (legacy)Store: > tplOutstandingAIOs > - class (legacy)Journal: > freeFileCount > availableFileCount > writeWaitFailures > writeBusyFailures > readRecordCount > readBusyFailures > writePageCacheDepth > readPageCacheDepth > autoExpand > maxFileCount -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-5935) Web Management UI style refactor to remove html inline styles and standardise via css
[ https://issues.apache.org/jira/browse/QPID-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew MacBean reassigned QPID-5935: Assignee: Keith Wall (was: Andrew MacBean) Could you please review this commit for me. It's an attempt at trying to standardise some of the UI elements and make better use of the common.css rather than inline style in HTML. > Web Management UI style refactor to remove html inline styles and standardise > via css > - > > Key: QPID-5935 > URL: https://issues.apache.org/jira/browse/QPID-5935 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Andrew MacBean >Assignee: Keith Wall >Priority: Minor > > The web UI HTML markup contains many uses of inline css style which in many > cases is actually redundant. > Much of it can be refactored into the CSS for .formLabel-labelCell and > .tableContainer-labelCell and the others simply removed. > In order to do this a standard label width has been set as 300px but purely > based on the majority currently set inline. > This change will not change the JS generated html markup or the tables based > to use CSS, this is something to consider to make everything consistent. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-5935) Web Management UI style refactor to remove html inline styles and standardise via css
[ https://issues.apache.org/jira/browse/QPID-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew MacBean updated QPID-5935: - Status: Reviewable (was: In Progress) > Web Management UI style refactor to remove html inline styles and standardise > via css > - > > Key: QPID-5935 > URL: https://issues.apache.org/jira/browse/QPID-5935 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Andrew MacBean >Assignee: Andrew MacBean >Priority: Minor > > The web UI HTML markup contains many uses of inline css style which in many > cases is actually redundant. > Much of it can be refactored into the CSS for .formLabel-labelCell and > .tableContainer-labelCell and the others simply removed. > In order to do this a standard label width has been set as 300px but purely > based on the majority currently set inline. > This change will not change the JS generated html markup or the tables based > to use CSS, this is something to consider to make everything consistent. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5935) Web Management UI style refactor to remove html inline styles and standardise via css
[ https://issues.apache.org/jira/browse/QPID-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14077568#comment-14077568 ] ASF subversion and git services commented on QPID-5935: --- Commit 1614299 from [~macbean] in branch 'qpid/trunk' [ https://svn.apache.org/r1614299 ] QPID-5935: [Java Broker] Web Management UI style refactor to remove html inline styles and standardise via css > Web Management UI style refactor to remove html inline styles and standardise > via css > - > > Key: QPID-5935 > URL: https://issues.apache.org/jira/browse/QPID-5935 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Andrew MacBean >Assignee: Andrew MacBean >Priority: Minor > > The web UI HTML markup contains many uses of inline css style which in many > cases is actually redundant. > Much of it can be refactored into the CSS for .formLabel-labelCell and > .tableContainer-labelCell and the others simply removed. > In order to do this a standard label width has been set as 300px but purely > based on the majority currently set inline. > This change will not change the JS generated html markup or the tables based > to use CSS, this is something to consider to make everything consistent. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-5935) Web Management UI style refactor to remove html inline styles and standardise via css
[ https://issues.apache.org/jira/browse/QPID-5935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew MacBean updated QPID-5935: - Description: The web UI HTML markup contains many uses of inline css style which in many cases is actually redundant. Much of it can be refactored into the CSS for .formLabel-labelCell and .tableContainer-labelCell and the others simply removed. In order to do this a standard label width has been set as 300px but purely based on the majority currently set inline. This change will not change the JS generated html markup or the tables based to use CSS, this is something to consider to make everything consistent. was: The web UI HTML markup contains many uses of inline css style which in many cases is actually redundant. Much of it can be refactored into the CSS for .formLabel-labelCell and .tableContainer-labelCell and the others simply removed. In order to do this a standard label width has been set as 300px. > Web Management UI style refactor to remove html inline styles and standardise > via css > - > > Key: QPID-5935 > URL: https://issues.apache.org/jira/browse/QPID-5935 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Andrew MacBean >Assignee: Andrew MacBean >Priority: Minor > > The web UI HTML markup contains many uses of inline css style which in many > cases is actually redundant. > Much of it can be refactored into the CSS for .formLabel-labelCell and > .tableContainer-labelCell and the others simply removed. > In order to do this a standard label width has been set as 300px but purely > based on the majority currently set inline. > This change will not change the JS generated html markup or the tables based > to use CSS, this is something to consider to make everything consistent. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-5935) Web Management UI style refactor to remove html inline styles and standardise via css
Andrew MacBean created QPID-5935: Summary: Web Management UI style refactor to remove html inline styles and standardise via css Key: QPID-5935 URL: https://issues.apache.org/jira/browse/QPID-5935 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Andrew MacBean Assignee: Andrew MacBean Priority: Minor The web UI HTML markup contains many uses of inline css style which in many cases is actually redundant. Much of it can be refactored into the CSS for .formLabel-labelCell and .tableContainer-labelCell and the others simply removed. In order to do this a standard label width has been set as 300px. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-5876) Java client causes unecessary rejects after failover when using 0-8..0-9-1 protocols
[ https://issues.apache.org/jira/browse/QPID-5876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-5876: - Description: Highest delivery tag variable not reset after failover and causes rejections to be sent unnecessarily, which the Broker has to ignore. The AMQSession.resubscribe() implementation does not reset the _highestDeliveryTag member variable. This means that rejects are send needlessly/incorrectly after failover occurs as the value is higher than it should be. was: Highest delivery tag variable not reset after failover and causes rejections to be sent unecessarily. The AMQSession.resubscribe() implementation does not reset the _highestDeliveryTag member variable. This means that rejects are send needlessly/incorrectly after failover occurs as the value is higher than it should be. > Java client causes unecessary rejects after failover when using 0-8..0-9-1 > protocols > > > Key: QPID-5876 > URL: https://issues.apache.org/jira/browse/QPID-5876 > Project: Qpid > Issue Type: Bug > Components: Java Client >Reporter: Andrew MacBean >Assignee: Keith Wall > > Highest delivery tag variable not reset after failover and causes rejections > to be sent unnecessarily, which the Broker has to ignore. > The AMQSession.resubscribe() implementation does not reset the > _highestDeliveryTag member variable. This means that rejects are send > needlessly/incorrectly after failover occurs as the value is higher than it > should be. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-5876) Java client causes unecessary rejects after failover when using 0-8..0-9-1 protocols
[ https://issues.apache.org/jira/browse/QPID-5876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-5876: - Fix Version/s: (was: 0.29) > Java client causes unecessary rejects after failover when using 0-8..0-9-1 > protocols > > > Key: QPID-5876 > URL: https://issues.apache.org/jira/browse/QPID-5876 > Project: Qpid > Issue Type: Bug > Components: Java Client >Reporter: Andrew MacBean >Assignee: Keith Wall > > Highest delivery tag variable not reset after failover and causes rejections > to be sent unecessarily. > The AMQSession.resubscribe() implementation does not reset the > _highestDeliveryTag member variable. This means that rejects are send > needlessly/incorrectly after failover occurs as the value is higher than it > should be. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5876) Java client causes unecessary rejects after failover when using 0-8..0-9-1 protocols
[ https://issues.apache.org/jira/browse/QPID-5876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14077547#comment-14077547 ] Keith Wall commented on QPID-5876: -- It was decided that we do not wish to introduce the complicate of a fix for QPID-3521 into the scope of 0.30. For this reason, this defect fix has been backed out. > Java client causes unecessary rejects after failover when using 0-8..0-9-1 > protocols > > > Key: QPID-5876 > URL: https://issues.apache.org/jira/browse/QPID-5876 > Project: Qpid > Issue Type: Bug > Components: Java Client >Reporter: Andrew MacBean >Assignee: Keith Wall > > Highest delivery tag variable not reset after failover and causes rejections > to be sent unecessarily. > The AMQSession.resubscribe() implementation does not reset the > _highestDeliveryTag member variable. This means that rejects are send > needlessly/incorrectly after failover occurs as the value is higher than it > should be. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-5876) Java client causes unecessary rejects after failover when using 0-8..0-9-1 protocols
[ https://issues.apache.org/jira/browse/QPID-5876?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14077546#comment-14077546 ] ASF subversion and git services commented on QPID-5876: --- Commit 1614291 from [~k-wall] in branch 'qpid/trunk' [ https://svn.apache.org/r1614291 ] QPID-5876: [Java Client] Highest delivery tag variable not reset after failover and causes rejections to be sent - revert of commit 1607882 > Java client causes unecessary rejects after failover when using 0-8..0-9-1 > protocols > > > Key: QPID-5876 > URL: https://issues.apache.org/jira/browse/QPID-5876 > Project: Qpid > Issue Type: Bug > Components: Java Client >Reporter: Andrew MacBean >Assignee: Keith Wall > Fix For: 0.29 > > > Highest delivery tag variable not reset after failover and causes rejections > to be sent unecessarily. > The AMQSession.resubscribe() implementation does not reset the > _highestDeliveryTag member variable. This means that rejects are send > needlessly/incorrectly after failover occurs as the value is higher than it > should be. -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-5911) Increase default maximum heap size from 1g to 2g
[ https://issues.apache.org/jira/browse/QPID-5911?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew MacBean resolved QPID-5911. -- Resolution: Fixed > Increase default maximum heap size from 1g to 2g > > > Key: QPID-5911 > URL: https://issues.apache.org/jira/browse/QPID-5911 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Assignee: Andrew MacBean > Fix For: 0.29 > > > The Java Broker has shipped with a default maximum heap size (-Xmx) of 1GB > for many years. It has been decided the with the availability of memory in > modern machines, now is the time to increase the default maximum heap size > from 1g to 2g. > The user is still free to use the QPID_JAVA_MEM to override the this value if > the new default does not suit. > http://qpid.apache.org/releases/qpid-trunk/java-broker/book/Java-Broker-Appendix-Environment-Variables.html -- This message was sent by Atlassian JIRA (v6.2#6252) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
