Re: Plans for QMF v1 and v2 (was Re: QMFv2 object update bug [WAS Re: Questions from a novice])
So, the initial thinking for AMQP Management has (finally) now been uploaded so that anyone can see it [1]. As Fraser mentioned, the scope of the AMQP Management work at OASIS is currently purely about mechanism and not defining specific operations / attributes that are available on a managed object. -- Rob [1] https://lists.oasis-open.org/archives/amqp/201305/msg5.html On 7 May 2013 20:18, Fraser Adams fraser.ad...@blueyonder.co.uk wrote: On 06/05/13 12:11, Gordon Sim wrote: For my part, I am in favour of removing QMFv1 support, if necessary providing some sort of adapter or plugin to deal with any use cases for which this might prove problematic. I think QMFv2 is now firmly established as the current management mechanism for the c++ broker. My take on this is that I'm more than happy to see the back of QMF1 but I'd be keen to understand whether or not this results in *breaking changes*. A couple of things I mentioned on the dev group around this point are a) The asynchronous python API - that's where this discussion started the problem is that the callbacks that have actually worked to date work for QMF1, there was a suggestion of an additional objectUpdate() call for QMF2 which is OK as it wouldn't break existing clients as long as QMF1 data was still pushed, but would if it was disabled. Forcing clients to change from statUpdate() and propUpdate() to objectUpdate() (and any changes regression testing that this involves) is clearly a breaking change. Parochially I've only got one tool that uses the async API but I'd prefer it not to be broken (mainly because I wrote it at home for a work use and I'm not responsible for supporting it and I'd end up having to explain the subtleties we're discussing here to someone with a lot less QMF experience than me :'( ). At a push as long as I have decent notice I can rewrite it myself, but others may not have that luxury - as Bill has mentioned previously he's a contractor so when he finishes up his contract and someone else takes over his work they won't have this background and it might silently stop working properly. b) If anyone has been writing Agents using QMF1 then clearly they are likely to break. Parochially this doesn't affect me, but I'm not sure quite how we can gauge how much it may affect others. Perhaps rather like the automake to cmake change we start off by giving gentle nudges then get a bit more forceful, so disabling the QMF1 broker updates as Ken has suggested might be a start (along with some decent documentation and a deprecation notice in the qpidd -h text). I'd personally quite like to see the python async API shim the QMF2 update to make it behave like statUpdate()/propUpdate() though I accept this might be difficult and would have to bow to people who know more about the implementation of this than me. Ultimately I also think we should be starting to think about an AMQP 1.0 based management standard and how we would transition to that. That is however a larger question that shouldn't hold up the immediate decision regarding QMFv1 though it may inform it a little. Yeah I totally agree, I hope that it's not too long before Rob is able to share the draft AMQP 1.0 Management Spec. It'd be good to have a lively discussion about this among a wider group. Rob and I had a couple of decent chats over Easter but I'm keen to start some proper thinking on how we can make this a reality. Unfortunately I suspect that the QMF1/QMF2 quirks are likely to be minor compared to moving to AMQP 1.0 Management, but hopefully not insurmountable, I'm hopeful that it should be possible to shim between ManagementAgent and ManagementNode and vice versa which should help with migration. As we've discussed a pluggable Management layer for the C++ broker would be good, it really helped in the Java broker - I was able to get QMF2 support up and working in a couple of weekends with no prior knowledge of the Java broker code base. rant As an aside the AMQP 1.0 Management specification is only covering the protocol as I understand it, but I'd be quite keen for us to get our act together with respect to APIs. Yes I know it's possible to write QMF2 using the protocol directly, but frankly it's not as interoperable as it might be (C++ binary strings versus UTF8 strings are a personal favourite of mine resulting in byte[] or String respectively in Java - ClassCastException hell :-)). So I think it's useful to have a decent API, however the four or five APIs that we seem to have for QMF is less helpful :-D - can we agree on one when we start looking at AMQP 1.0 Management? /rant :-) Cheers, Frase --**--**- To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.**orgdev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-4591) mechanism to detect when messages are overwritten in ring-type queues
[ https://issues.apache.org/jira/browse/QPID-4591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13655924#comment-13655924 ] Justin Ross commented on QPID-4591: --- An approach currently under review: https://reviews.apache.org/r/11009/ mechanism to detect when messages are overwritten in ring-type queues - Key: QPID-4591 URL: https://issues.apache.org/jira/browse/QPID-4591 Project: Qpid Issue Type: New Feature Components: C++ Broker Affects Versions: 0.18 Reporter: Ernest Allen Fix For: Future A way to determine when a ring queue is full and old messages are being deleted. Also need a way to determine when the ring queue is no longer full. -- 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
RC3: three rare failures
I ran autotools make check 100 times.
In addition to the queue_flow_limit failures that we already know about, I saw
three very-low-frequency failures.
1 cli_tests.CliTests.test_queue_params
1 ha_tests.ReplicationTests.test_priority_ring
1 qpid_tests.broker_0_10.management.ManagementTest.test_connection_stats
1 queue_flow_limit_tests.QueueFlowLimitTests.test_default_flow_count
2 queue_flow_limit_tests.QueueFlowLimitTests.test_blocked_queue_delete
2 queue_flow_limit_tests.QueueFlowLimitTests.test_flow_count
4 queue_flow_limit_tests.QueueFlowLimitTests.test_default_flow_size
10 queue_flow_limit_tests.QueueFlowLimitTests.test_flow_size
here are outputs from the three non-queue_flow_limit failures:
cli_tests.CliTests.test_queue_params fail
Error during teardown: Traceback (most recent call last):
File
/home/mick/qpid-0.22-rc3/cpp/src/tests/python/commands/qpid-python-test, line
340, in run
phase()
File /home/mick/qpid-0.22-rc3/cpp/src/tests/python/qpid/testlib.py, line
229, in tearDown
if not self.session.error(): self.session.close(timeout=10)
File /home/mick/qpid-0.22-rc3/cpp/src/tests/python/qpid/session.py, line
113, in close
raise Timeout()
Timeout
ha_tests.ReplicationTests.test_priority_ring fail
Error during test: Traceback (most recent call last):
File
/home/mick/qpid-0.22-rc3/cpp/src/tests/python/commands/qpid-python-test, line
340, in run
phase()
File /home/mick/qpid-0.22-rc3/cpp/src/tests/ha_tests.py, line 410, in
test_priority_ring
primary.promote()
File /home/mick/qpid-0.22-rc3/cpp/src/tests/ha_test.py, line 102, in
promote
self.ready(); self.qpid_ha([promote])
File /home/mick/qpid-0.22-rc3/cpp/src/tests/ha_test.py, line 202, in ready
return Broker.ready(self, client_properties={qpid.ha-admin:1})
File /home/mick/qpid-0.22-rc3/cpp/src/tests/brokertest.py, line 386, in
ready
Timed out waiting for broker %s%s%(self.name, error_line(self.log,5)))
Exception: Timed out waiting for broker primary:
2013-05-10 11:22:08 [Broker] notice SASL disabled: No Authentication
Performed
2013-05-10 11:22:08 [Network] info Listening to: 0.0.0.0:0
2013-05-10 11:22:08 [Network] info Listening to: [::]:53982
2013-05-10 11:22:08 [HA] notice Shut down
2013-05-10 11:22:08 [Broker] critical Unexpected error: Can't bind to
port [::]:53982: Address already in use (qpid/sys/posix/BSDSocket.cpp:197)
qpid_tests.broker_0_10.management.ManagementTest.test_connection_stats .. fail
Error during test: Traceback (most recent call last):
File
/home/mick/qpid-0.22-rc3/cpp/src/tests/python/commands/qpid-python-test, line
340, in run
phase()
File
/home/mick/qpid-0.22-rc3/tests/src/py/qpid_tests/broker_0_10/management.py,
line 641, in test_connection_stats
assert(conn_qmf)
AssertionError
- Original Message -
From revision 1480717 of the release branch:
http://people.apache.org/~jross/qpid-0.22-rc3/
http://people.apache.org/~jross/qpid-0.22-rc3-testing.txt
My testing on Fedora 16 x86-64 encountered no errors.
This RC has all the updates for stripped spec xml files. Thanks,
Rafi, Robbie, and Alan, for helping to resolve that quickly.
There are still 11 bugs open against 0.21/0.22. At this point I think
they need to get moved out of this release.
http://s.apache.org/qpid-0.22-open-bugs
I'd like to call a vote for release in about a week if no new blocking
issues arise, so please provide any feedback you have sooner than
later. Many thanks to those who have tested and reported their
results.
Justin
---
0.22 release page: https://cwiki.apache.org/qpid/022-release.html
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-4834) Ruby client examples incorrectly handles '--connection-options' option
Petr Matousek created QPID-4834:
---
Summary: Ruby client examples incorrectly handles
'--connection-options' option
Key: QPID-4834
URL: https://issues.apache.org/jira/browse/QPID-4834
Project: Qpid
Issue Type: Bug
Components: Ruby Client
Affects Versions: 0.20
Reporter: Petr Matousek
Priority: Minor
The 'connection-options' option is incorrectly handled as a string in the
example clients, should be handled as a list.
# ruby spout.rb --connection-options {reconnect:True} q;{create:always}
2013-05-10 04:49:01 [Client] warning Exception received from broker:
not-found: not-found: Queue not found: {reconnect:True}
(/builddir/build/BUILD/qpid-0.22/cpp/src/qpid/broker/SessionAdapter.cpp:693)
[caused by 2 \x08:\x01]
./../lib/qpid_messaging/session.rb:63:in `createSender': Queue
{reconnect:True} does not exist (MessagingError)
from ./../lib/qpid_messaging/session.rb:63:in `create_sender'
from spout.rb:106
2013-05-10 04:49:01 [Client] warning Connection
[127.0.0.1:56869-127.0.0.1:5672] closed
The 'nil' in the option parser looked weird to me, so I did the
following change to make the option work:
# vim spout.rb
- opts.on(nil, --connection-options VALUE,
+ opts.on(--connection-options VALUE,
Following change results in another error, the connection's
convert_options method expects list not a string:
# ruby spout.rb --connection-options {reconnect:True} q;{create:always}
./../lib/qpid_messaging/connection.rb:149:in `convert_options':
undefined method `each_pair' for {reconnect:True}:String
(NoMethodError)
from ./../lib/qpid_messaging/connection.rb:67:in `initialize'
from spout.rb:103:in `new'
from spout.rb:103
I used the following code to fix the issue, which was sufficient for
my needs (there would be probably a better solution, I guess):
-options[:connection_options] = conopts
+options[:connection_options] = {}
+conopts = conopts.gsub /^\{(.*)\}$/, '\1'
+conopts.split(,).each do |x|
+ key,val = x.split(':')
+ options[:connection_options][key]= val
Packages used:
ruby gem: qpid_messaging-0.20.2
also valid for examples on trunk
--
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-4835) JMS client is unable to read the application headers of messages sent by the ruby clients
Petr Matousek created QPID-4835: --- Summary: JMS client is unable to read the application headers of messages sent by the ruby clients Key: QPID-4835 URL: https://issues.apache.org/jira/browse/QPID-4835 Project: Qpid Issue Type: Bug Components: Ruby Client Affects Versions: 0.20 Reporter: Petr Matousek I was unable to read the application headers of messages sent by the ruby example client (spout) using the JMS example client. ie. # cd /usr/lib/ruby/gems/1.8/gems/qpid_messaging-0.20.2/examples # ruby spout.rb -P foo=bar q # cd /usr/share/doc/qpid-java-0.22/examples # ./run_example.sh org.apache.qpid.example.Drain q | grep Properties Properties:NONE Properties of the received message shall list 'foo = bar'. note: JMS client can read application headers of messages sent by c++/python. packages used: ruby gem: qpid_messaging-0.20.2 java Drain example from qpid-0.22 -- 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-4835) JMS client is unable to read the application headers of messages sent by the ruby clients
[ https://issues.apache.org/jira/browse/QPID-4835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross updated QPID-4835: -- Assignee: Darryl L. Pierce JMS client is unable to read the application headers of messages sent by the ruby clients - Key: QPID-4835 URL: https://issues.apache.org/jira/browse/QPID-4835 Project: Qpid Issue Type: Bug Components: Ruby Client Affects Versions: 0.20 Reporter: Petr Matousek Assignee: Darryl L. Pierce I was unable to read the application headers of messages sent by the ruby example client (spout) using the JMS example client. ie. # cd /usr/lib/ruby/gems/1.8/gems/qpid_messaging-0.20.2/examples # ruby spout.rb -P foo=bar q # cd /usr/share/doc/qpid-java-0.22/examples # ./run_example.sh org.apache.qpid.example.Drain q | grep Properties Properties:NONE Properties of the received message shall list 'foo = bar'. note: JMS client can read application headers of messages sent by c++/python. packages used: ruby gem: qpid_messaging-0.20.2 java Drain example from qpid-0.22 -- 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-4834) Ruby client examples incorrectly handles '--connection-options' option
[
https://issues.apache.org/jira/browse/QPID-4834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross updated QPID-4834:
--
Assignee: Darryl L. Pierce
Ruby client examples incorrectly handles '--connection-options' option
--
Key: QPID-4834
URL: https://issues.apache.org/jira/browse/QPID-4834
Project: Qpid
Issue Type: Bug
Components: Ruby Client
Affects Versions: 0.20
Reporter: Petr Matousek
Assignee: Darryl L. Pierce
Priority: Minor
The 'connection-options' option is incorrectly handled as a string in the
example clients, should be handled as a list.
# ruby spout.rb --connection-options {reconnect:True} q;{create:always}
2013-05-10 04:49:01 [Client] warning Exception received from broker:
not-found: not-found: Queue not found: {reconnect:True}
(/builddir/build/BUILD/qpid-0.22/cpp/src/qpid/broker/SessionAdapter.cpp:693)
[caused by 2 \x08:\x01]
./../lib/qpid_messaging/session.rb:63:in `createSender': Queue
{reconnect:True} does not exist (MessagingError)
from ./../lib/qpid_messaging/session.rb:63:in `create_sender'
from spout.rb:106
2013-05-10 04:49:01 [Client] warning Connection
[127.0.0.1:56869-127.0.0.1:5672] closed
The 'nil' in the option parser looked weird to me, so I did the
following change to make the option work:
# vim spout.rb
- opts.on(nil, --connection-options VALUE,
+ opts.on(--connection-options VALUE,
Following change results in another error, the connection's
convert_options method expects list not a string:
# ruby spout.rb --connection-options {reconnect:True} q;{create:always}
./../lib/qpid_messaging/connection.rb:149:in `convert_options':
undefined method `each_pair' for {reconnect:True}:String
(NoMethodError)
from ./../lib/qpid_messaging/connection.rb:67:in `initialize'
from spout.rb:103:in `new'
from spout.rb:103
I used the following code to fix the issue, which was sufficient for
my needs (there would be probably a better solution, I guess):
-options[:connection_options] = conopts
+options[:connection_options] = {}
+conopts = conopts.gsub /^\{(.*)\}$/, '\1'
+conopts.split(,).each do |x|
+ key,val = x.split(':')
+ options[:connection_options][key]= val
Packages used:
ruby gem: qpid_messaging-0.20.2
also valid for examples on trunk
--
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: Review Request: Address deadlock btw _messageDeliveryLock and _failoverMutex
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10738/#review20483 --- http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQConnection.java https://reviews.apache.org/r/10738/#comment42204 Whitespace http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQConnection.java https://reviews.apache.org/r/10738/#comment42205 Whitespace http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession.java https://reviews.apache.org/r/10738/#comment42206 Unused http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession.java https://reviews.apache.org/r/10738/#comment42207 Might be better called 'waitForInProgressDeliveryToComplete' as it doesn't actually wait for all message delivery to finish (although that might be the case, depending on other factors outside its control) but rather any that is already in progress to complete. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession.java https://reviews.apache.org/r/10738/#comment42210 We should hold the object lock while performing the check, otherwise we could go into the wait() after the only notify() that could wake us has already been performed. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession.java https://reviews.apache.org/r/10738/#comment42211 We probably shouldn't catch all exceptions, or eat the interrupted status. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession.java https://reviews.apache.org/r/10738/#comment42212 Linked to earlier comment, we need to hold the object lock while performing the update or we could potentially notify() before they call wait(), which might mean they never wake up. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession.java https://reviews.apache.org/r/10738/#comment42213 We probably shouldn't catch all exceptions, or eat the interrupted status. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/BasicMessageConsumer.java https://reviews.apache.org/r/10738/#comment42216 This and all the code that uses it seems to duplicate the code added in AMQSession. It seems like this stuff could go in a utility class to avoid the duplication, which would also permit easy addition of some unit tests. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/BasicMessageConsumer.java https://reviews.apache.org/r/10738/#comment42217 Removal of this usage of the old lock will cause a fair shift in client behaviour, allowing the consumer close to proceed at the same time as message delivery is ongoing on the session, possibly entailing things such as the Dispatcher performing a session rollback in a message listener while this close is in progress. How clear are we on what impact this change has on the client? For example, this lock usage was apparently added specifically to prevent a deadlock in that sort of situation. Has your investigation of this change in behaviour determined whether that would become a problem again? http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/BasicMessageConsumer.java https://reviews.apache.org/r/10738/#comment42218 What impact does dropping the message on the floor here have on the client? Earlier points in the call hierarchy seem to make effort to do other things with the message when detecting session/consumer close, so is there any impact from not doing so? E.g a message getting stuck acquired for a now-closed consumer? Does any particular attention need paid to the overridden 0-10 specific version of this method? http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/BasicMessageConsumer.java https://reviews.apache.org/r/10738/#comment42219 Same comments as earlier about thread safety, exception handling, and reuse. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/BasicMessageConsumer.java https://reviews.apache.org/r/10738/#comment42220 Same comments as earlier about method name, thread safety, exception handling, and reuse. http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/configuration/ClientProperties.java https://reviews.apache.org/r/10738/#comment42214 Effectively unused - Robbie Gemmell On May 8, 2013, 2:02 p.m., rajith attapattu
[jira] [Created] (QPID-4836) Add design guidelines to project etiquette html page
Philip Harvey created QPID-4836: --- Summary: Add design guidelines to project etiquette html page Key: QPID-4836 URL: https://issues.apache.org/jira/browse/QPID-4836 Project: Qpid Issue Type: Task Components: Documentation Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor On a number of occasions, I've been involved in Qpid changes that have required rework because certain aspects of the design were not considered early on. To mitigate this, I'd like to add a Design Checklist to the Qpid web site that we can all refer to, either when designing features or reviewing other people's changes. I'd like to re-purpose http://qpid.apache.org/qpid_project_etiquette_guide.html to include this information, probably renaming it to something like Qpid Project Developers Guide. -- 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-4836) Add design guidelines to project etiquette html page
[ https://issues.apache.org/jira/browse/QPID-4836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philip Harvey updated QPID-4836: Attachment: QPID-4836-design-guidelines.patch attached patch for review Add design guidelines to project etiquette html page Key: QPID-4836 URL: https://issues.apache.org/jira/browse/QPID-4836 Project: Qpid Issue Type: Task Components: Documentation Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Attachments: QPID-4836-design-guidelines.patch On a number of occasions, I've been involved in Qpid changes that have required rework because certain aspects of the design were not considered early on. To mitigate this, I'd like to add a Design Checklist to the Qpid web site that we can all refer to, either when designing features or reviewing other people's changes. I'd like to re-purpose http://qpid.apache.org/qpid_project_etiquette_guide.html to include this information, probably renaming it to something like Qpid Project Developers Guide. -- 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-4836) Add design guidelines to project etiquette html page
[ https://issues.apache.org/jira/browse/QPID-4836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13656125#comment-13656125 ] Justin Ross commented on QPID-4836: --- Right now I have the new proposed website pointing at the wiki version of this: https://cwiki.apache.org/qpid/qpid-project-etiquette-guide.html I thought that was a more appropriate place to keep developer guidelines. I'm not really wed to one or another location, but we should try to focus our attention on just one, I figure. Add design guidelines to project etiquette html page Key: QPID-4836 URL: https://issues.apache.org/jira/browse/QPID-4836 Project: Qpid Issue Type: Task Components: Documentation Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Attachments: QPID-4836-design-guidelines.patch On a number of occasions, I've been involved in Qpid changes that have required rework because certain aspects of the design were not considered early on. To mitigate this, I'd like to add a Design Checklist to the Qpid web site that we can all refer to, either when designing features or reviewing other people's changes. I'd like to re-purpose http://qpid.apache.org/qpid_project_etiquette_guide.html to include this information, probably renaming it to something like Qpid Project Developers Guide. -- 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: RC3: three rare failures
This looks very familiar to the queue_flow failures - the session setup by the test becomes invalid and operations fail. cli_tests.CliTests.test_queue_params fail Error during teardown: Traceback (most recent call last): File /home/mick/qpid-0.22-rc3/cpp/src/tests/python/commands/qpid-python-test, line 340, in run phase() File /home/mick/qpid-0.22-rc3/cpp/src/tests/python/qpid/testlib.py, line 229, in tearDown if not self.session.error(): self.session.close(timeout=10) File /home/mick/qpid-0.22-rc3/cpp/src/tests/python/qpid/session.py, line 113, in close raise Timeout() Timeout - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-4781) cmake build of perl bindings fails in RC2
[ https://issues.apache.org/jira/browse/QPID-4781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce resolved QPID-4781. Resolution: Fixed Fix Version/s: 0.23 Assignee: Darryl L. Pierce cmake build of perl bindings fails in RC2 - Key: QPID-4781 URL: https://issues.apache.org/jira/browse/QPID-4781 Project: Qpid Issue Type: Bug Components: Perl Client Affects Versions: 0.22 Environment: RHEL5 Reporter: Jimmy Jones Assignee: Darryl L. Pierce Fix For: 0.23 Running cmake .. make make install -- Installing: /usr/local/etc/qpid/qpidd.conf CMake Error at bindings/qpid/perl/cmake_install.cmake:36 (FILE): file INSTALL cannot find file /home/test/qpid-0.22-rc2/cpp/bld/bindings/qpid/perl/libcqpid_perl.so to install. Call Stack (most recent call first): bindings/cmake_install.cmake:37 (INCLUDE) cmake_install.cmake:63 (INCLUDE) make: *** [install] Error 1 The library in that directory is cqpid_perl.so, not libcqpid_perl.so -- 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-4781) cmake build of perl bindings fails in RC2
[ https://issues.apache.org/jira/browse/QPID-4781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13656270#comment-13656270 ] Darryl L. Pierce commented on QPID-4781: There's a fix for a similar issue regarding the Ruby language bindings. For Cmake earlier than 2.8 the produced file is missing the lib prefix. So I copied that fix over to the Perl bindings as well. So now it will be sure that the file installed is named cqpid_perl.so, which is what the bindings expect. This commit can be found here: http://svn.apache.org/viewvc?view=revisionrevision=1482038 cmake build of perl bindings fails in RC2 - Key: QPID-4781 URL: https://issues.apache.org/jira/browse/QPID-4781 Project: Qpid Issue Type: Bug Components: Perl Client Affects Versions: 0.22 Environment: RHEL5 Reporter: Jimmy Jones Assignee: Darryl L. Pierce Fix For: 0.23 Running cmake .. make make install -- Installing: /usr/local/etc/qpid/qpidd.conf CMake Error at bindings/qpid/perl/cmake_install.cmake:36 (FILE): file INSTALL cannot find file /home/test/qpid-0.22-rc2/cpp/bld/bindings/qpid/perl/libcqpid_perl.so to install. Call Stack (most recent call first): bindings/cmake_install.cmake:37 (INCLUDE) cmake_install.cmake:63 (INCLUDE) make: *** [install] Error 1 The library in that directory is cqpid_perl.so, not libcqpid_perl.so -- 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
0.22 Request For Inclusion: QPID-4781
QPID-4781: cmake build of perl bindings fails in RC2 Added a fix in the CMakeLists.txt file to properly installed the Perl bindings library based on which version of Cmake is being used. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpfk04bjLFOr.pgp Description: PGP signature
Re: Remaining perl bindings issues in RC3
On Fri, May 10, 2013 at 05:42:10PM +0200, Jimmy Jones wrote: Hi, Done some more testing of RC3, and unfortunatly its still not possible to build the perl bindings. The outstanding issues: * QPID-4781 cmake build of perl bindings fails in RC2 - confusion between cqpid_perl.so and libcqpid_perl.so in install This is fixed, tested and pushed to master. I put in a request for inclusion for it today. * QPID-4724 qpid-cpp-0.22-rc1 RHEL6 cmake issues - approved for 0.22 but not in RC3 Sorry, thought this was pulled into the 0.22 branch. It's there now. * QPID-4828 qpid-cpp-0.22-rc3 RHEL5 cmake issues - same as the above, but for RHEL5 - doesn't auto detect perl paths Hrm, so this really isn't a build issue per se; i.e., there's nothing we can do in our build environment to overcome the issue? Should this be included as a release note for RHEL5 builds? * QPID-4770 Perl bindings don't build from qpid-0.22-rc2.tar.gz - an automake failure, i guess not so important as deprected * QPID-4719 Problem building perl bindings from qpid 0.22 RC1 tarball - fixup to Makefile.am EXTRA_DIST to include missing files, not approved for 0.22? This last one has an outstanding request for inclusion on it. Justin: Can you take a look at the two RFIs? I'd say if the first two are the most important for 0.22, without them the bindings aren't usable on RHEL5/6 in my testing. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpgA1O8ahiY3.pgp Description: PGP signature
Re: Review Request: Address deadlock btw _messageDeliveryLock and _failoverMutex
On May 13, 2013, 3:22 p.m., Robbie Gemmell wrote: http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession.java, lines 255-256 https://reviews.apache.org/r/10738/diff/2/?file=288992#file288992line255 Unused Will mark for removal. On May 13, 2013, 3:22 p.m., Robbie Gemmell wrote: http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession.java, line 750 https://reviews.apache.org/r/10738/diff/2/?file=288992#file288992line750 Might be better called 'waitForInProgressDeliveryToComplete' as it doesn't actually wait for all message delivery to finish (although that might be the case, depending on other factors outside its control) but rather any that is already in progress to complete. Make sense, I will make that change. On May 13, 2013, 3:22 p.m., Robbie Gemmell wrote: http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession.java, lines 758-766 https://reviews.apache.org/r/10738/diff/2/?file=288992#file288992line758 We should hold the object lock while performing the check, otherwise we could go into the wait() after the only notify() that could wake us has already been performed. Good catch! On May 13, 2013, 3:22 p.m., Robbie Gemmell wrote: http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession.java, line 767 https://reviews.apache.org/r/10738/diff/2/?file=288992#file288992line767 We probably shouldn't catch all exceptions, or eat the interrupted status. For starters I will narrow it down to interrupted exception and then log it. On May 13, 2013, 3:22 p.m., Robbie Gemmell wrote: http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession.java, lines 3339-3347 https://reviews.apache.org/r/10738/diff/2/?file=288992#file288992line3339 Linked to earlier comment, we need to hold the object lock while performing the update or we could potentially notify() before they call wait(), which might mean they never wake up. Will fix this On May 13, 2013, 3:22 p.m., Robbie Gemmell wrote: http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/BasicMessageConsumer.java, line 137 https://reviews.apache.org/r/10738/diff/2/?file=288993#file288993line137 This and all the code that uses it seems to duplicate the code added in AMQSession. It seems like this stuff could go in a utility class to avoid the duplication, which would also permit easy addition of some unit tests. Sure, will do that. On May 13, 2013, 3:22 p.m., Robbie Gemmell wrote: http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/BasicMessageConsumer.java, lines 771-785 https://reviews.apache.org/r/10738/diff/2/?file=288993#file288993line771 Same comments as earlier about thread safety, exception handling, and reuse. Will be addressed in next rev. On May 13, 2013, 3:22 p.m., Robbie Gemmell wrote: http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/BasicMessageConsumer.java, lines 1059-1082 https://reviews.apache.org/r/10738/diff/2/?file=288993#file288993line1059 Same comments as earlier about method name, thread safety, exception handling, and reuse. Will be addresed in next rev. On May 13, 2013, 3:22 p.m., Robbie Gemmell wrote: http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQConnection.java, line 873 https://reviews.apache.org/r/10738/diff/2/?file=288991#file288991line873 Whitespace Will fix this. Can't see this in my git patch. (The diff for RB is created from my svn checkout, as RB doesn't like the git formatted patch). Will double check all whitespace issues before I commit. On May 13, 2013, 3:22 p.m., Robbie Gemmell wrote: http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/BasicMessageConsumer.java, lines 744-745 https://reviews.apache.org/r/10738/diff/2/?file=288993#file288993line744 What impact does dropping the message on the floor here have on the client? Earlier points in the call hierarchy seem to make effort to do other things with the message when detecting session/consumer close, so is there any impact from not doing so? E.g a message getting stuck acquired for a now-closed consumer? Does any particular attention need paid to the overridden 0-10 specific version of this method? The message will be dropped if a consumer (or session is closed or closing). When a consumer is closed, any messages acquired but not acknowledged should be be made available to another consumer by the broker. These messages will be marked
Re: Review Request: Address deadlock btw _messageDeliveryLock and _failoverMutex
On May 13, 2013, 3:22 p.m., Robbie Gemmell wrote: http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession.java, line 767 https://reviews.apache.org/r/10738/diff/2/?file=288992#file288992line767 We probably shouldn't catch all exceptions, or eat the interrupted status. rajith attapattu wrote: For starters I will narrow it down to interrupted exception and then log it. I meant catch the interrupted exception only and ignore. Even if the thread was woken up prematurely, it will go back to waiting if the variable isn't set. - rajith --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10738/#review20483 --- On May 8, 2013, 2:02 p.m., rajith attapattu wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/10738/ --- (Updated May 8, 2013, 2:02 p.m.) Review request for qpid, Robbie Gemmell, Weston Price, and Rob Godfrey. Description --- There are at least 3 cases where the deadlock btw _messageDeliveryLock and _failoverMutex surfaces. Among them sending a message inside onMessage() and the session being closed due to an error (causing the deadlock) seems to come up a lot in production environments. There is also a deadlock btw _messageDeliveryLock and _lock (AMQSession.java) which happens less frequently. The messageDeliveryLock is used to ensure that we don't close the session in the middle of a message delivery. In order to do this we hold the lock across onMessage(). This causes several issues in addition to the potential to deadlock. If an onMessage call takes longer/wedged then you cannot close the session or failover will not happen until it returns as the same thread is holding the failoverMutex. Based on an idea from Rafi, I have come up with a solution to get rid of _messageDeliveryLock and instead use an alternative strategy to achieve similar functionality. In order to ensure that close() doesn't proceed until the message deliveries currently in progress completes, an atomic counter is used to keep track of message deliveries in progress. The close() will wait until the count falls to zero before proceeding. No new deliveries will be initiated bcos the close method will mark the session as closed. The wait has a timeout to ensure that a longer running or wedged onMessage() will not hold up session close. There is a slim chance that before a session being marked as closed a message delivery could be initiated, but not yet gotten to the point of updating the counter, hence waitForMsgDeliveryToFinish() will see it as zero and proceed with close. But in comparison to the issues with _messageDeliveryLock, I believe it's acceptable. There is an issue if MessageConsumer close is called outside of Session close. This can be solved in a similar manner. I will wait until the current review is complete and then post the solution for the MessageConsumer close. I will commit them both together. This addresses bug QPID-4574. https://issues.apache.org/jira/browse/QPID-4574 Diffs - http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQConnection.java 1480271 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession.java 1480271 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/BasicMessageConsumer.java 1480271 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/configuration/ClientProperties.java 1480271 Diff: https://reviews.apache.org/r/10738/diff/ Testing --- Java test suite, tests from customers and QE around the deadlock situation. Thanks, rajith attapattu
[jira] [Commented] (QPID-3760) Unable to use address strings with java client due to NPE
[
https://issues.apache.org/jira/browse/QPID-3760?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13656830#comment-13656830
]
Pavel Moravec commented on QPID-3760:
-
This is a duplicate of https://issues.apache.org/jira/browse/QPID-3769, fixed
in 0.22.
Unable to use address strings with java client due to NPE
-
Key: QPID-3760
URL: https://issues.apache.org/jira/browse/QPID-3760
Project: Qpid
Issue Type: Bug
Components: Java Client
Affects Versions: 0.10
Reporter: Sergey Zhemzhitsky
Labels: addressing
Stacktrace:
{code}
Exception in thread Thread-5 java.lang.NullPointerException
at org.apache.qpid.client.AMQDestination.equals(AMQDestination.java:577)
at
org.springframework.jms.connection.CachingConnectionFactory$DestinationCacheKey.destinationEquals(CachingConnectionFactory.java:467)
at
org.springframework.jms.connection.CachingConnectionFactory$DestinationCacheKey.equals(CachingConnectionFactory.java:474)
at java.util.HashMap.get(HashMap.java:385)
at
org.springframework.jms.connection.CachingConnectionFactory$CachedSessionInvocationHandler.getCachedProducer(CachingConnectionFactory.java:353)
at
org.springframework.jms.connection.CachingConnectionFactory$CachedSessionInvocationHandler.invoke(CachingConnectionFactory.java:320)
at $Proxy1.createProducer(Unknown Source)
{code}
Exception happens for the following address:
{code}
JbenchQueue;{create: always, node: {type:queue}}
{code}
It seems the qpid java client tries to obtain exchangeClass property in
AMQDestination.equals method, but this property is not set when using address
strings.
--
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
