[jira] [Commented] (QPID-3338) qpidxarm CMake target is missing in 0-12
[ https://issues.apache.org/jira/browse/QPID-3338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13064393#comment-13064393 ] Cliff Jansen commented on QPID-3338: updated trunk: r1145883 updated 0.12 branch: r1145886 qpidxarm CMake target is missing in 0-12 Key: QPID-3338 URL: https://issues.apache.org/jira/browse/QPID-3338 Project: Qpid Issue Type: Bug Components: C++ Broker, C++ Client Affects Versions: 0.12 Environment: Windows with Microsoft compilers (as opposed to mingw) Reporter: Cliff Jansen Assignee: Cliff Jansen Priority: Blocker Fix For: 0.12 Attachments: jira-3338.patch cpp/src/CMakeLists.txt was altered for mingw builds in QPID-2905 (r1104662). The qpidxarm target builds the XA distributed transaction resource manager for use with the Microsoft distributed trasanction coordinator. It was targeted for Windows builds only, using the CMake variable WIN32. This variable was changed to _MSC_VER for QPID-2905, presumably to indicate that the build target should only apply to builds using the Microsoft compiler, and not mingw. Unfortunately _MSC_VER is not a recognized CMAKE variable and the qpidxarm target is never generated. The CMake documentation indicates the the variable MSVC should be used to indicate The Microsoft compiler compared to mingw. -- 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] [Updated] (QPID-3310) Principal/Subject refactoring
[ https://issues.apache.org/jira/browse/QPID-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-3310: - Attachment: (was: 0001-QPID-3310-Principal-Subject-refactoring.patch) Principal/Subject refactoring - Key: QPID-3310 URL: https://issues.apache.org/jira/browse/QPID-3310 Project: Qpid Issue Type: Task Components: Java Broker Affects Versions: 0.10 Reporter: Keith Wall Assignee: Keith Wall Fix For: Future This task is to refactor the broker to pass through a Subject from the authentication layer downwards, rather than a Principal. The motivation for this change is to allow the security modules to make decisions based on all principals (including Group principals) rather than merely the UsernamePrincipal. This task will support QPID-3283. -- 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] [Updated] (QPID-3310) Principal/Subject refactoring
[ https://issues.apache.org/jira/browse/QPID-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall updated QPID-3310: - Attachment: 0001-QPID-3310-Principal-Subject-refactoring.patch Hi Robbie, I've addressed your review comments and re-cut the patch. cheers Keith Principal/Subject refactoring - Key: QPID-3310 URL: https://issues.apache.org/jira/browse/QPID-3310 Project: Qpid Issue Type: Task Components: Java Broker Affects Versions: 0.10 Reporter: Keith Wall Assignee: Keith Wall Fix For: Future Attachments: 0001-QPID-3310-Principal-Subject-refactoring.patch This task is to refactor the broker to pass through a Subject from the authentication layer downwards, rather than a Principal. The motivation for this change is to allow the security modules to make decisions based on all principals (including Group principals) rather than merely the UsernamePrincipal. This task will support QPID-3283. -- 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] [Assigned] (QPID-3310) Principal/Subject refactoring
[ https://issues.apache.org/jira/browse/QPID-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Keith Wall reassigned QPID-3310: Assignee: Robbie Gemmell (was: Keith Wall) Principal/Subject refactoring - Key: QPID-3310 URL: https://issues.apache.org/jira/browse/QPID-3310 Project: Qpid Issue Type: Task Components: Java Broker Affects Versions: 0.10 Reporter: Keith Wall Assignee: Robbie Gemmell Fix For: Future Attachments: 0001-QPID-3310-Principal-Subject-refactoring.patch This task is to refactor the broker to pass through a Subject from the authentication layer downwards, rather than a Principal. The motivation for this change is to allow the security modules to make decisions based on all principals (including Group principals) rather than merely the UsernamePrincipal. This task will support QPID-3283. -- 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-3310) Principal/Subject refactoring
[ https://issues.apache.org/jira/browse/QPID-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13064433#comment-13064433 ] Robbie Gemmell commented on QPID-3310: -- Woops, I didn't post the comments on the JIRA when I sent you them. For anyone later wondering, they were: The newly introduced for loop in AccessControl to validate rights depends on the ordering of rules checked to ensure the correct result, and so may return the wrong result if the iterator is not returning them in the appropriate order. There are a couple of code style issues with braces not on new lines. In the new control flow added in ServerConnection#setAuthorizedSubject(), whilst actually functional, looks uninentially odd due to checking things are null and then assigning them to be null once they are known to be. Principal/Subject refactoring - Key: QPID-3310 URL: https://issues.apache.org/jira/browse/QPID-3310 Project: Qpid Issue Type: Task Components: Java Broker Affects Versions: 0.10 Reporter: Keith Wall Assignee: Robbie Gemmell Fix For: Future Attachments: 0001-QPID-3310-Principal-Subject-refactoring.patch This task is to refactor the broker to pass through a Subject from the authentication layer downwards, rather than a Principal. The motivation for this change is to allow the security modules to make decisions based on all principals (including Group principals) rather than merely the UsernamePrincipal. This task will support QPID-3283. -- 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-3355) Client aborts when replaying sender after connection recovery
[ https://issues.apache.org/jira/browse/QPID-3355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13064459#comment-13064459 ] Gordon Sim commented on QPID-3355: -- I have committed this patch since it is logically consistent and may indeed prevent this specific issue. However the root cause is I believe in the messaging implementation above this, where the session is reset while a sync() call is in progress. If the session is referenced while calling sync() then the issue the attached patch fixes won't even occur. Its possible there are other forms of failure possible from the root cause as well so I have fixed that too. Client aborts when replaying sender after connection recovery - Key: QPID-3355 URL: https://issues.apache.org/jira/browse/QPID-3355 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.7, 0.10 Reporter: Jason Dillaman Fix For: 0.13 Attachments: QPID-3355.patch There is a race condition between qpid::client::SessionImpl::waitForCompletion and qpid::client::SessionImpl::~SessionImpl. If one thread is waiting for a completion and another thread causes the destructor for the session to be invoked, the destructor can abort the client if waitForCompletion is still holding the state mutex. The reason this occurs is because waitForCompletion is not holding a Waiter::ScopedWait, so the destructor completes while the mutex is still being held. This was discovered when testing connection loss and recovery. -- 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] [Resolved] (QPID-3355) Client aborts when replaying sender after connection recovery
[ https://issues.apache.org/jira/browse/QPID-3355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gordon Sim resolved QPID-3355. -- Resolution: Fixed Fix Version/s: 0.13 Client aborts when replaying sender after connection recovery - Key: QPID-3355 URL: https://issues.apache.org/jira/browse/QPID-3355 Project: Qpid Issue Type: Bug Components: C++ Client Affects Versions: 0.7, 0.10 Reporter: Jason Dillaman Fix For: 0.13 Attachments: QPID-3355.patch There is a race condition between qpid::client::SessionImpl::waitForCompletion and qpid::client::SessionImpl::~SessionImpl. If one thread is waiting for a completion and another thread causes the destructor for the session to be invoked, the destructor can abort the client if waitForCompletion is still holding the state mutex. The reason this occurs is because waitForCompletion is not holding a Waiter::ScopedWait, so the destructor completes while the mutex is still being held. This was discovered when testing connection loss and recovery. -- 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: Deleting ruby and dotnet top level directories (was Re: 0.12 release update - RC1 this week)
On 07/12/2011 01:47 PM, Gordon Sim wrote: On 07/12/2011 12:18 PM, Robbie Gemmell wrote: Given that we voted to stop releasing standalone artifacts for the pure ruby client with the last release, is there any reason to keep it in the repository? I noticed that the first thing that happened with the 0.10 release was that a user came looking for the ruby client when the artifact went missing, found the code in the 'full release' archive instead, and just used that. A highly effective removal. I have said in the past I'd prefer to use a non-trunk attic area, but the concensus was to go for deletion, although nothing has happened since that discussion. I'm happy to delete this and the dotnet directory. Any objections to that? Going once, going twice... I'll delete these directories tomorrow AM unless I hear objections. I'll do so on both the 0.12 release branch and on trunk. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Review Request: QPID-3345: restore/add ability to use sys props to select the NetworkTransport used to make/accept connections
On 2011-07-13 04:04:38, rajith attapattu wrote: /trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/Transport.java, line 30 https://reviews.apache.org/r/1087/diff/1/?file=22375#file22375line30 Looking at the Transport class, I see that transports are choosen based on the AMQP protocol version. While it is true that this can be easily overridden using qpid.transport system property, it would have been nice if we had the transport implementations independent of the protocol versions. Perhaps this is the case, and the map is just there to specify the default (or preferred) transport for each version? Is this approach was taken due to the 0-8,0-9 version code paths are heavily tied to MINA (I haven't really looked at the code in this area for a long time) ? No, for the client, user can either override all transports (via -Dqpid.transport) or by protocol version (via -Dqpid.transport.v0_10 etc). The objective of this Jira was merely to reintroduce plugability of the existing transports. The next step will be the testing of the IoNetworkTransport implementation against 0-8..0-9-1 so that it can become the default for all protocols. This will take us the next step towards making the use Mina on the client optional. This is a reasonably complex area, so I think an incremental approach makes sense. - Keith --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/1087/#review1041 --- On 2011-07-12 09:38:50, Keith Wall wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/1087/ --- (Updated 2011-07-12 09:38:50) Review request for qpid. Summary --- QPID-3345: transport implementations for client/broker sides controllable via new System Properties and Reflection. This addresses bug QPID-3345. https://issues.apache.org/jira/browse/QPID-3345 Diffs - /trunk/qpid/java/common/src/test/java/org/apache/qpid/transport/network/TransportTest.java PRE-CREATION /trunk/qpid/java/common/src/test/java/org/apache/qpid/test/utils/QpidTestCase.java 1145481 /trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/security/SecurityLayer.java 1145481 /trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/Transport.java 1145481 /trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/NetworkTransport.java 1145481 /trunk/qpid/java/broker/src/main/java/org/apache/qpid/server/Broker.java 1145481 /trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQConnectionDelegate_8_0.java 1145481 /trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/Connection.java 1145481 /trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/utils/QpidBrokerTestCase.java 1145481 Diff: https://reviews.apache.org/r/1087/diff Testing --- Additional unit test and exercised by existing system test suite (0-9-1/0-10 code paths) Thanks, Keith
[jira] [Commented] (QPID-3345) Make new transport implementations pluggable
[ https://issues.apache.org/jira/browse/QPID-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13064597#comment-13064597 ] jirapos...@reviews.apache.org commented on QPID-3345: - bq. On 2011-07-13 04:04:38, rajith attapattu wrote: bq. /trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/Transport.java, line 30 bq. https://reviews.apache.org/r/1087/diff/1/?file=22375#file22375line30 bq. bq. Looking at the Transport class, I see that transports are choosen based on the AMQP protocol version. bq. bq. While it is true that this can be easily overridden using qpid.transport system property, it would have been nice if we had the transport implementations independent of the protocol versions. bq. bq. Perhaps this is the case, and the map is just there to specify the default (or preferred) transport for each version? bq. bq. Is this approach was taken due to the 0-8,0-9 version code paths are heavily tied to MINA (I haven't really looked at the code in this area for a long time) ? No, for the client, user can either override all transports (via -Dqpid.transport) or by protocol version (via -Dqpid.transport.v0_10 etc). The objective of this Jira was merely to reintroduce plugability of the existing transports. The next step will be the testing of the IoNetworkTransport implementation against 0-8..0-9-1 so that it can become the default for all protocols. This will take us the next step towards making the use Mina on the client optional. This is a reasonably complex area, so I think an incremental approach makes sense. - Keith --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/1087/#review1041 --- On 2011-07-12 09:38:50, Keith Wall wrote: bq. bq. --- bq. This is an automatically generated e-mail. To reply, visit: bq. https://reviews.apache.org/r/1087/ bq. --- bq. bq. (Updated 2011-07-12 09:38:50) bq. bq. bq. Review request for qpid. bq. bq. bq. Summary bq. --- bq. bq. QPID-3345: transport implementations for client/broker sides controllable via new System Properties and Reflection. bq. bq. bq. This addresses bug QPID-3345. bq. https://issues.apache.org/jira/browse/QPID-3345 bq. bq. bq. Diffs bq. - bq. bq. /trunk/qpid/java/common/src/test/java/org/apache/qpid/transport/network/TransportTest.java PRE-CREATION bq. /trunk/qpid/java/common/src/test/java/org/apache/qpid/test/utils/QpidTestCase.java 1145481 bq. /trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/security/SecurityLayer.java 1145481 bq. /trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/Transport.java 1145481 bq. /trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/NetworkTransport.java 1145481 bq./trunk/qpid/java/broker/src/main/java/org/apache/qpid/server/Broker.java 1145481 bq. /trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQConnectionDelegate_8_0.java 1145481 bq. /trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/Connection.java 1145481 bq. /trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/utils/QpidBrokerTestCase.java 1145481 bq. bq. Diff: https://reviews.apache.org/r/1087/diff bq. bq. bq. Testing bq. --- bq. bq. Additional unit test and exercised by existing system test suite (0-9-1/0-10 code paths) bq. bq. bq. Thanks, bq. bq. Keith bq. bq. Make new transport implementations pluggable Key: QPID-3345 URL: https://issues.apache.org/jira/browse/QPID-3345 Project: Qpid Issue Type: Improvement Components: Java Client, Java Common Reporter: Keith Wall Assignee: Rajith Attapattu Fix For: 0.13 Attachments: 0001-QPID-3345-restore-add-ability-to-use-sys-props-to-se.patch Allow new transport implementations (those produced by QPID-3342) to be loaded by reflection, thus working towards the removal of dependencies on Mina by the client. -- 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] [Resolved] (QPID-3310) Principal/Subject refactoring
[ https://issues.apache.org/jira/browse/QPID-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-3310. -- Resolution: Fixed Fix Version/s: (was: Future) 0.13 Patch applied. Principal/Subject refactoring - Key: QPID-3310 URL: https://issues.apache.org/jira/browse/QPID-3310 Project: Qpid Issue Type: Task Components: Java Broker Affects Versions: 0.10 Reporter: Keith Wall Assignee: Robbie Gemmell Fix For: 0.13 Attachments: 0001-QPID-3310-Principal-Subject-refactoring.patch This task is to refactor the broker to pass through a Subject from the authentication layer downwards, rather than a Principal. The motivation for this change is to allow the security modules to make decisions based on all principals (including Group principals) rather than merely the UsernamePrincipal. This task will support QPID-3283. -- 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] [Assigned] (QPID-3267) Java broker authentication does not work on JRE's other than Sun's
[ https://issues.apache.org/jira/browse/QPID-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned QPID-3267: Assignee: Robbie Gemmell (was: Keith Wall) Java broker authentication does not work on JRE's other than Sun's -- Key: QPID-3267 URL: https://issues.apache.org/jira/browse/QPID-3267 Project: Qpid Issue Type: Bug Reporter: Danushka Menikkumbura Assignee: Robbie Gemmell Priority: Critical Attachments: QPID-3267.patch This is due to use of com.sun.security.auth.UserPrincipal in ServerSession which is sun-specific. -- 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] [Updated] (QPID-3267) Java broker authentication does not work on JRE's other than Sun's
[ https://issues.apache.org/jira/browse/QPID-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-3267: - Component/s: Java Broker Affects Version/s: 0.12 0.11 0.6 0.7 0.8 0.9 0.10 Fix Version/s: 0.13 Java broker authentication does not work on JRE's other than Sun's -- Key: QPID-3267 URL: https://issues.apache.org/jira/browse/QPID-3267 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.6, 0.7, 0.8, 0.9, 0.10, 0.11, 0.12 Reporter: Danushka Menikkumbura Assignee: Robbie Gemmell Priority: Critical Fix For: 0.13 Attachments: QPID-3267.patch This is due to use of com.sun.security.auth.UserPrincipal in ServerSession which is sun-specific. -- 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-3267) Java broker authentication does not work on JRE's other than Sun's
[ https://issues.apache.org/jira/browse/QPID-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13064622#comment-13064622 ] Robbie Gemmell commented on QPID-3267: -- Hi Danushka, With the patch for QPID-3310 now applied, this issue should hopefully be resolved, so I've pushed this JIRA to Ready To Review as a result, Can you check the updated code meets your need and close this out if it does? Thanks, Robbie Java broker authentication does not work on JRE's other than Sun's -- Key: QPID-3267 URL: https://issues.apache.org/jira/browse/QPID-3267 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.6, 0.7, 0.8, 0.9, 0.10, 0.11, 0.12 Reporter: Danushka Menikkumbura Assignee: Robbie Gemmell Priority: Critical Fix For: 0.13 Attachments: QPID-3267.patch This is due to use of com.sun.security.auth.UserPrincipal in ServerSession which is sun-specific. -- 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: Deleting ruby and dotnet top level directories (was Re: 0.12 release update - RC1 this week)
On 07/13/2011 08:20 AM, Gordon Sim wrote: Going once, going twice... I'll delete these directories tomorrow AM unless I hear objections. I'll do so on both the 0.12 release branch and on trunk. My only suggestion would be to delete everything in the directories except the top level directory and then place a text / readme in the top level directory telling users where to locate the new versions of these clients. Carl. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Deleting ruby and dotnet top level directories (was Re: 0.12 release update - RC1 this week)
On 07/13/2011 04:39 PM, Carl Trieloff wrote: On 07/13/2011 08:20 AM, Gordon Sim wrote: Going once, going twice... I'll delete these directories tomorrow AM unless I hear objections. I'll do so on both the 0.12 release branch and on trunk. My only suggestion would be to delete everything in the directories except the top level directory and then place a text / readme in the top level directory telling users where to locate the new versions of these clients. I'm not keen on that. Documentation on what we have and where to find it is certainly good. I don't like readmes in stale directories. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Review Request: QPID-3345: restore/add ability to use sys props to select the NetworkTransport used to make/accept connections
On 2011-07-13 04:04:38, rajith attapattu wrote: /trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/Transport.java, line 30 https://reviews.apache.org/r/1087/diff/1/?file=22375#file22375line30 Looking at the Transport class, I see that transports are choosen based on the AMQP protocol version. While it is true that this can be easily overridden using qpid.transport system property, it would have been nice if we had the transport implementations independent of the protocol versions. Perhaps this is the case, and the map is just there to specify the default (or preferred) transport for each version? Is this approach was taken due to the 0-8,0-9 version code paths are heavily tied to MINA (I haven't really looked at the code in this area for a long time) ? Keith Wall wrote: No, for the client, user can either override all transports (via -Dqpid.transport) or by protocol version (via -Dqpid.transport.v0_10 etc). The objective of this Jira was merely to reintroduce plugability of the existing transports. The next step will be the testing of the IoNetworkTransport implementation against 0-8..0-9-1 so that it can become the default for all protocols. This will take us the next step towards making the use Mina on the client optional. This is a reasonably complex area, so I think an incremental approach makes sense. Gotcha. Thanks for the answers. - rajith --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/1087/#review1041 --- On 2011-07-12 09:38:50, Keith Wall wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/1087/ --- (Updated 2011-07-12 09:38:50) Review request for qpid. Summary --- QPID-3345: transport implementations for client/broker sides controllable via new System Properties and Reflection. This addresses bug QPID-3345. https://issues.apache.org/jira/browse/QPID-3345 Diffs - /trunk/qpid/java/common/src/test/java/org/apache/qpid/transport/network/TransportTest.java PRE-CREATION /trunk/qpid/java/common/src/test/java/org/apache/qpid/test/utils/QpidTestCase.java 1145481 /trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/security/SecurityLayer.java 1145481 /trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/Transport.java 1145481 /trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/NetworkTransport.java 1145481 /trunk/qpid/java/broker/src/main/java/org/apache/qpid/server/Broker.java 1145481 /trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQConnectionDelegate_8_0.java 1145481 /trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/Connection.java 1145481 /trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/utils/QpidBrokerTestCase.java 1145481 Diff: https://reviews.apache.org/r/1087/diff Testing --- Additional unit test and exercised by existing system test suite (0-9-1/0-10 code paths) Thanks, Keith
[jira] [Commented] (QPID-3345) Make new transport implementations pluggable
[ https://issues.apache.org/jira/browse/QPID-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13064666#comment-13064666 ] jirapos...@reviews.apache.org commented on QPID-3345: - bq. On 2011-07-13 04:04:38, rajith attapattu wrote: bq. /trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/Transport.java, line 30 bq. https://reviews.apache.org/r/1087/diff/1/?file=22375#file22375line30 bq. bq. Looking at the Transport class, I see that transports are choosen based on the AMQP protocol version. bq. bq. While it is true that this can be easily overridden using qpid.transport system property, it would have been nice if we had the transport implementations independent of the protocol versions. bq. bq. Perhaps this is the case, and the map is just there to specify the default (or preferred) transport for each version? bq. bq. Is this approach was taken due to the 0-8,0-9 version code paths are heavily tied to MINA (I haven't really looked at the code in this area for a long time) ? bq. bq. Keith Wall wrote: bq. No, for the client, user can either override all transports (via -Dqpid.transport) or by protocol version (via -Dqpid.transport.v0_10 etc). bq. bq. The objective of this Jira was merely to reintroduce plugability of the existing transports. bq. bq. The next step will be the testing of the IoNetworkTransport implementation against 0-8..0-9-1 so that it can become the default for all protocols. This will take us the next step towards making the use Mina on the client optional. This is a reasonably complex area, so I think an incremental approach makes sense. bq. bq. Gotcha. Thanks for the answers. - rajith --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/1087/#review1041 --- On 2011-07-12 09:38:50, Keith Wall wrote: bq. bq. --- bq. This is an automatically generated e-mail. To reply, visit: bq. https://reviews.apache.org/r/1087/ bq. --- bq. bq. (Updated 2011-07-12 09:38:50) bq. bq. bq. Review request for qpid. bq. bq. bq. Summary bq. --- bq. bq. QPID-3345: transport implementations for client/broker sides controllable via new System Properties and Reflection. bq. bq. bq. This addresses bug QPID-3345. bq. https://issues.apache.org/jira/browse/QPID-3345 bq. bq. bq. Diffs bq. - bq. bq. /trunk/qpid/java/common/src/test/java/org/apache/qpid/transport/network/TransportTest.java PRE-CREATION bq. /trunk/qpid/java/common/src/test/java/org/apache/qpid/test/utils/QpidTestCase.java 1145481 bq. /trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/security/SecurityLayer.java 1145481 bq. /trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/Transport.java 1145481 bq. /trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/NetworkTransport.java 1145481 bq./trunk/qpid/java/broker/src/main/java/org/apache/qpid/server/Broker.java 1145481 bq. /trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQConnectionDelegate_8_0.java 1145481 bq. /trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/Connection.java 1145481 bq. /trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/utils/QpidBrokerTestCase.java 1145481 bq. bq. Diff: https://reviews.apache.org/r/1087/diff bq. bq. bq. Testing bq. --- bq. bq. Additional unit test and exercised by existing system test suite (0-9-1/0-10 code paths) bq. bq. bq. Thanks, bq. bq. Keith bq. bq. Make new transport implementations pluggable Key: QPID-3345 URL: https://issues.apache.org/jira/browse/QPID-3345 Project: Qpid Issue Type: Improvement Components: Java Client, Java Common Reporter: Keith Wall Assignee: Rajith Attapattu Fix For: 0.13 Attachments: 0001-QPID-3345-restore-add-ability-to-use-sys-props-to-se.patch Allow new transport implementations (those produced by QPID-3342) to be loaded by reflection, thus working towards the removal of dependencies on Mina by the client. -- 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-3345) Make new transport implementations pluggable
[ https://issues.apache.org/jira/browse/QPID-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13064667#comment-13064667 ] jirapos...@reviews.apache.org commented on QPID-3345: - --- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/1087/#review1045 --- Ship it! I looked at the patch from the client side and it looks good to me. I am happy with the direction you are taking. - rajith On 2011-07-12 09:38:50, Keith Wall wrote: bq. bq. --- bq. This is an automatically generated e-mail. To reply, visit: bq. https://reviews.apache.org/r/1087/ bq. --- bq. bq. (Updated 2011-07-12 09:38:50) bq. bq. bq. Review request for qpid. bq. bq. bq. Summary bq. --- bq. bq. QPID-3345: transport implementations for client/broker sides controllable via new System Properties and Reflection. bq. bq. bq. This addresses bug QPID-3345. bq. https://issues.apache.org/jira/browse/QPID-3345 bq. bq. bq. Diffs bq. - bq. bq. /trunk/qpid/java/common/src/test/java/org/apache/qpid/transport/network/TransportTest.java PRE-CREATION bq. /trunk/qpid/java/common/src/test/java/org/apache/qpid/test/utils/QpidTestCase.java 1145481 bq. /trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/security/SecurityLayer.java 1145481 bq. /trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/Transport.java 1145481 bq. /trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/network/NetworkTransport.java 1145481 bq./trunk/qpid/java/broker/src/main/java/org/apache/qpid/server/Broker.java 1145481 bq. /trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQConnectionDelegate_8_0.java 1145481 bq. /trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/Connection.java 1145481 bq. /trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/utils/QpidBrokerTestCase.java 1145481 bq. bq. Diff: https://reviews.apache.org/r/1087/diff bq. bq. bq. Testing bq. --- bq. bq. Additional unit test and exercised by existing system test suite (0-9-1/0-10 code paths) bq. bq. bq. Thanks, bq. bq. Keith bq. bq. Make new transport implementations pluggable Key: QPID-3345 URL: https://issues.apache.org/jira/browse/QPID-3345 Project: Qpid Issue Type: Improvement Components: Java Client, Java Common Reporter: Keith Wall Assignee: Rajith Attapattu Fix For: 0.13 Attachments: 0001-QPID-3345-restore-add-ability-to-use-sys-props-to-se.patch Allow new transport implementations (those produced by QPID-3342) to be loaded by reflection, thus working towards the removal of dependencies on Mina by the client. -- 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: Deleting ruby and dotnet top level directories (was Re: 0.12 release update - RC1 this week)
On 07/13/2011 11:53 AM, Gordon Sim wrote: On 07/13/2011 04:39 PM, Carl Trieloff wrote: On 07/13/2011 08:20 AM, Gordon Sim wrote: Going once, going twice... I'll delete these directories tomorrow AM unless I hear objections. I'll do so on both the 0.12 release branch and on trunk. My only suggestion would be to delete everything in the directories except the top level directory and then place a text / readme in the top level directory telling users where to locate the new versions of these clients. I'm not keen on that. Documentation on what we have and where to find it is certainly good. I don't like readmes in stale directories. How about a top level readme with a where everything is. I think this is particularly important given the swig bindings as they are not that easy to find unless you know what you are looking for. Carl. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Deleting ruby and dotnet top level directories (was Re: 0.12 release update - RC1 this week)
On 07/13/2011 06:16 PM, Carl Trieloff wrote: How about a top level readme with a where everything is. Yes, a top level README is reasonable. I think this is particularly important given the swig bindings as they are not that easy to find unless you know what you are looking for. I agree they aren't easy to find. We also need to be clear about what to expect in terms of maturity with these however. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Deleting ruby and dotnet top level directories (was Re: 0.12 release update - RC1 this week)
On 07/13/2011 01:59 PM, Gordon Sim wrote: How about a top level readme with a where everything is. Yes, a top level README is reasonable. ack, this is a better than my first idea. I think this is particularly important given the swig bindings as they are not that easy to find unless you know what you are looking for. I agree they aren't easy to find. We also need to be clear about what to expect in terms of maturity with these however. My comments are related to usability, and finding the pieces in the download. It might make more sense to provide maturity indicators on the download page, we can discuss this and add them with the 0.12 release. Carl. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Unable to connect multiple consumers to a queue on fan out exchange
Hi All,
I have a fanout exchange and I am binding different queues to this exchange.
When I send data to this exchange each queue that is bound to this exchange
is getting data as expected. But when I try to connect multiple consumers to
one of these fanned out queues, I get the following message:
Queue message_queue1 has an exclusive consumer. No more consumers allowed.
Here is the properties file that has the configuration:
fanout.properties:
java.naming.factory.initial =
org.apache.qpid.jndi.PropertiesFileInitialContextFactory
connectionfactory.qpidConnectionfactory =
amqp://guest:guest@xxx/?brokerlist='tcp://x:5672'
# for producer
destination.fanoutQueue =
BURL:fanout://testcollector.fanout//message_queue?durable='false'autodelete='true'exclusive='false'
# for consumers
destination.fanoutQueue1 =
BURL:fanout://testcollector.fanout//message_queue1?durable='false'autodelete='true'exclusive='false'
destination.fanoutQueue2 =
BURL:fanout://testcollector.fanout//message_queue2?durable='false'autodelete='true'exclusive='false'
destination.fanoutQueue3 =
BURL:fanout://testcollector.fanout//message_queue3?durable='false'autodelete='true'exclusive='false'
-
I tried to connect two consumers to message_queue1 and I get the following
error:
INFO org.apache.qpid.client.AMQConnection - Closing AMQConnection due to
:org.apache.qpid.AMQException: ch=0 id=0
ExecutionException(errorCode=RESOURCE_LOCKED, commandId=6, classCode=4,
commandCode=7, fieldIndex=0, description=resource-locked: Queue
message_queue1 has an exclusive consumer. No more consumers allowed.
(qpid/broker/Queue.cpp:385), errorInfo={}) [error code 405: Already exists]
I checked the configuration on AMQP Server and it says that message_queue1
is a non-exclusive queue.
-bash-4.1$ qpid-stat -q
Queues
queue dur autoDel excl msg msgIn
msgOut bytes bytesIn bytesOut cons bind
message_queue1 Y 122
21 15324 309 1 2
Here is the code I am using.
Producer.java: (queueName=fanoutQueue)
Properties properties = new Properties();
properties.load(this.getClass().getResourceAsStream(fanout.properties));
//Create the initial context
Context ctx = new InitialContext(properties);
// look up destination and connection factory
Destination destination = (Destination)ctx.lookup(queueName);
ConnectionFactory conFac =
(ConnectionFactory)ctx.lookup(qpidConnectionfactory);
Connection connection = conFac.createConnection();
Session session = connection.createSession(false,
Session.AUTO_ACKNOWLEDGE);
MessageProducer messageProducer =
session.createProducer(destination);
TextMessage message;
// Send a series of messages in a loop
int i=0;
while(true) {
message = session.createTextMessage(Hello world! +i);
messageProducer.send(message, DeliveryMode.NON_PERSISTENT,
Message.DEFAULT_PRIORITY, 60*1000);
i++;
Thread.sleep(1000);
}
---
Consumer.java: (queueName=fanoutQueue1)
-
Properties properties = new Properties();
properties.load(this.getClass().getResourceAsStream(fanout.properties));
//Create the initial context
Context ctx = new InitialContext(properties);
// look up destination and connection factory
Destination destination = (Destination)ctx.lookup(queueName);
ConnectionFactory conFac =
(ConnectionFactory)ctx.lookup(qpidConnectionfactory);
Connection connection = conFac.createConnection();
connection.setExceptionListener(new ExceptionListener()
{
public void onException(JMSException jmse)
{
System.err.println(CLASS + : The sample received an
exception
through the ExceptionListener);
System.exit(0);
}
});
System.out.println(CLASS + : Creating a non-transacted,
auto-acknowledged
session);
Session session = connection.createSession(false,
Session.AUTO_ACKNOWLEDGE);
MessageConsumer messageConsumer =
session.createConsumer(destination);
connection.start();
while(true) {
TextMessage message =
(TextMessage)messageConsumer.receive(1000);
if(message != null)
