Re: 0.12 release update - upcoming dates
Hi, Steve. Sorry for the late reply. I'm close to cutting the alpha now, and it doesn't look like your change has landed. I took a look at the jira, however, and it looks to me like something we could accept up to beta. Justin - Original Message - From: Steve Huston shus...@riverace.com To: dev@qpid.apache.org Sent: Thursday, June 16, 2011 7:45:12 PM Subject: RE: 0.12 release update - upcoming dates Justin, I'm trying to land the fix for QPID-3256 - there are a few review comments outstanding, but so far nothing major. The original problem reporter has already verified the patch fixes the original problem. Ok to get this in tomorrow? If needed I can try to get it in today but I'd rather work the review comments with more deliberation. Thanks, -Steve -- Steve Huston, Riverace Corporation Total Lifecycle Support for Your Networked Applications http://www.riverace.com -Original Message- From: Justin Ross [mailto:jr...@redhat.com] Sent: Tuesday, June 14, 2011 10:47 AM To: dev@qpid.apache.org Subject: Re: 0.12 release update - upcoming dates I agree, and that's why I prefer to set the deadlines to the middle of the week. That way if we slip a little, there's still a chance we'll get it that week and not the next. Rajith (or anyone else facing a similar problem), are the changes you'd like to see in 0.12 looking like they will land by end of day Wednesday? Just so I can determine when we can accept it, what's the new feature and what is its current status? Justin - Original Message - From: Aidan Skinner aidan.skin...@gmail.com To: dev@qpid.apache.org Sent: Friday, June 3, 2011 1:43:45 AM Subject: Re: 0.12 release update - upcoming dates I'm really only passing through qpid-dev, so feel free to ignore me, but IME Friday deadlines turn into Monday deadlines turn into Wednesday the week after deadlines all too easily. - Aidan On Thu, Jun 2, 2011 at 2:21 PM, Rajith Attapattu rajit...@gmail.com wrote: Justin, Wondering if you could move the beta date to 17th of June (friday) instead of the 15th? Regards, Rajith On Tue, May 31, 2011 at 5:19 PM, Justin Ross jr...@redhat.com wrote: Hi, folks. Here are some of the upcoming dates for the 0.12 release of Qpid. - 3 March - 0.12 trunk opened - 15 June - 0.12 alpha (in a little over 2 weeks) - 28 June - 0.12 beta - 27 July - Target date for the final 0.12 release candidate The alpha date is the deadline for landing major features. Said features must be functionally complete, with all distribution-related integration complete. After the alpha, we may still be able to accept a new feature, but it must be something (a) quite small or (b) isolated from the other code. In addition, it must not change the existing distribution artifacts in any significant way. With the beta, we will create the 0.12 release branch, and 0.14 development can then begin on trunk. The release page[1] has links to the jiras for 0.12 and an overview of the schedule. Thanks! Justin --- [1] https://cwiki.apache.org/confluence/display/qpid/0.12+Release - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org -- Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org A witty saying proves nothing - Voltaire - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Updated] (QPID-3307) ClassNotfound Exception when using Qpid java client in Complex classloading Environments.
[ https://issues.apache.org/jira/browse/QPID-3307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Charith Dhanushka Wickramarachchi updated QPID-3307: Attachment: QPID-3307_patch_unit_test.txt Hi , I'm attaching an unit test case which will send receive an Object Message which have a custom Serializable Type inside.In that case the ObjectInputStream i have provided will be used. To re-create the exact class loading scenario I'll have to find a way to simulate that kind of class loading environment within the Unit test. I'll have to think through it on how to implement that. thanks, Charith ClassNotfound Exception when using Qpid java client in Complex classloading Environments. --- Key: QPID-3307 URL: https://issues.apache.org/jira/browse/QPID-3307 Project: Qpid Issue Type: Bug Components: Java Client Reporter: Charith Dhanushka Wickramarachchi Priority: Critical Attachments: QPID-3307_patch.txt, QPID-3307_patch.txt, QPID-3307_patch.txt, QPID-3307_patch_unit_test.txt Hi , When we are using qpid client to receive JMSObject in complex class loading environments like web application containers/Osgi environments .There is a scenario where this issues comes. Scenario. In a web application container normally they use a class loader per web app. and if we have qpid client libs at the root classloader level this error can come. The reason for this is Serializable Object types that are used inside the web app are not visible to the class loader that loads the JMSObject message and unmarshall it. thanks, Charith -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Created] (QPID-3312) Console throws unhandled exception when the broker shuts down/restarts
Console throws unhandled exception when the broker shuts down/restarts -- Key: QPID-3312 URL: https://issues.apache.org/jira/browse/QPID-3312 Project: Qpid Issue Type: Bug Components: Dot Net Client Affects Versions: 0.10 Environment: Windows 7 Reporter: Ricardo Pereira moura Fix For: 0.10 When the broker shuts down or restarts the dotnet Qpid Console (version 0.10) throws an unhandled exception: Log Name: Application Source:.NET Runtime Date: 19-06-2011 13:23:26 Event ID: 1026 Task Category: None Level: Error Keywords: Classic User: N/A Computer: XXX Description: Application: XXX.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: org.apache.qpid.transport.SessionClosedException Stack: at org.apache.qpid.transport.Session.Invoke(org.apache.qpid.transport.Method) at org.apache.qpid.transport.Invoker.MessageStop(System.String, org.apache.qpid.transport.Option[]) at org.apache.qpid.console.Broker.Shutdown() at org.apache.qpid.console.Broker.Finalize() Event Xml: Event xmlns=http://schemas.microsoft.com/win/2004/08/events/event; System Provider Name=.NET Runtime / EventID Qualifiers=01026/EventID Level2/Level Task0/Task Keywords0x80/Keywords TimeCreated SystemTime=2011-06-19T12:23:26.0Z / EventRecordID20215/EventRecordID ChannelApplication/Channel ComputerXXX/Computer Security / /System EventData DataApplication: XXX.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: org.apache.qpid.transport.SessionClosedException Stack: at org.apache.qpid.transport.Session.Invoke(org.apache.qpid.transport.Method) at org.apache.qpid.transport.Invoker.MessageStop(System.String, org.apache.qpid.transport.Option[]) at org.apache.qpid.console.Broker.Shutdown() at org.apache.qpid.console.Broker.Finalize() /Data /EventData /Event -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: 0.12 release update - upcoming dates
Ok, thanks Justin. The review process picked up some problems and I understand Cliff Jansen is working on these. For some odd reason I'm not seeing Cliff's review updates though. -- Steve Huston, Riverace Corporation Total Lifecycle Support for Your Networked Applications http://www.riverace.com -Original Message- From: Justin Ross [mailto:jr...@redhat.com] Sent: Monday, June 20, 2011 4:38 AM To: dev@qpid.apache.org Subject: Re: 0.12 release update - upcoming dates Hi, Steve. Sorry for the late reply. I'm close to cutting the alpha now, and it doesn't look like your change has landed. I took a look at the jira, however, and it looks to me like something we could accept up to beta. Justin - Original Message - From: Steve Huston shus...@riverace.com To: dev@qpid.apache.org Sent: Thursday, June 16, 2011 7:45:12 PM Subject: RE: 0.12 release update - upcoming dates Justin, I'm trying to land the fix for QPID-3256 - there are a few review comments outstanding, but so far nothing major. The original problem reporter has already verified the patch fixes the original problem. Ok to get this in tomorrow? If needed I can try to get it in today but I'd rather work the review comments with more deliberation. Thanks, -Steve -- Steve Huston, Riverace Corporation Total Lifecycle Support for Your Networked Applications http://www.riverace.com -Original Message- From: Justin Ross [mailto:jr...@redhat.com] Sent: Tuesday, June 14, 2011 10:47 AM To: dev@qpid.apache.org Subject: Re: 0.12 release update - upcoming dates I agree, and that's why I prefer to set the deadlines to the middle of the week. That way if we slip a little, there's still a chance we'll get it that week and not the next. Rajith (or anyone else facing a similar problem), are the changes you'd like to see in 0.12 looking like they will land by end of day Wednesday? Just so I can determine when we can accept it, what's the new feature and what is its current status? Justin - Original Message - From: Aidan Skinner aidan.skin...@gmail.com To: dev@qpid.apache.org Sent: Friday, June 3, 2011 1:43:45 AM Subject: Re: 0.12 release update - upcoming dates I'm really only passing through qpid-dev, so feel free to ignore me, but IME Friday deadlines turn into Monday deadlines turn into Wednesday the week after deadlines all too easily. - Aidan On Thu, Jun 2, 2011 at 2:21 PM, Rajith Attapattu rajit...@gmail.com wrote: Justin, Wondering if you could move the beta date to 17th of June (friday) instead of the 15th? Regards, Rajith On Tue, May 31, 2011 at 5:19 PM, Justin Ross jr...@redhat.com wrote: Hi, folks. Here are some of the upcoming dates for the 0.12 release of Qpid. - 3 March - 0.12 trunk opened - 15 June - 0.12 alpha (in a little over 2 weeks) - 28 June - 0.12 beta - 27 July - Target date for the final 0.12 release candidate The alpha date is the deadline for landing major features. Said features must be functionally complete, with all distribution-related integration complete. After the alpha, we may still be able to accept a new feature, but it must be something (a) quite small or (b) isolated from the other code. In addition, it must not change the existing distribution artifacts in any significant way. With the beta, we will create the 0.12 release branch, and 0.14 development can then begin on trunk. The release page[1] has links to the jiras for 0.12 and an overview of the schedule. Thanks! Justin --- [1] https://cwiki.apache.org/confluence/display/qpid/0.12+Release - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org -- Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org A witty saying proves nothing - Voltaire - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact:
[jira] [Resolved] (QPID-3129) cluster_tests.LongTests.test_failover hangs
[ https://issues.apache.org/jira/browse/QPID-3129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway resolved QPID-3129. --- Resolution: Fixed Fixed on trunk r1137657 cluster_tests.LongTests.test_failover hangs Key: QPID-3129 URL: https://issues.apache.org/jira/browse/QPID-3129 Project: Qpid Issue Type: Bug Components: C++ Clustering Affects Versions: 0.9 Reporter: Alan Conway Assignee: Alan Conway Priority: Minor Fix For: 0.11 The test cluster_tests.LongTests.test_failover hangs if run with duration of a minute or more. To reproduce: make check TESTS=run_cluster_tests CLUSTER_TESTS='cluster_tests.LongTests.test_failover -DDURATION=1' Should pass after about 1 minute, but hangs indefinitely. This is probably a test bug. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Qpid python bindings for windows
Hi guys, We need to stand up a windows proxy, in the cloud backend, so that the proxy can use local authentication to the booting instance. We want to control the proxy via qpid/qmf, to pass commands down to it and get results back. For that we want to use Python, so the question is: are there any qpid bindings for python that would work in windows? Thank you. Ovi - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Review Request: QPID-3265 Can't subscribe to headers exchange using address (rather than BURL)
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/937/ --- Review request for qpid. Summary --- The patch makes the following changes 1. AMQSession_0_10.java A default binding is only added if there are no explicit bindings specified via x-bindings 2. BasicMessageConsumer_0_10.java When the same destination (Topic) is used to create two different consumers the code creates a copy of the destination to ensure the second consumer gets it's own unique temp queue. When doing so we need to ensure we delete any bindings for the previous temp queue. If we don't remove old bindings and if there were no explicit bindings specified via x-bindings, then the second consumers queue will not be bound due to the logic mentioned in [1]. (Bcos the previous binding is treated as explicit bindings). 3. AddressHelper.java The second part of the JIRA covers a different bug - i.e x-binding specified in the link properties are not used if the node type if a queue. I added code to read the x-bindings in link props if there are no x-bindings specified in the node props. 4. Modified test cases 1. To ensure that a default binding is not added when explicit bindings are specified. 2. To fix an existing test case that relied on a default binding even when x-bindings is specified. (*) I still need to add (or modify an existing test case) to cover the case where x-bindings are specified in link props when the node type if a queue. This addresses bug QPID-3265. https://issues.apache.org/jira/browse/QPID-3265 Diffs - http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession_0_10.java 1137691 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/BasicMessageConsumer_0_10.java 1137691 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/messaging/address/AddressHelper.java 1137691 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client/destination/AddressBasedDestinationTest.java 1137691 Diff: https://reviews.apache.org/r/937/diff Testing --- The use cases specified in the JIRA were manually tested in addition to the above mentioned automated test cases. Thanks, rajith
[jira] [Commented] (QPID-3265) Can't subscribe to headers exchange using address (rather than BURL)
[ https://issues.apache.org/jira/browse/QPID-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13052089#comment-13052089 ] jirapos...@reviews.apache.org commented on QPID-3265: - --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/937/ --- Review request for qpid. Summary --- The patch makes the following changes 1. AMQSession_0_10.java A default binding is only added if there are no explicit bindings specified via x-bindings 2. BasicMessageConsumer_0_10.java When the same destination (Topic) is used to create two different consumers the code creates a copy of the destination to ensure the second consumer gets it's own unique temp queue. When doing so we need to ensure we delete any bindings for the previous temp queue. If we don't remove old bindings and if there were no explicit bindings specified via x-bindings, then the second consumers queue will not be bound due to the logic mentioned in [1]. (Bcos the previous binding is treated as explicit bindings). 3. AddressHelper.java The second part of the JIRA covers a different bug - i.e x-binding specified in the link properties are not used if the node type if a queue. I added code to read the x-bindings in link props if there are no x-bindings specified in the node props. 4. Modified test cases 1. To ensure that a default binding is not added when explicit bindings are specified. 2. To fix an existing test case that relied on a default binding even when x-bindings is specified. (*) I still need to add (or modify an existing test case) to cover the case where x-bindings are specified in link props when the node type if a queue. This addresses bug QPID-3265. https://issues.apache.org/jira/browse/QPID-3265 Diffs - http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession_0_10.java 1137691 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/BasicMessageConsumer_0_10.java 1137691 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/messaging/address/AddressHelper.java 1137691 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/client/destination/AddressBasedDestinationTest.java 1137691 Diff: https://reviews.apache.org/r/937/diff Testing --- The use cases specified in the JIRA were manually tested in addition to the above mentioned automated test cases. Thanks, rajith Can't subscribe to headers exchange using address (rather than BURL) Key: QPID-3265 URL: https://issues.apache.org/jira/browse/QPID-3265 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.10 Environment: java 0.10 client Reporter: Gordon Sim Assignee: Rajith Attapattu Creating a receiver for the following address works from python and c++, but not from JMS (using drain example in each case): my-headers-exchange; {link:{x-bindings:[{arguments:{'x-match':all,a:b,c:d}}]}} The problem with JMS seems to be that though it correctly interprets the arguments and issues a bind with them in it, it issues another bind to the exchange with no arguments that fails with an error. Also, the following also doesn't work: my-subscription-queue; {create:always, node:{x-declare:{auto-delete:True}}, link:{x-bindings:[{queue:my-subscription-queue, exchange:my-headers-exchange, arguments:{'x-match':all,a:b,c:d}}]}} Here the x-bindings in the link don't seem to get interpreted. However if instead they are moved to the node, that works. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3311) ConcurrentModificationException in java client during failover
[ https://issues.apache.org/jira/browse/QPID-3311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13052096#comment-13052096 ] Rajith Attapattu commented on QPID-3311: The patch looks good to me. I will commit this shortly. ConcurrentModificationException in java client during failover -- Key: QPID-3311 URL: https://issues.apache.org/jira/browse/QPID-3311 Project: Qpid Issue Type: Bug Components: Java Client Reporter: Siddhesh Poyarekar Attachments: TxSender.java, qpid-java-safe-remove-sessions.patch Description of problem: The java client removes transacted sessions during failover. This removal is not safe however, since it happens when the Hashmap of sessions is being iterated through. This occasionally results in a ConcurrentModificationException. How reproducible: Always Steps to Reproduce: 1. Run attached program Actual results: ERROR [IoReceiver - localhost/127.0.0.1:5672] (AMQConnectionDelegate_0_10.java:281) - error during failover java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:810) at java.util.HashMap$ValueIterator.next(HashMap.java:839) at org.apache.qpid.transport.Connection.resume(Connection.java:469) at org.apache.qpid.client.AMQConnectionDelegate_0_10.resubscribeSessions(AMQConnectionDelegate_0_10.java:221) at org.apache.qpid.client.AMQConnection.resubscribeSessions(AMQConnection.java:1207) at org.apache.qpid.client.AMQConnectionDelegate_0_10.closed(AMQConnectionDelegate_0_10.java:274) at org.apache.qpid.transport.Connection.closed(Connection.java:561) at org.apache.qpid.transport.network.Assembler.closed(Assembler.java:110) at org.apache.qpid.transport.network.InputHandler.closed(InputHandler.java:202) at org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:150) at java.lang.Thread.run(Thread.java:636) ERROR [IoReceiver - localhost/127.0.0.1:5672] (AMQConnectionDelegate_0_10.java:293) - connection exception: conn:3749eb9f org.apache.qpid.transport.ConnectionException: connection aborted at org.apache.qpid.transport.Connection.closed(Connection.java:534) at org.apache.qpid.transport.network.Assembler.closed(Assembler.java:110) at org.apache.qpid.transport.network.InputHandler.closed(InputHandler.java:202) at org.apache.qpid.transport.network.io.IoReceiver.run(IoReceiver.java:150) at java.lang.Thread.run(Thread.java:636) Expected results: Successful failover Additional info: Logging options (log4j.properties): log4j.rootLogger=debug, stdout, R log4j.appender.stdout=org.apache.log4j.ConsoleAppender log4j.appender.stdout.layout=org.apache.log4j.PatternLayout # Pattern to output the caller's file name and line number. log4j.appender.stdout.layout.ConversionPattern=%5p [%t] (%F:%L) - %m%n log4j.appender.R=org.apache.log4j.FileAppender log4j.appender.R.File=example.log log4j.appender.R.MaxFileSize=1KB # Keep one backup file log4j.appender.R.MaxBackupIndex=1 log4j.appender.R.layout=org.apache.log4j.PatternLayout log4j.logger.org.apache=TRACE -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Review Request: QPID-3079: allow asynchronous completion of Message.Accept command (note: requires store interface changes).
On 2011-06-17 13:19:13, Alan Conway wrote: Looking good, just a few suggestions. Note on testing: need to run store tests as well as qpidd tests. Yes, both store and C++ broker unit tests are passing. On 2011-06-17 13:19:13, Alan Conway wrote: /branches/qpid-3079/qpid/cpp/src/qpid/broker/DeliveryRecord.cpp, line 116 https://reviews.apache.org/r/860/diff/2/?file=21211#file21211line116 Static locals not thread safe, use a normal local variable. Removed. On 2011-06-17 13:19:13, Alan Conway wrote: /branches/qpid-3079/qpid/cpp/src/qpid/broker/DeliveryRecord.cpp, line 125 https://reviews.apache.org/r/860/diff/2/?file=21211#file21211line125 What happens in the case isRedundant() == true? the D.R. is removed from the unacked list - this check has been moved to the caller. On 2011-06-17 13:19:13, Alan Conway wrote: /branches/qpid-3079/qpid/cpp/src/qpid/broker/Queue.h, line 300 https://reviews.apache.org/r/860/diff/2/?file=21213#file21213line300 Functions are too big to inline in .h, move to .cpp. done. On 2011-06-17 13:19:13, Alan Conway wrote: /branches/qpid-3079/qpid/cpp/src/qpid/broker/Queue.h, line 310 https://reviews.apache.org/r/860/diff/2/?file=21213#file21213line310 Suggest a change here to make it more flexible and type safe: registerCallback(boost::functionvoid() f); You can package up all the details in boost::bind at the call site, this class doesn't need to know. See comments below Very nice - done. On 2011-06-17 13:19:13, Alan Conway wrote: /branches/qpid-3079/qpid/cpp/src/qpid/broker/Queue.cpp, line 665 https://reviews.apache.org/r/860/diff/2/?file=21214#file21214line665 static local variables are not thread safe. Use a normal local variable constructing an intrusive pointer is trivial. done. On 2011-06-17 13:19:13, Alan Conway wrote: /branches/qpid-3079/qpid/cpp/src/qpid/broker/SemanticState.cpp, line 804 https://reviews.apache.org/r/860/diff/2/?file=21215#file21215line804 This doesn't need to be static, and you can avoid the casting. Just write void dequeueDone() { cmd-complete(); } and see further comment at the call site below done. On 2011-06-17 13:19:13, Alan Conway wrote: /branches/qpid-3079/qpid/cpp/src/qpid/broker/SemanticState.cpp, line 966 https://reviews.apache.org/r/860/diff/2/?file=21215#file21215line966 See comments above: this can now be async-registerCallback(boost::bind(AsyncMessageAcceptCmd::dequeueDone, this)) done. On 2011-06-17 13:19:13, Alan Conway wrote: /branches/qpid-3079/qpid/cpp/src/qpid/broker/Queue.h, line 437 https://reviews.apache.org/r/860/diff/2/?file=21213#file21213line437 Store the DequeueCompletion pointer on the PersistableMessage, avoid this map lookup. Sorry Alan, I'm being dense here - I don't understand. Wouldn't the PersistableMessage still need a container for the DequeueCompletions, as there may be more than one dequeue pending for that message? I'm thinking of fanout - same physical PersistableMessage shared among N queues. There may be several different sessions dequeuing/accepting that message at the same time, right? How do we 'map' (heh) back from the P.M. to the sessions pending on the Message.Accept completion? On 2011-06-17 13:19:13, Alan Conway wrote: /branches/qpid-3079/qpid/cpp/src/qpid/broker/DeliveryRecord.h, line 107 https://reviews.apache.org/r/860/diff/2/?file=21210#file21210line107 Why the change from dequeue to list? Big performance improvement with qpid-cpp-benchmark by moving from a dequeue to a list. I'm guessing because we delete entries from the middle of the list(?) - Kenneth --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/860/#review859 --- On 2011-06-16 15:25:17, Kenneth Giusti wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/860/ --- (Updated 2011-06-16 15:25:17) Review request for qpid, Alan Conway, Gordon Sim, and Kim van der Riet. Summary --- Modifies the broker's handling of Message.Accept to hold off the completion of the command until all messages related to the accept have completed dequeue. This particularly applies to persistent messages, as the store::dequeue() operation must complete before the message is considered fully dequeued. Note this bugfix requires some changes to the broker's store module interface: previously, the store only identified the message when a dequeue was completed. This is not enough information - the queue from which is was removed must also be identified (the message may be in the
[jira] [Commented] (QPID-3079) message.accept command should be completed on a per-dequeue basis
[ https://issues.apache.org/jira/browse/QPID-3079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13052155#comment-13052155 ] jirapos...@reviews.apache.org commented on QPID-3079: - bq. On 2011-06-17 13:19:13, Alan Conway wrote: bq. Looking good, just a few suggestions. bq. bq. Note on testing: need to run store tests as well as qpidd tests. Yes, both store and C++ broker unit tests are passing. bq. On 2011-06-17 13:19:13, Alan Conway wrote: bq. /branches/qpid-3079/qpid/cpp/src/qpid/broker/DeliveryRecord.cpp, line 116 bq. https://reviews.apache.org/r/860/diff/2/?file=21211#file21211line116 bq. bq. Static locals not thread safe, use a normal local variable. Removed. bq. On 2011-06-17 13:19:13, Alan Conway wrote: bq. /branches/qpid-3079/qpid/cpp/src/qpid/broker/DeliveryRecord.cpp, line 125 bq. https://reviews.apache.org/r/860/diff/2/?file=21211#file21211line125 bq. bq. What happens in the case isRedundant() == true? the D.R. is removed from the unacked list - this check has been moved to the caller. bq. On 2011-06-17 13:19:13, Alan Conway wrote: bq. /branches/qpid-3079/qpid/cpp/src/qpid/broker/Queue.h, line 300 bq. https://reviews.apache.org/r/860/diff/2/?file=21213#file21213line300 bq. bq. Functions are too big to inline in .h, move to .cpp. done. bq. On 2011-06-17 13:19:13, Alan Conway wrote: bq. /branches/qpid-3079/qpid/cpp/src/qpid/broker/Queue.h, line 310 bq. https://reviews.apache.org/r/860/diff/2/?file=21213#file21213line310 bq. bq. Suggest a change here to make it more flexible and type safe: bq. bq. registerCallback(boost::functionvoid() f); bq. bq. You can package up all the details in boost::bind at the call site, this class doesn't need to know. See comments below Very nice - done. bq. On 2011-06-17 13:19:13, Alan Conway wrote: bq. /branches/qpid-3079/qpid/cpp/src/qpid/broker/Queue.cpp, line 665 bq. https://reviews.apache.org/r/860/diff/2/?file=21214#file21214line665 bq. bq. static local variables are not thread safe. Use a normal local variable constructing an intrusive pointer is trivial. done. bq. On 2011-06-17 13:19:13, Alan Conway wrote: bq. /branches/qpid-3079/qpid/cpp/src/qpid/broker/SemanticState.cpp, line 804 bq. https://reviews.apache.org/r/860/diff/2/?file=21215#file21215line804 bq. bq. This doesn't need to be static, and you can avoid the casting. Just write bq. bq. void dequeueDone() { cmd-complete(); } bq. bq. and see further comment at the call site below done. bq. On 2011-06-17 13:19:13, Alan Conway wrote: bq. /branches/qpid-3079/qpid/cpp/src/qpid/broker/SemanticState.cpp, line 966 bq. https://reviews.apache.org/r/860/diff/2/?file=21215#file21215line966 bq. bq. See comments above: this can now be bq. bq. async-registerCallback(boost::bind(AsyncMessageAcceptCmd::dequeueDone, this)) done. bq. On 2011-06-17 13:19:13, Alan Conway wrote: bq. /branches/qpid-3079/qpid/cpp/src/qpid/broker/Queue.h, line 437 bq. https://reviews.apache.org/r/860/diff/2/?file=21213#file21213line437 bq. bq. Store the DequeueCompletion pointer on the PersistableMessage, avoid this map lookup. Sorry Alan, I'm being dense here - I don't understand. Wouldn't the PersistableMessage still need a container for the DequeueCompletions, as there may be more than one dequeue pending for that message? I'm thinking of fanout - same physical PersistableMessage shared among N queues. There may be several different sessions dequeuing/accepting that message at the same time, right? How do we 'map' (heh) back from the P.M. to the sessions pending on the Message.Accept completion? bq. On 2011-06-17 13:19:13, Alan Conway wrote: bq. /branches/qpid-3079/qpid/cpp/src/qpid/broker/DeliveryRecord.h, line 107 bq. https://reviews.apache.org/r/860/diff/2/?file=21210#file21210line107 bq. bq. Why the change from dequeue to list? Big performance improvement with qpid-cpp-benchmark by moving from a dequeue to a list. I'm guessing because we delete entries from the middle of the list(?) - Kenneth --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/860/#review859 --- On 2011-06-16 15:25:17, Kenneth Giusti wrote: bq. bq. --- bq. This is an automatically generated e-mail. To reply, visit: bq. https://reviews.apache.org/r/860/ bq. --- bq. bq. (Updated 2011-06-16 15:25:17) bq. bq. bq. Review request for qpid, Alan Conway, Gordon Sim, and Kim van der Riet. bq. bq. bq. Summary bq. --- bq. bq. Modifies the broker's handling
[jira] [Commented] (QPID-3175) SSL support in Python client libraries
[ https://issues.apache.org/jira/browse/QPID-3175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13052167#comment-13052167 ] Rafael H. Schloming commented on QPID-3175: --- One comment on the patch. Is there a reason to change the arguments to the transport constructors? Would it be possible to have the keyfile, certfile, etc pulled out of the connection object that is passed to the transport rather than adding them as explicit arguments? SSL support in Python client libraries -- Key: QPID-3175 URL: https://issues.apache.org/jira/browse/QPID-3175 Project: Qpid Issue Type: Bug Components: Python Client Affects Versions: 0.8 Environment: Windows XP, Python 2.7.1, (broker Red Hat MRG 1.3 on RHEL 5.5) Reporter: JAkub Scholz Assignee: Rafael H. Schloming Fix For: 0.11 Attachments: QPID-3175.patch I was trying to connect to my broker with SSL encrypted connection (both PLAIN and EXTERNAL authentication methods). However, it seems to be not working. I get following error messages: Traceback (most recent call last): File ssl-external.py, line 20, in module connection.open() File string, line 6, in open File c:\opt\!_EUREX14\tests\qpid.python-0.8\python\qpid\messaging\endpoints.py, line 244, in open self.attach() File string, line 6, in attach File c:\opt\!_EUREX14\tests\qpid.python-0.8\python\qpid\messaging\endpoints.py, line 262, in attach self._ewait(lambda: self._transport_connected and not self._unlinked()) File c:\opt\!_EUREX14\tests\qpid.python-0.8\python\qpid\messaging\endpoints.py, line 197, in _ewait self.check_error() File c:\opt\!_EUREX14\tests\qpid.python-0.8\python\qpid\messaging\endpoints.py, line 190, in check_error raise self.error qpid.messaging.exceptions.ConnectError: [Errno 1] _ssl.c:499: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate In the source codes (messaging/transports.py), the SSL seems to be supported and implemented, but it is not working. I didn't found any possibilities how to pass the certificates to the SSL libraries and the wrap_socket call in transports.py is calling the wrap_socket without any additional attributes except the original socket. I didn't had the chance to test other platforms or Python versions, except Python 2.4.3 on RHEL 5.5, where the SSL is not supported at all (the SSL support in Python changed significantly with 2.6) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] [Commented] (QPID-3126) Make install fails with /usr/bin/ld: cannot find -lqmfengine error
[ https://issues.apache.org/jira/browse/QPID-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13052168#comment-13052168 ] Joel Bricker commented on QPID-3126: If you swap the following two lines in cpp/src/qmf.mk: libqmf.la \ libqmfengine.la \ You can install normally from source, without have to run libtool yourself. This worked for me, at least. Make install fails with /usr/bin/ld: cannot find -lqmfengine error Key: QPID-3126 URL: https://issues.apache.org/jira/browse/QPID-3126 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.8 Environment: Linux 2.6.32-28-server #55-Ubuntu SMP Mon Jan 10 23:57:16 UTC 2011 x86_64 GNU/Linux Reporter: Rafał Dowgird Labels: build Attachments: out.txt When 'make install' is run, the build fails with /usr/bin/ld: cannot find -lqmfengine It is possible to work around that by running libtool manually in /cpp/src, with the list of libraries rearranged: ../libtool --mode=install /usr/bin/install -c libqpidtypes.la libqpidcommon.la libqpidbroker.la libqpidclient.la libqmfengine.la libqpidmessaging.la libqmf.la libqmf2.la libqmfconsole.la '/usr/local/lib' Note that libqmfengine.la was moved before libqpidmessaging.la, compared to what make tries to run. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: Qpid python bindings for windows
Hi Ovi, The existing python bindings work on Windows. -Steve -- Steve Huston, Riverace Corporation Total Lifecycle Support for Your Networked Applications http://www.riverace.com -Original Message- From: Ovidiu Visan [mailto:ovi...@redhat.com] Sent: Monday, June 20, 2011 12:33 PM To: dev@qpid.apache.org; us...@qpid.apache.org Subject: Qpid python bindings for windows Hi guys, We need to stand up a windows proxy, in the cloud backend, so that the proxy can use local authentication to the booting instance. We want to control the proxy via qpid/qmf, to pass commands down to it and get results back. For that we want to use Python, so the question is: are there any qpid bindings for python that would work in windows? Thank you. Ovi - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:users-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org