[jira] [Commented] (QPID-3342) Rationalise transport layer by introducing common interfaces shared by all protocols
[ https://issues.apache.org/jira/browse/QPID-3342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061354#comment-13061354 ] Robbie Gemmell commented on QPID-3342: -- Hi Rajith, This work is similar to the work Andrew was doing, yes, but he isn't working on it anymore and this is fresh implementation with some commonality. The NetworkTransport being mentioned is different one, partially replacing the existing one (NetworkTransport extended by IncomingNetworkTransport and OutgoingNetworkTransport). There is a final JIRA to be raised to make these transports using these new interfaces pluggable in similar fashion to what you did. > Rationalise transport layer by introducing common interfaces shared by all > protocols > > > Key: QPID-3342 > URL: https://issues.apache.org/jira/browse/QPID-3342 > Project: Qpid > Issue Type: Improvement > Components: Java Broker, Java Client, Java Common >Reporter: Keith Wall >Assignee: Robbie Gemmell > Fix For: 0.13 > > Attachments: > 0002-QPID-3342-rationalise-the-existing-0-10-transport-co.patch, > 0003-QPID-3342-transition-TCP-based-Mina-transport-for-0-.patch > > > Refactor the transport stack by introducing two new interfaces > NetworkTransport and NetworkConnection. Remove dependencies between > IoSender and IoReceiver. -- 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-3342) Rationalise transport layer by introducing common interfaces shared by all protocols
[ https://issues.apache.org/jira/browse/QPID-3342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061364#comment-13061364 ] Robbie Gemmell commented on QPID-3342: -- Small elaboration on the above, Keith and I have been working on this together as discussed on the mailing list previously. It is being attached here to grant the appropriate permissions for inclusion. > Rationalise transport layer by introducing common interfaces shared by all > protocols > > > Key: QPID-3342 > URL: https://issues.apache.org/jira/browse/QPID-3342 > Project: Qpid > Issue Type: Improvement > Components: Java Broker, Java Client, Java Common >Reporter: Keith Wall >Assignee: Robbie Gemmell > Fix For: 0.13 > > Attachments: > 0002-QPID-3342-rationalise-the-existing-0-10-transport-co.patch, > 0003-QPID-3342-transition-TCP-based-Mina-transport-for-0-.patch > > > Refactor the transport stack by introducing two new interfaces > NetworkTransport and NetworkConnection. Remove dependencies between > IoSender and IoReceiver. -- 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-3343) Refactor testprofiles to allow for the testing of all protocols with client/broker residing in the same VM.
[ https://issues.apache.org/jira/browse/QPID-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061369#comment-13061369 ] Robbie Gemmell commented on QPID-3343: -- Keith and I have been working on this together as discussed on the mailing list previously. It is being attached here to grant the appropriate permissions for inclusion. > Refactor testprofiles to allow for the testing of all protocols with > client/broker residing in the same VM. > --- > > Key: QPID-3343 > URL: https://issues.apache.org/jira/browse/QPID-3343 > Project: Qpid > Issue Type: Improvement > Components: Java Tests >Reporter: Keith Wall >Assignee: Keith Wall > Fix For: 0.13 > > Attachments: > 0007-QPID-3343-refactor-test-profiles-to-allow-testing-wi.patch > > > Refactor the test framework to make use of the interface offered by QPID-2815 > to start/stop the broker within the JVM. Create new test profiles to test > 0-9-1 and 0-10 within the same JVM considerably reducing time taken for > test-cycle. > Adopt new naming scheme for test profile names. > Remove support for the vm:// transport. -- 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-3026) The ApplicationRegistry object should be a singleton
[ https://issues.apache.org/jira/browse/QPID-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061370#comment-13061370 ] Robbie Gemmell commented on QPID-3026: -- Keith and I have been working on this together as discussed on the mailing list previously. It is being attached here to grant the appropriate permissions for inclusion. > The ApplicationRegistry object should be a singleton > > > Key: QPID-3026 > URL: https://issues.apache.org/jira/browse/QPID-3026 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Affects Versions: 0.9 >Reporter: Andrew Kennedy >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 0.11 > > Attachments: > 0005-QPID-3026-remove-incomplete-support-for-multiple-App.patch > > > The ApplicationRegistry can currently have multiple instances, in order to > cater for multiple brokers in the same VM. However, *many* parts of the code > simply call ApplcationRegistry.getInstance() to obtain a reference, meaning > multiple instances are ignored. The only time this is ever useful is for > certain types of tests, therefore the capability to have multiple broker > instances should be removed. > Any tests that require multiple brokers can start a VM broker and an > external, or two external brokers. In general, test-only code should not be > made available to the rest of the application. -- 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-2815) Refactor broker startup to enable a uniform method of starting the broker
[ https://issues.apache.org/jira/browse/QPID-2815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061368#comment-13061368 ] Robbie Gemmell commented on QPID-2815: -- Keith and I have been working on this together as discussed on the mailing list previously. It is being attached here to grant the appropriate permissions for inclusion. > Refactor broker startup to enable a uniform method of starting the broker > - > > Key: QPID-2815 > URL: https://issues.apache.org/jira/browse/QPID-2815 > Project: Qpid > Issue Type: Improvement >Affects Versions: 0.7 >Reporter: Andrew Kennedy >Assignee: Keith Wall > Fix For: 0.13 > > Attachments: > 0006-QPID-2815-refactor-broker-startup-to-present-a-clean.patch > > > Update the way the broker is started to decouple it from any particular > protocol version or transport. -- 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-3341) Remove unused/dead transport code
[ https://issues.apache.org/jira/browse/QPID-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061366#comment-13061366 ] Robbie Gemmell commented on QPID-3341: -- Keith and I have been working on this together as discussed on the mailing list previously. It is being attached here to grant the appropriate permissions for inclusion. > Remove unused/dead transport code > - > > Key: QPID-3341 > URL: https://issues.apache.org/jira/browse/QPID-3341 > Project: Qpid > Issue Type: Improvement > Components: Java Broker, Java Client, Java Common >Reporter: Keith Wall >Assignee: Robbie Gemmell > Fix For: 0.13 > > Attachments: > 0001-QPID-3341-remove-unused-dead-transport-code-and-acco.patch > > > There are several dead sections of transport code within MINANetworkDriver > and test support classes that are no longer in use. These will be removed. > There are also several features, such as protect IO, that have been broken by > many previous commits over four+ years, and have no test coverage. These > faetures will also be removed. > This improvement will support future work to rationalise the transport > implementations. > -- 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-2815) Refactor broker startup to enable a uniform method of starting the broker
[ https://issues.apache.org/jira/browse/QPID-2815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned QPID-2815: Assignee: Robbie Gemmell (was: Keith Wall) > Refactor broker startup to enable a uniform method of starting the broker > - > > Key: QPID-2815 > URL: https://issues.apache.org/jira/browse/QPID-2815 > Project: Qpid > Issue Type: Improvement >Affects Versions: 0.7 >Reporter: Andrew Kennedy >Assignee: Robbie Gemmell > Fix For: 0.13 > > Attachments: > 0006-QPID-2815-refactor-broker-startup-to-present-a-clean.patch > > > Update the way the broker is started to decouple it from any particular > protocol version or transport. -- 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-3343) Refactor testprofiles to allow for the testing of all protocols with client/broker residing in the same VM.
[ https://issues.apache.org/jira/browse/QPID-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned QPID-3343: Assignee: Robbie Gemmell (was: Keith Wall) > Refactor testprofiles to allow for the testing of all protocols with > client/broker residing in the same VM. > --- > > Key: QPID-3343 > URL: https://issues.apache.org/jira/browse/QPID-3343 > Project: Qpid > Issue Type: Improvement > Components: Java Tests >Reporter: Keith Wall >Assignee: Robbie Gemmell > Fix For: 0.13 > > Attachments: > 0007-QPID-3343-refactor-test-profiles-to-allow-testing-wi.patch > > > Refactor the test framework to make use of the interface offered by QPID-2815 > to start/stop the broker within the JVM. Create new test profiles to test > 0-9-1 and 0-10 within the same JVM considerably reducing time taken for > test-cycle. > Adopt new naming scheme for test profile names. > Remove support for the vm:// transport. -- 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-3342) Rationalise transport layer by introducing common interfaces shared by all protocols
[ https://issues.apache.org/jira/browse/QPID-3342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061533#comment-13061533 ] Robbie Gemmell commented on QPID-3342: -- Hi Rajith Im sorry you feel that way, and have to say I disagree in general, but as some attempt at explanation: This is as mentioned above, very much in line with the work Andrew was doing previously so its design has as you mention been proposed, and has had the previous code available on branches for close to 9 months now. Given this, despite this being a reimplementation (involving less change in a more controlled fashion), I dont think this is entirely out of the blue and it seems like ample discussion had taken place and time to consider it been given. I can conceed your point about possibly putting it up for review first, although I would usually only take course for something that hadnt been given prior discussion, hadnt had any review, and had some doubt about it. I would stress that this (and Andrews code before it) has already seen *weeks* of review from myself before I committed it, and again the previous implemtnation has been available for all to look at. Great care was taken to try and ensure consistency of the IO behaviour during the restructuring (which was actually fairly minimal for the 0-10 code path), and no IO features which were present and worked or were being used are being (permanantly) removed. Much of the change that went in was nothing to do with the IO layer alongside work, and is purely to the Java broker or associated dead Mina related features. The transports are *not* currently configurable, however as I mentioned above they will again be made so via a final JIRA (quite possibly tomorrow), in similar fashion to the way they were already. I didn't think this small delay was a particular sticking point for the rest of the code given that until these changes were made there were no two interface-compatible IO implementations available to use such plugability. > Rationalise transport layer by introducing common interfaces shared by all > protocols > > > Key: QPID-3342 > URL: https://issues.apache.org/jira/browse/QPID-3342 > Project: Qpid > Issue Type: Improvement > Components: Java Broker, Java Client, Java Common >Reporter: Keith Wall >Assignee: Robbie Gemmell > Fix For: 0.13 > > Attachments: > 0002-QPID-3342-rationalise-the-existing-0-10-transport-co.patch, > 0003-QPID-3342-transition-TCP-based-Mina-transport-for-0-.patch > > > Refactor the transport stack by introducing two new interfaces > NetworkTransport and NetworkConnection. Remove dependencies between > IoSender and IoReceiver. -- 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-3342) Rationalise transport layer by introducing common interfaces shared by all protocols
[ https://issues.apache.org/jira/browse/QPID-3342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061538#comment-13061538 ] Robbie Gemmell commented on QPID-3342: -- Cross-posted comments. Yes, that JIRA is the final piece in the puzzle. As per Andrews previous design, the pluggability will occur at the NetworkTansport level in similar fashion to the previous 'getTransport' behaviour you added, with the building and lifecycle maintenance of the Sender/Reciever pipes being the responsability of the NetworkConnections those NetworkTransports produce. > Rationalise transport layer by introducing common interfaces shared by all > protocols > > > Key: QPID-3342 > URL: https://issues.apache.org/jira/browse/QPID-3342 > Project: Qpid > Issue Type: Improvement > Components: Java Broker, Java Client, Java Common >Reporter: Keith Wall >Assignee: Robbie Gemmell > Fix For: 0.13 > > Attachments: > 0002-QPID-3342-rationalise-the-existing-0-10-transport-co.patch, > 0003-QPID-3342-transition-TCP-based-Mina-transport-for-0-.patch > > > Refactor the transport stack by introducing two new interfaces > NetworkTransport and NetworkConnection. Remove dependencies between > IoSender and IoReceiver. -- 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-3342) Rationalise transport layer by introducing common interfaces shared by all protocols
[ https://issues.apache.org/jira/browse/QPID-3342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13061578#comment-13061578 ] Robbie Gemmell commented on QPID-3342: -- These changes were done from scratch and are not from Andrews branch, but they do share a common goal and overall design. Two of the four older JIRAs I closed are not being underaken due to prior failure to make them work and our subsequent removal of the vm transport, as per recent discussion on the mailing list concerning the work. We had initially planned to reuse the old IO JIRAs, however when it came time to commit we decided it would be better to create new ones and distinguish from the earlier work because the same steps were not followed and the commits are not related enough at the code level in the way that reusing old JIRAs associated with 9 months of work on 2 old branches would seem to imply, and so we thought that to do so would be confusing for people looking at them. The code changed at the IO layer is so rarely touched and the Java broker doesnt see a whole lot of people changing it, so I didnt think a heads up to e,g. help other developers avoid conflict was necessary. > Rationalise transport layer by introducing common interfaces shared by all > protocols > > > Key: QPID-3342 > URL: https://issues.apache.org/jira/browse/QPID-3342 > Project: Qpid > Issue Type: Improvement > Components: Java Broker, Java Client, Java Common >Reporter: Keith Wall >Assignee: Robbie Gemmell > Fix For: 0.13 > > Attachments: > 0002-QPID-3342-rationalise-the-existing-0-10-transport-co.patch, > 0003-QPID-3342-transition-TCP-based-Mina-transport-for-0-.patch > > > Refactor the transport stack by introducing two new interfaces > NetworkTransport and NetworkConnection. Remove dependencies between > IoSender and IoReceiver. -- 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-3341) Remove unused/dead transport code
[ https://issues.apache.org/jira/browse/QPID-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-3341. -- Resolution: Fixed Closing out, patch applied. > Remove unused/dead transport code > - > > Key: QPID-3341 > URL: https://issues.apache.org/jira/browse/QPID-3341 > Project: Qpid > Issue Type: Improvement > Components: Java Broker, Java Client, Java Common >Reporter: Keith Wall >Assignee: Robbie Gemmell > Fix For: 0.13 > > Attachments: > 0001-QPID-3341-remove-unused-dead-transport-code-and-acco.patch > > > There are several dead sections of transport code within MINANetworkDriver > and test support classes that are no longer in use. These will be removed. > There are also several features, such as protect IO, that have been broken by > many previous commits over four+ years, and have no test coverage. These > faetures will also be removed. > This improvement will support future work to rationalise the transport > implementations. > -- 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-2815) Refactor broker startup to enable a uniform method of starting the broker
[ https://issues.apache.org/jira/browse/QPID-2815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-2815. -- Resolution: Fixed Closing out, patch applied. > Refactor broker startup to enable a uniform method of starting the broker > - > > Key: QPID-2815 > URL: https://issues.apache.org/jira/browse/QPID-2815 > Project: Qpid > Issue Type: Improvement >Affects Versions: 0.7 >Reporter: Andrew Kennedy >Assignee: Robbie Gemmell > Fix For: 0.13 > > Attachments: > 0006-QPID-2815-refactor-broker-startup-to-present-a-clean.patch > > > Update the way the broker is started to decouple it from any particular > protocol version or transport. -- 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-3026) The ApplicationRegistry object should be a singleton
[ https://issues.apache.org/jira/browse/QPID-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-3026. -- Resolution: Fixed Closing out, patch applied. > The ApplicationRegistry object should be a singleton > > > Key: QPID-3026 > URL: https://issues.apache.org/jira/browse/QPID-3026 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Affects Versions: 0.9 >Reporter: Andrew Kennedy >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 0.11 > > Attachments: > 0005-QPID-3026-remove-incomplete-support-for-multiple-App.patch > > > The ApplicationRegistry can currently have multiple instances, in order to > cater for multiple brokers in the same VM. However, *many* parts of the code > simply call ApplcationRegistry.getInstance() to obtain a reference, meaning > multiple instances are ignored. The only time this is ever useful is for > certain types of tests, therefore the capability to have multiple broker > instances should be removed. > Any tests that require multiple brokers can start a VM broker and an > external, or two external brokers. In general, test-only code should not be > made available to the rest of the application. -- 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-3343) Refactor testprofiles to allow for the testing of all protocols with client/broker residing in the same VM.
[ https://issues.apache.org/jira/browse/QPID-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-3343. -- Resolution: Fixed Closing out, patch applied. > Refactor testprofiles to allow for the testing of all protocols with > client/broker residing in the same VM. > --- > > Key: QPID-3343 > URL: https://issues.apache.org/jira/browse/QPID-3343 > Project: Qpid > Issue Type: Improvement > Components: Java Tests >Reporter: Keith Wall >Assignee: Robbie Gemmell > Fix For: 0.13 > > Attachments: > 0007-QPID-3343-refactor-test-profiles-to-allow-testing-wi.patch > > > Refactor the test framework to make use of the interface offered by QPID-2815 > to start/stop the broker within the JVM. Create new test profiles to test > 0-9-1 and 0-10 within the same JVM considerably reducing time taken for > test-cycle. > Adopt new naming scheme for test profile names. > Remove support for the vm:// transport. -- 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-3325) Make it possible to access broker shutdown hook from outside
[ https://issues.apache.org/jira/browse/QPID-3325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063839#comment-13063839 ] Robbie Gemmell commented on QPID-3325: -- Hi Danushka, The work Keith referenced (QPID-3026) has now been completed, in concert with other related work on broker startup (QPID-2815). Keith's suggestion from this this JIRA was not included, but I think its a good idea and should be. My main reservation with the attached patch would be that since none of our code uses the getter and its not obvious why it should be there then it would likely just get 'cleaned up' by someone at some point. Could you let us know if the reasoning behind exposing the shutdown hook thread was as queried, and whether the suggested approach would do what you are looking for? (updated patch welcome too) Thanks, Robbie > Make it possible to access broker shutdown hook from outside > > > Key: QPID-3325 > URL: https://issues.apache.org/jira/browse/QPID-3325 > Project: Qpid > Issue Type: Improvement >Reporter: Danushka Menikkumbura >Assignee: Robbie Gemmell > Attachments: QPID-3325.patch > > -- 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-3323) Make main method throw an exception when something goes wrong at start up so that a host applicaton can act accordingly
[ https://issues.apache.org/jira/browse/QPID-3323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063879#comment-13063879 ] Robbie Gemmell commented on QPID-3323: -- Hi Danushka, The broker startup refactoring I mentioned above has now been committed (mainly QPID-2815). This provides a cleaner way to configure and start Broker instances within the same JVM as other components, giving ability for the calling applications to control exception handling and isolating the presence of System.exit() calls in the Main class, outwith the actual startup/shutdown code path. As a result of this I am going to close QPID-3323 and QPID-2794. You can see example of how to use and configure one of the new Broker instances by looking at the now significantly reduced Main class. Please let us know if you have any problems using the refactored system to achieve your goal and we can look how best to resolve the issue. Regards, Robbie > Make main method throw an exception when something goes wrong at start up so > that a host applicaton can act accordingly > --- > > Key: QPID-3323 > URL: https://issues.apache.org/jira/browse/QPID-3323 > Project: Qpid > Issue Type: Improvement >Reporter: Danushka Menikkumbura >Assignee: Robbie Gemmell > Attachments: QPID-3323.patch > > -- 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] [Closed] (QPID-3323) Make main method throw an exception when something goes wrong at start up so that a host applicaton can act accordingly
[ https://issues.apache.org/jira/browse/QPID-3323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed QPID-3323. Resolution: Not A Problem Closing out. There isn't really a matching resolution given the above, so just going with Not A Problem. > Make main method throw an exception when something goes wrong at start up so > that a host applicaton can act accordingly > --- > > Key: QPID-3323 > URL: https://issues.apache.org/jira/browse/QPID-3323 > Project: Qpid > Issue Type: Improvement >Reporter: Danushka Menikkumbura >Assignee: Robbie Gemmell > Attachments: QPID-3323.patch > > -- 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-2794) Broker shutdown logic needs changing to run inside another process
[ https://issues.apache.org/jira/browse/QPID-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063882#comment-13063882 ] Robbie Gemmell commented on QPID-2794: -- Hi Danushka, The broker startup refactoring I mentioned above has now been committed (mainly QPID-2815). This provides a cleaner way to configure and start Broker instances within the same JVM as other components, giving ability for the calling applications to control exception handling and isolating the presence of System.exit() calls in the Main class, outwith the actual startup/shutdown code path. As a result of this I am going to close QPID-3323 and QPID-2794. You can see example of how to use and configure one of the new Broker instances by looking at the now significantly reduced Main class. Please let us know if you have any problems using the refactored system to achieve your goal and we can look how best to resolve the issue. Regards, Robbie > Broker shutdown logic needs changing to run inside another process > -- > > Key: QPID-2794 > URL: https://issues.apache.org/jira/browse/QPID-2794 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Danushka Menikkumbura >Assignee: Robbie Gemmell > Attachments: QPID-2794.patch > > > At the moment the broker shutdown terminates the JVM which is a problem when > the broker runs inside another process. -- 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] [Closed] (QPID-2794) Broker shutdown logic needs changing to run inside another process
[ https://issues.apache.org/jira/browse/QPID-2794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed QPID-2794. Resolution: Not A Problem Closing out. There isn't really a matching resolution given the above, so just going with Not A Problem. > Broker shutdown logic needs changing to run inside another process > -- > > Key: QPID-2794 > URL: https://issues.apache.org/jira/browse/QPID-2794 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Danushka Menikkumbura >Assignee: Robbie Gemmell > Attachments: QPID-2794.patch > > > At the moment the broker shutdown terminates the JVM which is a problem when > the broker runs inside another process. -- 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] [Closed] (QPID-3322) Can not enable Mina IO throttling
[ https://issues.apache.org/jira/browse/QPID-3322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed QPID-3322. Resolution: Won't Fix The work I referenced above to remove dead/unused/known-defective IO features has now been committed. Having not received a response on use of ProtectIO, and based on the previous commentary about it above, it was included in the code removal. As such I am going to close this JIRA out as a wont-fix. > Can not enable Mina IO throttling > - > > Key: QPID-3322 > URL: https://issues.apache.org/jira/browse/QPID-3322 > Project: Qpid > Issue Type: Bug >Reporter: Danushka Menikkumbura >Assignee: Robbie Gemmell > Attachments: QPID-3322.patch > > -- 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-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:comment-tabpanel&focusedCommentId=13063894#comment-13063894 ] Robbie Gemmell commented on QPID-3307: -- Hi Charith, Have you made any progress on adding at least happy-path unit testing for this? It would be good to get your patch applied. Regards, Robbie > 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 >Assignee: Robbie Gemmell >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] [Commented] (QPID-2720) Qpid broker can not run inside an OSGi container
[ https://issues.apache.org/jira/browse/QPID-2720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13063902#comment-13063902 ] Robbie Gemmell commented on QPID-2720: -- Hi Danushka, The work I have referenced in some of your other JIRAs, refactoring of the broker startup via QPID-2815, would seem to offer a way to resolve the above issue with your patch. Instead of using a static method to manipulate the PluginManager directly, you could add a method on the BrokerOptions object to pass the context, or alternatively an instance method to the Broker object that could be used to set the BundleContext before starting the instance, which could then be provided to/sourced by the PluginManager for that Broker instance. This would allow leveraging the new Broker + BrokerOptions combination as a singluar front end for starting the broker and configuring it to function as desired. Regards, Robbie > Qpid broker can not run inside an OSGi container > > > Key: QPID-2720 > URL: https://issues.apache.org/jira/browse/QPID-2720 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Reporter: Danushka Menikkumbura >Assignee: Robbie Gemmell > Fix For: 0.13 > > Attachments: QPID-2720-V2.patch, QPID-2720-V3.patch, QPID-2720.patch > > -- 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-2818) Make Transport mechanisms into OSGi plugins
[ https://issues.apache.org/jira/browse/QPID-2818?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-2818: - Fix Version/s: (was: 0.11) Future Bumping to the 'future' version. > Make Transport mechanisms into OSGi plugins > --- > > Key: QPID-2818 > URL: https://issues.apache.org/jira/browse/QPID-2818 > Project: Qpid > Issue Type: Improvement > Components: Java Broker, Java Client >Reporter: Andrew Kennedy > Fix For: Future > > > Make the transport mechanism pluggable using OSGi on both the broker and 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-3156) Java client implementation of the Address syntax for Destinations throws a ClassCastException when used with the documented 'True' or 'False' values for node durability
[
https://issues.apache.org/jira/browse/QPID-3156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell resolved QPID-3156.
--
Resolution: Fixed
Closing out, changes were committed long ago to address this.
> Java client implementation of the Address syntax for Destinations throws a
> ClassCastException when used with the documented 'True' or 'False' values for
> node durability
>
>
> Key: QPID-3156
> URL: https://issues.apache.org/jira/browse/QPID-3156
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
>Affects Versions: 0.6, 0.7, 0.8, 0.9, 0.10
>Reporter: Robbie Gemmell
> Fix For: 0.11
>
> Attachments:
> 0001-QPID-3156-Use-MapAccessor-to-retrieve-Boolean-proper.patch
>
>
> The Java client implementation of the Address syntax for destinations throws
> a ClassCastException when used with the documented
> (http://qpid.apache.org/books/0.8/Programming-In-Apache-Qpid/html/ch02s04.html#section-address-string-bnf)
> 'True' or 'False' values for node durability, instead requiring that users
> specify 'true' or 'false' as the value to achieve the desired effect. The
> former is parsed as a boolean value by the AddressParser whereas the later is
> parsed as a String, but the AddressHelper implementation expects the durable
> property to be defined as a String and casts the value as such without doing
> an instanceof check after retrieving it from an untyped Map, thus leading to
> the ClassCastException observed.
> Ideally I would suggest the parser/helper should accept both variations going
> forward, thus preserving compatibility for anyone with already functional
> code and also making it possible for users to use whichever variant they
> prefer because e.g. it is best suited to a particular implementation language
> idiom.
> Reported by a user via the dev list:
> I tried to create a durable queue like this
> queue = queueSession.createQueue("myQueue;{create:always, node:{durable:
> True}}");
> QueueSender queueSender = queueSession.createSender(queue);
> queueSender.send(textMessage);
> and getting this exception.
> Caused by: java.lang.ClassCastException: java.lang.Boolean cannot be cast to
> java.lang.String
> at
> org.apache.qpid.client.messaging.address.AddressHelper.getDurability(AddressHelper.java:237)
> at
> org.apache.qpid.client.messaging.address.AddressHelper.fillInCommonNodeArgs(AddressHelper.java:222)
> at
> org.apache.qpid.client.messaging.address.AddressHelper.createQueueNode(AddressHelper.java:215)
> at
> org.apache.qpid.client.messaging.address.AddressHelper.getSourceNode(AddressHelper.java:254)
> at
> org.apache.qpid.client.AMQDestination.rebuildTargetAndSourceNodes(AMQDestination.java:888)
> at
> org.apache.qpid.client.AMQSession_0_10.resolveAddressType(AMQSession_0_10.java:1272)
> thanks,
> Amila.
--
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-2476) Complete ACL implementation for 0-10 code path
[ https://issues.apache.org/jira/browse/QPID-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-2476: - Fix Version/s: (was: 0.11) 0.13 > Complete ACL implementation for 0-10 code path > -- > > Key: QPID-2476 > URL: https://issues.apache.org/jira/browse/QPID-2476 > Project: Qpid > Issue Type: New Feature > Components: Java Broker >Affects Versions: 0.7, 0.9 >Reporter: Andrew Kennedy > Labels: qpid, security > Fix For: 0.13 > > Attachments: acl.txt, method-considered-harmful.txt, method-redux.txt > > Original Estimate: 336h > Remaining Estimate: 336h > > Complete ACL implementation for 0-10 code path, providing an ACLv2 > implementation that covers the following features/requirements: > - Best practice security design > - Support for roles/groups > - Appropriate for standard stores for authorisation credentials (e.g. LDAP, > Kerberos) > - Expressable as XML > - Easy to store/backup/extract ACL config > - Exception handling catching at point of ACL application and return to > client via Connection ExceptionListener with correct error code, log failure > in broker > - No significant performance cost on publish, permissions to be cached > - Security handled at correct level of abstraction internally > - Interoperability with existing ACLv2 -- 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-2498) Upgrade Mina to 1.1.7
[ https://issues.apache.org/jira/browse/QPID-2498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-2498: - Fix Version/s: (was: 0.11) 0.13 Assignee: Robbie Gemmell (was: Andrew Kennedy) > Upgrade Mina to 1.1.7 > - > > Key: QPID-2498 > URL: https://issues.apache.org/jira/browse/QPID-2498 > Project: Qpid > Issue Type: Improvement > Components: Java Broker, Java Client >Affects Versions: 0.6 >Reporter: Emmanuel Bourg >Assignee: Robbie Gemmell > Fix For: 0.13 > > Attachments: mina-update.patch, mina-upgrade.patch > > > Upgrading Mina to 1.1.7 would allow the removal of > backport-util-concurrent.jar from the dependencies. -- 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-3231) timeout period used during synchronous 0-8/0-9 operations may begin before transmission of the operation occurs
[ https://issues.apache.org/jira/browse/QPID-3231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-3231: - Affects Version/s: 0.11 Fix Version/s: (was: 0.11) 0.13 > timeout period used during synchronous 0-8/0-9 operations may begin before > transmission of the operation occurs > --- > > Key: QPID-3231 > URL: https://issues.apache.org/jira/browse/QPID-3231 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.5, 0.6, 0.7, 0.8, 0.9, 0.10, 0.11 >Reporter: Robbie Gemmell > Fix For: 0.13 > > > The timeout period used during synchronous 0-8/0-9 operations may begin > before transmission of the operation actually occurs. > If a large amount of data is sent (asynchronously) before a synchronous > operation is performed (e.g session commit) then this data may still be in > the effectively unbounded network buffers and delay transmission of the > frames for the synchronous operation. However, the timer used to indicate > timeout of the synchronous operation begins as soon as the asynchronous send > operation for it returns, and so could also include time spent transmitting > the previous data asynchronously. This would mean that the synchronous > operation is timed out prematurely, and may later succeed once the command is > actually placed on the wire. > We should ensure that the send method only returns once the data is actually > on the wire when it used for synchronous operations with timeouts. -- 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-3255) JMX Console to be changed to remove use of deprecated UserManagement methods
[ https://issues.apache.org/jira/browse/QPID-3255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-3255: - Affects Version/s: 0.12 Fix Version/s: (was: 0.11) 0.13 Assignee: Robbie Gemmell > JMX Console to be changed to remove use of deprecated UserManagement methods > > > Key: QPID-3255 > URL: https://issues.apache.org/jira/browse/QPID-3255 > Project: Qpid > Issue Type: Sub-task > Components: Java Management : JMX Console >Affects Versions: 0.11, 0.12 >Reporter: Keith Wall >Assignee: Robbie Gemmell > Fix For: 0.13 > > > QPID-2759 deprecated some JMX UserManagement operations whilst removing > support for the old jmxremote.access file. > This task is to change the Java Management Console to cease using those > deprecated methods and remove the on-screen widgets pertaining to access > management. -- 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-3274) Jenkins CI - JMX test failures under Solaris
[
https://issues.apache.org/jira/browse/QPID-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell updated QPID-3274:
-
Fix Version/s: (was: 0.11)
Assignee: Robbie Gemmell (was: Keith Wall)
> Jenkins CI - JMX test failures under Solaris
>
>
> Key: QPID-3274
> URL: https://issues.apache.org/jira/browse/QPID-3274
> Project: Qpid
> Issue Type: Sub-task
> Components: Java Tests
>Affects Versions: 0.11
> Environment: Solaris/Hudson
>Reporter: Keith Wall
>Assignee: Robbie Gemmell
> Labels: Hudson, Jenkins, Solaris
>
> Andrew K noticed whilst setting up Qpid under Hudson that the JMX tests fail
> under Hudson on Solaris.
> The first error was:
> https://builds.apache.org/hudson/view/M-R/view/Qpid/job/qpid-java-build/3/testReport/junit/org.apache.qpid.management.jmx/ManagementActorLoggingTest/testJMXManagementConsoleConnection/
> {code}
> java.net.MalformedURLException: Bad URL path:
> _solaris:30099/jndi/rmi://hudson_solaris:2/jmxrmi
> {code}
> followed by many instances of:
> https://builds.apache.org/hudson/view/M-R/view/Qpid/job/qpid-java-build/3/testReport/junit/org.apache.qpid.management.jmx/ManagementActorLoggingTest/testConnectionCloseViaManagement/
> {code}
> internal error: ObjID already in use
> {code}
> The full list of test failures is recorded here:
> https://builds.apache.org/hudson/view/M-R/view/Qpid/job/qpid-java-build/3/#showFailuresLink
> I tried the test cases standalone under OpenSolaris 11 and could not
> reproduce the problem.
> However, I notice that the initial error looks very much like the issue
> discussed here:
> http://apache-qpid-users.2158936.n2.nabble.com/Run-qpid-0-6-broker-error-in-Linux-td5517015.html
> Is the problem just being caused by the hostname on the Solaris host in the
> Jenkins build farm?
--
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-3149) Set up Hudson Continuous Integration
[ https://issues.apache.org/jira/browse/QPID-3149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-3149: - Affects Version/s: (was: 0.11) Fix Version/s: (was: 0.11) > Set up Hudson Continuous Integration > > > Key: QPID-3149 > URL: https://issues.apache.org/jira/browse/QPID-3149 > Project: Qpid > Issue Type: Task > Components: Build Tools >Reporter: Andrew Kennedy >Assignee: Andrew Kennedy >Priority: Minor > Labels: build, hudson, qpid > > Set up a Continuous Integration build environment for Java and C++ with full > unit, system and integration test suites being run, as well as the Python > test kit. This will use the ASF Hudson infrastructure, and will build on both > Unix and Windows environments. See here for details: > http://wiki.apache.org/general/Hudson -- 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-3052) Java test profiles do not effectively test all AMQP protocol versions
[ https://issues.apache.org/jira/browse/QPID-3052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-3052: - Affects Version/s: 0.12 0.11 0.10 Fix Version/s: (was: 0.11) 0.13 > Java test profiles do not effectively test all AMQP protocol versions > - > > Key: QPID-3052 > URL: https://issues.apache.org/jira/browse/QPID-3052 > Project: Qpid > Issue Type: Bug > Components: Java Tests >Affects Versions: 0.9, 0.10, 0.11, 0.12 >Reporter: Andrew Kennedy >Assignee: Andrew Kennedy >Priority: Minor > Fix For: 0.13 > > > The Java test profiles assume that, particularly default one for InVm > transports, the 0-10 protocol will fail, causing renegotiation. If 0-10 InVm > support is added then the default protocol will use this. It seems to make > more sense to specify exactly the version the client and the broker should > announce, and force renegotiation explicitly by disabling various protocol > versions on the command line when starting an external Java broker. Note that > this is not possible to specify for the InVm profiles anyway. Also, the only > protocol that is ever tested will be the highest supported by both broker and > client, therefore this is AMQP 0-9-1. In order for the tests not to do > surprising things when new protocol versions are added, I think that setting > versions explicitly is the best idea. I woulsd also like to add an explicit > 0-8 test profile for both InVM and external Java brokers, in order to > exercise and get coverage on this code. > In future, I recommend that some form of combinatorial profile system be > investigated for the test subsystem, allowing the required protocol, broker > type and so on to be specified separately. -- 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-3113) ChannelCloseTest should be excluded from 0-10 test profiles properly
[ https://issues.apache.org/jira/browse/QPID-3113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-3113: - Issue Type: Test (was: Bug) Summary: ChannelCloseTest should be excluded from 0-10 test profiles properly (was: ChannelCloseTest should be excluded from test profiles properly) > ChannelCloseTest should be excluded from 0-10 test profiles properly > > > Key: QPID-3113 > URL: https://issues.apache.org/jira/browse/QPID-3113 > Project: Qpid > Issue Type: Test > Components: Java Tests >Affects Versions: 0.9 >Reporter: Andrew Kennedy >Assignee: Andrew Kennedy >Priority: Minor > Fix For: 0.11 > > > ChannelCloseTest should use the Excludes file mechanism to ensure it is not > run for 0-10 profiles, and should also not be restricted to VM broker profiles -- 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-3113) ChannelCloseTest should be excluded from 0-10 test profiles properly
[ https://issues.apache.org/jira/browse/QPID-3113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-3113. -- Resolution: Fixed > ChannelCloseTest should be excluded from 0-10 test profiles properly > > > Key: QPID-3113 > URL: https://issues.apache.org/jira/browse/QPID-3113 > Project: Qpid > Issue Type: Test > Components: Java Tests >Affects Versions: 0.9 >Reporter: Andrew Kennedy >Assignee: Andrew Kennedy >Priority: Minor > Fix For: 0.11 > > > ChannelCloseTest should use the Excludes file mechanism to ensure it is not > run for 0-10 profiles, and should also not be restricted to VM broker profiles -- 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-3157) 'removed' subscriptions may be held in memory by the queues SubscriptionList or 'lastSubscriptionNode' reference
[ https://issues.apache.org/jira/browse/QPID-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-3157: - Affects Version/s: 0.12 0.11 Fix Version/s: (was: 0.11) 0.13 > 'removed' subscriptions may be held in memory by the queues SubscriptionList > or 'lastSubscriptionNode' reference > > > Key: QPID-3157 > URL: https://issues.apache.org/jira/browse/QPID-3157 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.5, 0.6, 0.7, 0.8, 0.9, 0.10, 0.11, 0.12 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Critical > Fix For: 0.13 > > > subscriptions 'removed' from a queue subscription list are only marked > deleted and can not actually bereleased from memory until the head of the > subscription list advances beyond them. Additionally and perhaps more > troublesome, a queues 'lastSubscriptionNode' can refer to a particular > subscription but hold *all* subscequent subscriptions in memory whether they > have been deleted or not and regardless whether the head of the > SubscriptionList has advanced beyond them, > As a result any memory in use by the now-closed subscription will not be > released until the queue is deleted, or all the subscriptions prior to it are > closed and removed from the list *and* the 'lastSubscriptionNode' advances > beyond them.. This also holds the associated ServerSession in memory, which > is currently a rather heavyweight object. > This issue is further compounded when the queue has a backlog of messages and > consumers are then created, used to recieve one message, and closed. In this > scenario the broker sends the client as many messages as it can prefetch, > leading to creation of up to MessageTransfer > commands, all which are recorded in the ServerSession but then left retained > as 'unprocessed' in the closed session, which might be held in memory as > described above. This results in an explosion in the number of > MessageTransfer commands retained in memory as each message can have up to > MessageTransfer commands associated with it before it is > eventually consumed by a client and all of thse will also be retained in > memory by a 'removed' but not deleted subscription. The last effect can be > combated by restricting the preftech size (eg appending &maxprefetch='1' to > the connection url). -- 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-2693) Broker instability with the topic exchange
[ https://issues.apache.org/jira/browse/QPID-2693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-2693: - Affects Version/s: 0.12 0.11 Fix Version/s: (was: 0.11) 0.13 > Broker instability with the topic exchange > -- > > Key: QPID-2693 > URL: https://issues.apache.org/jira/browse/QPID-2693 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.7, 0.8, 0.9, 0.10, 0.11, 0.12 > Environment: java version "1.6.0_12" > Java(TM) SE Runtime Environment (build 1.6.0_12-b04) > Java HotSpot(TM) 64-Bit Server VM (build 11.2-b01, mixed mode) > Linux 2.6.24-11-pve #1 SMP PREEMPT Fri May 14 09:28:08 CEST 2010 x86_64 > GNU/Linux >Reporter: Emmanuel Bourg >Assignee: Robbie Gemmell >Priority: Critical > Fix For: 0.13 > > Attachments: qpid-dump.txt, qpid-log.txt > > > I've noticed an instability of the Java broker when sending a high volume of > messages to the topic exchange. The messages are non acked, non durable. > After about 15 minutes the messages can no longer be dispatched and the > client gets this exception: > org.apache.qpid.transport.SessionException: timed out waiting for sync: > complete = 77824, point = 77825 > at org.apache.qpid.transport.Session.sync(Session.java:743) > at org.apache.qpid.transport.Session.sync(Session.java:712) > at org.apache.qpid.transport.Session.invoke(Session.java:672) > at org.apache.qpid.transport.Session.invoke(Session.java:518) > at > org.apache.qpid.transport.SessionInvoker.messageTransfer(SessionInvoker.java:96) > at org.apache.qpid.transport.Session.messageTransfer(Session.java:880) > And in the server log I get these exceptions: > 2010-06-25 02:48:48,005 [ERROR] Exception thrown and no ProtocolEngine to > handle it > org.apache.qpid.transport.SessionException: timed out waiting for completion > at org.apache.qpid.transport.Session.invoke(Session.java:635) > at > org.apache.qpid.server.transport.ServerSession.sendMessage(ServerSession.java:180) > at > org.apache.qpid.server.subscription.Subscription_0_10.send(Subscription_0_10.java:573) > at > org.apache.qpid.server.queue.SimpleAMQQueue.deliverMessage(SimpleAMQQueue.java:715) > at > org.apache.qpid.server.queue.SimpleAMQQueue.deliverToSubscription(SimpleAMQQueue.java:658) > at > org.apache.qpid.server.queue.SimpleAMQQueue.enqueue(SimpleAMQQueue.java:611) > at > org.apache.qpid.server.queue.SimpleAMQQueue.enqueue(SimpleAMQQueue.java:536) > at > org.apache.qpid.server.transport.ServerSession$1.postCommit(ServerSession.java:157) > at > org.apache.qpid.server.txn.AutoCommitTransaction.enqueue(AutoCommitTransaction.java:151) > at > org.apache.qpid.server.transport.ServerSession.enqueue(ServerSession.java:146) > at > org.apache.qpid.server.transport.ServerSessionDelegate.messageTransfer(ServerSessionDelegate.java:287) > at > org.apache.qpid.server.transport.ServerSessionDelegate.messageTransfer(ServerSessionDelegate.java:96) > at > org.apache.qpid.transport.MessageTransfer.dispatch(MessageTransfer.java:103) > at > org.apache.qpid.transport.SessionDelegate.command(SessionDelegate.java:46) > at > org.apache.qpid.server.transport.ServerSessionDelegate.command(ServerSessionDelegate.java:110) > at > org.apache.qpid.server.transport.ServerSessionDelegate.command(ServerSessionDelegate.java:96) > at org.apache.qpid.transport.Method.delegate(Method.java:159) > at org.apache.qpid.transport.Session.received(Session.java:487) > at org.apache.qpid.transport.Connection.dispatch(Connection.java:377) > at > org.apache.qpid.transport.ConnectionDelegate.handle(ConnectionDelegate.java:64) > at > org.apache.qpid.transport.ConnectionDelegate.handle(ConnectionDelegate.java:40) > at > org.apache.qpid.transport.MethodDelegate.messageTransfer(MethodDelegate.java:113) > at > org.apache.qpid.transport.MessageTransfer.dispatch(MessageTransfer.java:103) > at > org.apache.qpid.transport.ConnectionDelegate.command(ConnectionDelegate.java:54) > at > org.apache.qpid.transport.ConnectionDelegate.command(ConnectionDelegate.java:40) > at org.apache.qpid.transport.Method.delegate(Method.java:159) > at org.apache.qpid.transport.Connection.received(Connection.java:342) > at org.apache.qpid.transport.Connection.received(Connection.java:55) > at org.apache.qpid.transport.network.Assembler.emit(Assembler.java:98) > at > org.apache.qpid.transport.network.Assembler.assemble(Assembler.java:220) > at > org.apache.qpi
[jira] [Commented] (QPID-3310) Principal/Subject refactoring
[ https://issues.apache.org/jira/browse/QPID-3310?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [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: - Status: Ready To Review (was: In Progress) > 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-tabpanel&focusedCommentId=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
[jira] [Resolved] (QPID-3342) Rationalise transport layer by introducing common interfaces shared by all protocols
[ https://issues.apache.org/jira/browse/QPID-3342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-3342. -- Resolution: Fixed Patch applied, closing out. > Rationalise transport layer by introducing common interfaces shared by all > protocols > > > Key: QPID-3342 > URL: https://issues.apache.org/jira/browse/QPID-3342 > Project: Qpid > Issue Type: Improvement > Components: Java Broker, Java Client, Java Common >Reporter: Keith Wall >Assignee: Robbie Gemmell > Fix For: 0.13 > > Attachments: > 0002-QPID-3342-rationalise-the-existing-0-10-transport-co.patch, > 0003-QPID-3342-transition-TCP-based-Mina-transport-for-0-.patch > > > Refactor the transport stack by introducing two new interfaces > NetworkTransport and NetworkConnection. Remove dependencies between > IoSender and IoReceiver. -- 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-3345) Make new transport implementations pluggable
[ https://issues.apache.org/jira/browse/QPID-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned QPID-3345: Assignee: Robbie Gemmell (was: Rajith Attapattu) > 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: Robbie Gemmell > 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-3345) Make new transport implementations pluggable
[ https://issues.apache.org/jira/browse/QPID-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-3345. -- Resolution: Fixed Patch applied, closing out. > 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: Robbie Gemmell > 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] [Reopened] (QPID-2815) Refactor broker startup to enable a uniform method of starting the broker
[ https://issues.apache.org/jira/browse/QPID-2815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reopened QPID-2815: -- Reopening to add a unit test for the vastly simplified Main class to ensure the command line argument parsing is functioning as expected. > Refactor broker startup to enable a uniform method of starting the broker > - > > Key: QPID-2815 > URL: https://issues.apache.org/jira/browse/QPID-2815 > Project: Qpid > Issue Type: Improvement >Affects Versions: 0.7 >Reporter: Andrew Kennedy >Assignee: Robbie Gemmell > Fix For: 0.13 > > Attachments: > 0006-QPID-2815-refactor-broker-startup-to-present-a-clean.patch > > > Update the way the broker is started to decouple it from any particular > protocol version or transport. -- 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-2815) Refactor broker startup to enable a uniform method of starting the broker
[ https://issues.apache.org/jira/browse/QPID-2815?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned QPID-2815: Assignee: Keith Wall (was: Robbie Gemmell) Hi Keith, could you review this latest change and close out the JIRA if you are happy? I added a unit test for Main and updated the handling of the logWatch argument slightly. > Refactor broker startup to enable a uniform method of starting the broker > - > > Key: QPID-2815 > URL: https://issues.apache.org/jira/browse/QPID-2815 > Project: Qpid > Issue Type: Improvement >Affects Versions: 0.7 >Reporter: Andrew Kennedy >Assignee: Keith Wall > Fix For: 0.13 > > Attachments: > 0006-QPID-2815-refactor-broker-startup-to-present-a-clean.patch > > > Update the way the broker is started to decouple it from any particular > protocol version or transport. -- 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-2899) SelectorTest#testRuntimeSelectorError fails when using 0-10
[ https://issues.apache.org/jira/browse/QPID-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-2899: - Fix Version/s: 0.13 Summary: SelectorTest#testRuntimeSelectorError fails when using 0-10 (was: SelectorTest#testRuntimeSelectorError fails when using 0-10 because the broker fails to close the connection ) > SelectorTest#testRuntimeSelectorError fails when using 0-10 > --- > > Key: QPID-2899 > URL: https://issues.apache.org/jira/browse/QPID-2899 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.6 >Reporter: Robbie Gemmell > Fix For: 0.13 > > > org.apache.qpid.test.client.message.SelectorTest#testRuntimeSelectorError > fails when using 0-10 because the broker fails to close the connection when > the deliberate error occurs, as it does when using 0-8/0-9 > QpidBrokerTestCase behaviour is to close connections during teardown that > were created using the getConnection() utility method, and the teardown close > is failing because it tries to sync outstanding 0-10 commands with the broker > and times out. This test should already have caused the connection to be > closed due to a (deliberate) error when evaluating the selector. > However, in addition to the original exception it can be seen that there are > IllegalArgumentException occurrences immediately afterwards because the > InputHandler is continuing to process recieved data on the connection (whcih > should have been closed) and then ends up trying to add the contents of a > ByteBuffer to itself in the received() method (possibly because the exception > being throwing prevented an instance variable being set to null on completion > of a process), prompting the throwing of the IllegalArgumentException. > Commenting out the connection close during teardown reveals the test would > otherwise have failed because the connection was not closed due to the > original error as it should have been. It appears that the 0-8 broker code > closes the mina protocol session in this situation when the first exception > is thrown, but the 0-10 broker code proceeds using a crippled connection and > then gets into further difficulty. -- 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-2498) Upgrade Mina to 1.1.7
[ https://issues.apache.org/jira/browse/QPID-2498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-2498. -- Resolution: Fixed Assignee: Robbie Gemmell (was: Keith Wall) Thanks Emmanuel for the original patch (sorry we didnt get this done earlier), and Keith for the newer one. Keith's updated patch is now applied. I noticed just after committing it that the pom dependency stubs still needed to be renamed, so I have also done that. Closing this JIRA out now. > Upgrade Mina to 1.1.7 > - > > Key: QPID-2498 > URL: https://issues.apache.org/jira/browse/QPID-2498 > Project: Qpid > Issue Type: Improvement > Components: Java Broker, Java Client >Affects Versions: 0.6 >Reporter: Emmanuel Bourg >Assignee: Robbie Gemmell > Fix For: 0.13 > > Attachments: 0001-QPID-2498-Upgrade-Mina-to-1.1.7.patch, > mina-update.patch, mina-upgrade.patch > > > Upgrading Mina to 1.1.7 would allow the removal of > backport-util-concurrent.jar from the dependencies. -- 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] [Closed] (QPID-3104) why is backport-util-concurrent.jar required when running on linux java 1.6 but not windows
[ https://issues.apache.org/jira/browse/QPID-3104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed QPID-3104. Resolution: Not A Problem Assignee: Robbie Gemmell The use of backport was required due to the older mina version (1.0.1) being used on the Linux test vs the Windows test (1.1.7). Mina 1.1.7 makes use of Java5 constructs, whereas Mina 1.0.1 supports Java 1.4 and makes use of the backport classes. QPID-2498 has seen us upgrade our use of Mina to 1.1.7 on trunk for inclusion in the 0.14 release, so backport should no longer be required and this JIRA can be closed. > why is backport-util-concurrent.jar required when running on linux java 1.6 > but not windows > --- > > Key: QPID-3104 > URL: https://issues.apache.org/jira/browse/QPID-3104 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.5 > Environment: Lunix, hotpsot server JVM 1.6.0_20 > Windows XP. Hotspot client JVM 1.6.0_17 > Qpid java client 0.5 >Reporter: Jason Smith >Assignee: Robbie Gemmell >Priority: Minor > > The problem is when running my java application which includes the following > Qpid jars and dependencies, it works on Windows but with the same deployment > lib it fails when running on Linux. > 1. I have to add backport 3.0 jar which Im not sure why since I didn't have > to in my Windows sandbox. > 2. apache mina 1.1.7 doesn't work with Qpid 0.5, I had to use mina 1.0.1 > This is an acceptable solutions but I'm not sure why. Part of the reason is > I have other libraries that will perform much better when using using the > latest mina 1.1.7 on java 6. > On Windows XP - these jars cause no problems > mina-core-1.1.7.jar > qpid-all.jar > qpid-client-0.5.jar > qpid-common-0.5.jar > geronimo-jms_1.1_spec-1.0.jar > On Linux - I have to add these jars in order for Qpid to work, backport was > needed and mina needed a downgrade > mina-core-1.0.1.jar > backport-util-concurrent.jar > qpid-all.jar > qpid-client-0.5.jar > qpid-common-0.5.jar > geronimo-jms_1.1_spec-1.0.jar -- 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-3283) Make AuthenticationManager pluggable
[ https://issues.apache.org/jira/browse/QPID-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-3283. -- Resolution: Fixed Assignee: Robbie Gemmell (was: Keith Wall) Looks good to me, patch applied. > Make AuthenticationManager pluggable > > > Key: QPID-3283 > URL: https://issues.apache.org/jira/browse/QPID-3283 > Project: Qpid > Issue Type: Improvement > Components: Java Broker >Reporter: Keith Wall >Assignee: Robbie Gemmell > Fix For: 0.13 > > Attachments: > 0001-QPID-3283-Make-Authentication-Manager-pluggable.patch > > > This improvement forms part of the proposal I made to the Qpid Developer List > on 2011-05-16 in the posting entitled "Java Broker: Pluggable Authentication > Managers". > The existing AuthenticationManager and configuration classes will be > refactored to allow a user to choose an implementation of > AuthenticationManager through new elements in the config.xml. > Existing use-cases (that is authentication against the etc/passwd file) will > be maintained by plugging-in the PrincipalDatabaseAuthenticationManager > implementation. Future implementations of AuthenticationManager could then > allow authentication to be delegated to an external system such as an LDAP > Directory. > This change *will* alter the format of the config.xml file. Existing users > of <=0-12 will need to edit their config.xml when upgrading. Documentation > will be updated to guide upgraders and helpful error messages will gently > reject older configure files. > See also: > https://cwiki.apache.org/confluence/display/qpid/Java+Pluggable+Authentication+Managers -- 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-1347) Broker doesn't clearly report missing configuration files such as password file.
[ https://issues.apache.org/jira/browse/QPID-1347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-1347. -- Resolution: Fixed Fix Version/s: 0.13 Assignee: Robbie Gemmell Resolved via QPID-3283 > Broker doesn't clearly report missing configuration files such as password > file. > > > Key: QPID-1347 > URL: https://issues.apache.org/jira/browse/QPID-1347 > Project: Qpid > Issue Type: Bug > Components: Java Broker, Starter >Affects Versions: M3 >Reporter: Martin Ritchie >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 0.13 > > > If the password file is missing on startup the the following exception is > shown: > Error configuring message broker: > org.apache.commons.configuration.ConfigurationException: > java.lang.reflect.InvocationTargetException > 2008-09-26 15:14:56,529 ERROR [main] server.Main (Main.java:206) - Error > configuring message broker: > org.apache.commons.configuration.ConfigurationException: > java.lang.reflect.InvocationTargetException > org.apache.commons.configuration.ConfigurationException: > java.lang.reflect.InvocationTargetException > at > org.apache.qpid.server.security.auth.database.ConfigurationFilePrincipalDatabaseManager.initialisePrincipalDatabase(ConfigurationFilePrincipalDatabaseManager.java:158) > at > org.apache.qpid.server.security.auth.database.ConfigurationFilePrincipalDatabaseManager.initialisePrincipalDatabases(ConfigurationFilePrincipalDatabaseManager.java:87) > at > org.apache.qpid.server.security.auth.database.ConfigurationFilePrincipalDatabaseManager.(ConfigurationFilePrincipalDatabaseManager.java:56) > at > org.apache.qpid.server.registry.ConfigurationFileApplicationRegistry.initialise(ConfigurationFileApplicationRegistry.java:117) > at > org.apache.qpid.server.registry.ApplicationRegistry.initialise(ApplicationRegistry.java:79) > at > org.apache.qpid.server.registry.ApplicationRegistry.initialise(ApplicationRegistry.java:67) > at org.apache.qpid.server.Main.startup(Main.java:260) > at org.apache.qpid.server.Main.execute(Main.java:196) > at org.apache.qpid.server.Main.(Main.java:96) > at org.apache.qpid.server.Main.main(Main.java:454) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90) > Caused by: java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.qpid.server.security.auth.database.ConfigurationFilePrincipalDatabaseManager.initialisePrincipalDatabase(ConfigurationFilePrincipalDatabaseManager.java:148) > ... 14 more > Caused by: java.io.FileNotFoundException: Cannot find password file > /home/ritchiem/support/Stars/707/work/cfg/qpid.passwd > at > org.apache.qpid.server.security.auth.database.Base64MD5PasswordFilePrincipalDatabase.setPasswordFile(Base64MD5PasswordFilePrincipalDatabase.java:109) > ... 19 morere > The user must read all the way though to the Caused by section to find the > real problem. > This error could be processed on the broker and more appropriate text shown. -- 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-3359) FailoverMethodTest.testNoFailover unreliable since QPID-2815
[ https://issues.apache.org/jira/browse/QPID-3359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-3359. -- Resolution: Fixed Patch applied. > FailoverMethodTest.testNoFailover unreliable since QPID-2815 > > > Key: QPID-3359 > URL: https://issues.apache.org/jira/browse/QPID-3359 > Project: Qpid > Issue Type: Bug > Components: Java Tests >Affects Versions: 0.13 >Reporter: Keith Wall >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 0.13 > > Attachments: > 0001-QPID-3359-revert-testNoFailover-to-run-in-same-vm-pr.patch > > > FailoverMethodTest used to be inVM tests until QPID-2815, with removal of > ivVM, converted the test to use QpidBrokerTestCase. However, since then we > notice this test fails on slower CI boxes. It turns out the test design is > *extremely* sensitive the length of time the broker takes to start up. If > broker startup is slightly too slow, the test fails, and 'spawn' profiles > leave behind a broker process (causing subsequent tests to fail). > We will make the test a same-VM test to temporarily avoid the issue. In long > term, test needs redesigned to avoid the issue. -- 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-3255) JMX Console to be changed to remove use of deprecated UserManagement methods
[ https://issues.apache.org/jira/browse/QPID-3255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-3255: - Status: Ready To Review (was: In Progress) > JMX Console to be changed to remove use of deprecated UserManagement methods > > > Key: QPID-3255 > URL: https://issues.apache.org/jira/browse/QPID-3255 > Project: Qpid > Issue Type: Sub-task > Components: Java Management : JMX Console >Affects Versions: 0.11, 0.12 >Reporter: Keith Wall >Assignee: Robbie Gemmell > Fix For: 0.13 > > > QPID-2759 deprecated some JMX UserManagement operations whilst removing > support for the old jmxremote.access file. > This task is to change the Java Management Console to cease using those > deprecated methods and remove the on-screen widgets pertaining to access > management. -- 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-3255) JMX Console to be changed to remove use of deprecated UserManagement methods
[ https://issues.apache.org/jira/browse/QPID-3255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned QPID-3255: Assignee: Keith Wall (was: Robbie Gemmell) Hi Keith, could you review these changes please? I have removed the display of the unsupported operations from the console, and moved the old methods out to a legacy interface used only by the console when connected to older brokers. > JMX Console to be changed to remove use of deprecated UserManagement methods > > > Key: QPID-3255 > URL: https://issues.apache.org/jira/browse/QPID-3255 > Project: Qpid > Issue Type: Sub-task > Components: Java Management : JMX Console >Affects Versions: 0.11, 0.12 >Reporter: Keith Wall >Assignee: Keith Wall > Fix For: 0.13 > > > QPID-2759 deprecated some JMX UserManagement operations whilst removing > support for the old jmxremote.access file. > This task is to change the Java Management Console to cease using those > deprecated methods and remove the on-screen widgets pertaining to access > management. -- 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-3367) FileUtils improvements
[ https://issues.apache.org/jira/browse/QPID-3367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-3367. -- Resolution: Fixed Changes look good to me, patch applied. > FileUtils improvements > -- > > Key: QPID-3367 > URL: https://issues.apache.org/jira/browse/QPID-3367 > Project: Qpid > Issue Type: Improvement > Components: Java Common >Reporter: Keith Wall >Assignee: Robbie Gemmell >Priority: Minor > Fix For: 0.13 > > Attachments: > 0001-QPID-3367-FileUtils-improvements.-openFileOrDefaultR.patch > > > Improvements to the FileUtils.openFileOrDefaultResource to additionally > search the classpath for the filename to open before falling back to the > default. This is helpful to plugin JARs as it allows the JAR file to ship > resources/properties files with the plugin JAR. -- 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-3365) Improvements to build system to support client-plugins modules
[ https://issues.apache.org/jira/browse/QPID-3365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-3365. -- Resolution: Fixed Changes look good to me, patch applied. > Improvements to build system to support client-plugins modules > -- > > Key: QPID-3365 > URL: https://issues.apache.org/jira/browse/QPID-3365 > Project: Qpid > Issue Type: Improvement > Components: Ant Build System, Java Client >Reporter: Keith Wall >Assignee: Robbie Gemmell > Fix For: 0.13 > > Attachments: > 0001-QPID-3365-Extend-build-system-to-build-optional-clie.patch > > > The Ant Build system already builds broker side plugins beneath the > broker-plugins. This improvement is to introduce an analogous client-plugins > directory to allow for the building optional client side components. An > example of such components would be optional transport or security mechanisms. > This change does not introduce OSGi onto 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-3059) Example TopicListener.cs does not await the arrival of messages
[ https://issues.apache.org/jira/browse/QPID-3059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-3059. -- Resolution: Fixed Based on the comment above I'm just hitting accept whilst passing by :) > Example TopicListener.cs does not await the arrival of messages > --- > > Key: QPID-3059 > URL: https://issues.apache.org/jira/browse/QPID-3059 > Project: Qpid > Issue Type: Bug > Components: Dot Net Client >Affects Versions: 0.8 > Environment: Linux, Mono JIT compiler version 2.6.7 (tarball Mon Jul > 19 18:28:58 UTC 2010) and > Windows 7 >Reporter: Keith Wall >Assignee: Marnie McCormack >Priority: Minor > Attachments: > 0001-QPID-3059-Used-a-monitor-to-ensure-that-the-main-thr.patch > > > I'm trying to run the TopicListener/TopicPublisher provided in the source > tree of the dotnet 0.8 client (The Java Broker Compatible client) . I'm > running on a Linux host under Mono. > I find when I execute TopicListener.exe it immediately writes "Waiting for > messages..." to the console and then exits. The problem seems to me that > the main thread is being allowed to terminate so the program is exiting > before it has a chance to hear the messages of TopicPublisher. > mono ./bin/mono-2.0/debug/TopicListener.exe > Waiting for messages... -- 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-3062) Add additional example for AMQP0-8 .net client (qpid-dotnet-0-8-x.x)
[ https://issues.apache.org/jira/browse/QPID-3062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell resolved QPID-3062. -- Resolution: Fixed Based on the comment above I'm just hitting accept whilst passing by :) > Add additional example for AMQP0-8 .net client (qpid-dotnet-0-8-x.x) > > > Key: QPID-3062 > URL: https://issues.apache.org/jira/browse/QPID-3062 > Project: Qpid > Issue Type: Improvement > Components: Dot Net Client >Affects Versions: 0.8 >Reporter: Keith Wall >Assignee: Marnie McCormack >Priority: Minor > Attachments: > 0001-QPID-3062-Additional-example-for-the-.net-client.patch > > > We have an additional example (suitable for the AMQP0-8 .net client - > qpid-dotnet-0-8-x-x) which may be of use to the Qpid/.net community. > This improvement provides this patch. -- 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-3339) Occasional test failures from ExternalACLTest under java.0.10
[
https://issues.apache.org/jira/browse/QPID-3339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073196#comment-13073196
]
Robbie Gemmell commented on QPID-3339:
--
The patch looks good and seemed to resolve the issues previously being seen, so
it is now applied. I am leaving the JIRA open due to another sporadic failure
in ExternalACLTest though.
With those prior issues gone, repeseated execution of the tests occasionally
gets me an error being thrown by one of the tests,
*testClientConsumeFromNamedQueueFailure*. This seems to be because the test is
expecting the ACL failure to result in a JMSException being thrown, and instead
a different type is thrown. This seems to be due to a race causing the client
side to reach a different part of its execution and throw a SessionException to
indicate the problem instead. This produces a slightly different stacktrace
than the successfull case which should allow analysis (logs shown below,
onwards from the point of broker sending the exception to the client).
{noformat}
MinaNetworkTransport(Acceptor)-15 2011-07-30 11:00:48,311 DEBUG
[apache.qpid.transport.Connection] SEND: [conn:a96863] ch=0 id=0
ExecutionException(errorCode=UNAUTHORIZED_ACCESS, com
mandId=6, description=Cannot subscribe to '1': Permission denied)
MinaNetworkTransport(Acceptor)-15 2011-07-30 11:00:48,311 DEBUG
[transport.network.mina.MinaSender] sending data:
MinaNetworkTransport(Acceptor)-15 2011-07-30 11:00:48,312 DEBUG
[transport.network.mina.MinaSender] sent data:
MinaNetworkTransport(Acceptor)-15 2011-07-30 11:00:48,312 DEBUG
[apache.qpid.transport.Connection] FLUSH: [conn:a96863]
IoReceiver - localhost/127.0.0.1:15672 2011-07-30 11:00:48,312 DEBUG
[apache.qpid.transport.Connection] RECV: [conn:1c1eceb] ch=0
ExecutionException(errorCode=UNAUTHORIZED_ACCESS, co
mmandId=6, description=Cannot subscribe to '1': Permission denied)
IoReceiver - localhost/127.0.0.1:15672 2011-07-30 11:00:48,312 DEBUG
[apache.qpid.transport.Session] ID: [0] 0
MinaNetworkTransport(Acceptor)-15 2011-07-30 11:00:48,312 DEBUG
[apache.qpid.transport.Connection] SEND: [conn:a96863] ch=0
SessionFlush(completed=true)
MinaNetworkTransport(Acceptor)-15 2011-07-30 11:00:48,312 DEBUG
[transport.network.mina.MinaSender] sending data:
MinaNetworkTransport(Acceptor)-15 2011-07-30 11:00:48,312 DEBUG
[transport.network.mina.MinaSender] sent data:
MinaNetworkTransport(Acceptor)-15 2011-07-30 11:00:48,312 DEBUG
[apache.qpid.transport.Connection] FLUSH: [conn:a96863]
MinaNetworkTransport(Acceptor)-15 2011-07-30 11:00:48,312 DEBUG
[apache.qpid.transport.Connection] SEND: [conn:a96863] ch=0
SessionRequestTimeout(timeout=0)
MinaNetworkTransport(Acceptor)-15 2011-07-30 11:00:48,312 DEBUG
[transport.network.mina.MinaSender] sending data:
MinaNetworkTransport(Acceptor)-15 2011-07-30 11:00:48,312 DEBUG
[transport.network.mina.MinaSender] sent data:
MinaNetworkTransport(Acceptor)-15 2011-07-30 11:00:48,312 DEBUG
[apache.qpid.transport.Connection] FLUSH: [conn:a96863]
main 2011-07-30 11:00:48,312 DEBUG [apache.qpid.transport.Connection] FLUSH:
[conn:1c1eceb]
MinaNetworkTransport(Acceptor)-15 2011-07-30 11:00:48,312 DEBUG
[apache.qpid.transport.Connection] SEND: [conn:a96863] ch=0
SessionDetach(name=[B@1742c56)
MinaNetworkTransport(Acceptor)-15 2011-07-30 11:00:48,313 DEBUG
[transport.network.mina.MinaSender] sending data:
MinaNetworkTransport(Acceptor)-15 2011-07-30 11:00:48,313 DEBUG
[transport.network.mina.MinaSender] sent data:
MinaNetworkTransport(Acceptor)-15 2011-07-30 11:00:48,313 DEBUG
[apache.qpid.transport.Connection] FLUSH: [conn:a96863]
MinaNetworkTransport(Acceptor)-15 2011-07-30 11:00:48,313 DEBUG
[apache.qpid.transport.Session] ssn:"a55a7219-8df6-4ec1-bf8c-89556d23c37f"
processed([6, 6]) 5 5
MinaNetworkTransport(Acceptor)-15 2011-07-30 11:00:48,313 DEBUG
[apache.qpid.transport.Session] {[0, 5]}
IoReceiver - localhost/127.0.0.1:15672 2011-07-30 11:00:48,313 DEBUG
[apache.qpid.client.AMQConnection] exceptionReceived done by:IoReceiver -
localhost/127.0.0.1:15672
org.apache.qpid.AMQException: ch=0 id=0
ExecutionException(errorCode=UNAUTHORIZED_ACCESS, commandId=6,
description=Cannot subscribe to '1': Permission denied) [error code 403: access
refused]
at
org.apache.qpid.client.AMQSession_0_10.setCurrentException(AMQSession_0_10.java:1058)
at
org.apache.qpid.client.AMQSession_0_10.exception(AMQSession_0_10.java:921)
at
org.apache.qpid.transport.SessionDelegate.executionException(SessionDelegate.java:160)
at
org.apache.qpid.transport.SessionDelegate.executionException(SessionDelegate.java:32)
at
org.apache.qpid.transport.ExecutionException.dispatch(ExecutionException.java:112)
at
org.apache.qpid.transport.SessionDelegate.command(SessionDelegate.java:50)
at
org.apache.qpid.transport.SessionDelegate.command(SessionDelegate.java:32)
at org.a
[jira] [Assigned] (QPID-3064) queues will prevent GC of a closed subscription if it was the last used subscription and no more messages are enqueued
[ https://issues.apache.org/jira/browse/QPID-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned QPID-3064: Assignee: Robbie Gemmell > queues will prevent GC of a closed subscription if it was the last used > subscription and no more messages are enqueued > -- > > Key: QPID-3064 > URL: https://issues.apache.org/jira/browse/QPID-3064 > 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: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.13 > > > SimpleAMQQueue uses an atomic reference to round robin the subscriptions when > attempting to deliver a mesage to a subscription during enqueue operations. > This reference will prevent the subscription being Garbage Collected when it > is closed if the subscription was the last used and no more messages are > enqueued. When unregistering a subscription, this reference should be updated > if it points to the closing subscription. -- 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-3064) queues will prevent GC of a closed subscription if it was the last used subscription and no more messages are enqueued
[ https://issues.apache.org/jira/browse/QPID-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-3064: - Affects Version/s: 0.12 0.11 0.9 0.10 Fix Version/s: (was: Future) 0.13 > queues will prevent GC of a closed subscription if it was the last used > subscription and no more messages are enqueued > -- > > Key: QPID-3064 > URL: https://issues.apache.org/jira/browse/QPID-3064 > 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: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.13 > > > SimpleAMQQueue uses an atomic reference to round robin the subscriptions when > attempting to deliver a mesage to a subscription during enqueue operations. > This reference will prevent the subscription being Garbage Collected when it > is closed if the subscription was the last used and no more messages are > enqueued. When unregistering a subscription, this reference should be updated > if it points to the closing subscription. -- 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-3064) queues will prevent GC of a closed subscription if it was the last used subscription and no more messages are enqueued
[ https://issues.apache.org/jira/browse/QPID-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-3064: - Status: Ready To Review (was: In Progress) > queues will prevent GC of a closed subscription if it was the last used > subscription and no more messages are enqueued > -- > > Key: QPID-3064 > URL: https://issues.apache.org/jira/browse/QPID-3064 > 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: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.13 > > > SimpleAMQQueue uses an atomic reference to round robin the subscriptions when > attempting to deliver a mesage to a subscription during enqueue operations. > This reference will prevent the subscription being Garbage Collected when it > is closed if the subscription was the last used and no more messages are > enqueued. When unregistering a subscription, this reference should be updated > if it points to the closing subscription. -- 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-3064) queues will prevent GC of a closed subscription if it was the last used subscription and no more messages are enqueued
[ https://issues.apache.org/jira/browse/QPID-3064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned QPID-3064: Assignee: Keith Wall (was: Robbie Gemmell) Hi Keith, could you review these changes please? The 'last used subscription' marker functionality was moved onto the SubscriptionList itself, and if the marked subscription is deleted a dummy node is inserted to allow the real nodes removal. Thanks, Robbie. > queues will prevent GC of a closed subscription if it was the last used > subscription and no more messages are enqueued > -- > > Key: QPID-3064 > URL: https://issues.apache.org/jira/browse/QPID-3064 > 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: Robbie Gemmell >Assignee: Keith Wall > Fix For: 0.13 > > > SimpleAMQQueue uses an atomic reference to round robin the subscriptions when > attempting to deliver a mesage to a subscription during enqueue operations. > This reference will prevent the subscription being Garbage Collected when it > is closed if the subscription was the last used and no more messages are > enqueued. When unregistering a subscription, this reference should be updated > if it points to the closing subscription. -- 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-3157) 'removed' subscriptions may be held in memory by the queues SubscriptionList or 'lastSubscriptionNode' reference
[ https://issues.apache.org/jira/browse/QPID-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-3157: - Status: Ready To Review (was: In Progress) > 'removed' subscriptions may be held in memory by the queues SubscriptionList > or 'lastSubscriptionNode' reference > > > Key: QPID-3157 > URL: https://issues.apache.org/jira/browse/QPID-3157 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.5, 0.6, 0.7, 0.8, 0.9, 0.10, 0.11, 0.12 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Critical > Fix For: 0.13 > > > subscriptions 'removed' from a queue subscription list are only marked > deleted and can not actually bereleased from memory until the head of the > subscription list advances beyond them. Additionally and perhaps more > troublesome, a queues 'lastSubscriptionNode' can refer to a particular > subscription but hold *all* subscequent subscriptions in memory whether they > have been deleted or not and regardless whether the head of the > SubscriptionList has advanced beyond them, > As a result any memory in use by the now-closed subscription will not be > released until the queue is deleted, or all the subscriptions prior to it are > closed and removed from the list *and* the 'lastSubscriptionNode' advances > beyond them.. This also holds the associated ServerSession in memory, which > is currently a rather heavyweight object. > This issue is further compounded when the queue has a backlog of messages and > consumers are then created, used to recieve one message, and closed. In this > scenario the broker sends the client as many messages as it can prefetch, > leading to creation of up to MessageTransfer > commands, all which are recorded in the ServerSession but then left retained > as 'unprocessed' in the closed session, which might be held in memory as > described above. This results in an explosion in the number of > MessageTransfer commands retained in memory as each message can have up to > MessageTransfer commands associated with it before it is > eventually consumed by a client and all of thse will also be retained in > memory by a 'removed' but not deleted subscription. The last effect can be > combated by restricting the preftech size (eg appending &maxprefetch='1' to > the connection url). -- 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-3157) 'removed' subscriptions may be held in memory by the queues SubscriptionList or 'lastSubscriptionNode' reference
[ https://issues.apache.org/jira/browse/QPID-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned QPID-3157: Assignee: Keith Wall (was: Robbie Gemmell) Hi Keith, could you review these changes please? The SubscriptionList now ensures it removes the nodes during the remove method rather than waiting for the list head to advance past them, which may not occur if earlier Subscription nodes in the list remain active. A dummy node is inserted at the end when attempting to remove the current tail node, as the tail cant be unlinked for thread safety. The new 'marked node' functionlity within the SubscriptionList allows cleaning up any nodes the prior 'lastSubscriptionNode' reference in the queue would have leaked by simply searching for the next non-deleted node after the marker, since this is guaranteed to be within the active list, after which point they are no longer leaked due to the above changes. Thanks, Robbie. > 'removed' subscriptions may be held in memory by the queues SubscriptionList > or 'lastSubscriptionNode' reference > > > Key: QPID-3157 > URL: https://issues.apache.org/jira/browse/QPID-3157 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.5, 0.6, 0.7, 0.8, 0.9, 0.10, 0.11, 0.12 >Reporter: Robbie Gemmell >Assignee: Keith Wall >Priority: Critical > Fix For: 0.13 > > > subscriptions 'removed' from a queue subscription list are only marked > deleted and can not actually bereleased from memory until the head of the > subscription list advances beyond them. Additionally and perhaps more > troublesome, a queues 'lastSubscriptionNode' can refer to a particular > subscription but hold *all* subscequent subscriptions in memory whether they > have been deleted or not and regardless whether the head of the > SubscriptionList has advanced beyond them, > As a result any memory in use by the now-closed subscription will not be > released until the queue is deleted, or all the subscriptions prior to it are > closed and removed from the list *and* the 'lastSubscriptionNode' advances > beyond them.. This also holds the associated ServerSession in memory, which > is currently a rather heavyweight object. > This issue is further compounded when the queue has a backlog of messages and > consumers are then created, used to recieve one message, and closed. In this > scenario the broker sends the client as many messages as it can prefetch, > leading to creation of up to MessageTransfer > commands, all which are recorded in the ServerSession but then left retained > as 'unprocessed' in the closed session, which might be held in memory as > described above. This results in an explosion in the number of > MessageTransfer commands retained in memory as each message can have up to > MessageTransfer commands associated with it before it is > eventually consumed by a client and all of thse will also be retained in > memory by a 'removed' but not deleted subscription. The last effect can be > combated by restricting the preftech size (eg appending &maxprefetch='1' to > the connection url). -- 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-3319) org.apache.qpid.server.subscription.SubscriptionList leaks memory
[ https://issues.apache.org/jira/browse/QPID-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073211#comment-13073211 ] Robbie Gemmell commented on QPID-3319: -- Hi Srinath, Sorry for the delayed reply, I am/have been on holiday as well. Given many of the issues I raised with the patch previously still apply after the update, I really wouldnt be comfortable committing it as-is. I had actually already looked into fixing the leaks in the existing implementation previously and just hadnt got time to finish it, so I have completed that work and it is now committed on trunk. It addresses a number of different possible leaks that were present and ensures the list always removes the Subscription immediately rather than the sometimes-lazily method used before, additionally avoiding the most troublesome leak in the form of the 'lastSubscriptionNode' reference in the queue leaking Subscriptions that the SubscriptionList itself can no longer reach by moving that functionality into the list itself. As the queue no longer maintains that reference at all, it also no longer leaks that specific Subscription either (which happens if the reference is never updated after the Subscription is unregistered). The changes are committed via QPID-3064 and QPID-3157. Just for any future patches you have, the updated patch doesnt conform to the 'braces on new lines' aspect of the code style. I am going to mark this RtR, for closure alongside QPID-3157. > org.apache.qpid.server.subscription.SubscriptionList leaks memory > - > > Key: QPID-3319 > URL: https://issues.apache.org/jira/browse/QPID-3319 > Project: Qpid > Issue Type: Bug >Reporter: Danushka Menikkumbura >Assignee: Robbie Gemmell >Priority: Critical > Attachments: QPID-3319-26-07-2011.patch, QPID-3319-26-07-2011.patch, > QPID-3319.2.patch, QPID-3319.3.patch, QPID-3319.patch > > -- 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-3319) org.apache.qpid.server.subscription.SubscriptionList leaks memory
[ https://issues.apache.org/jira/browse/QPID-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned QPID-3319: Assignee: Keith Wall (was: Robbie Gemmell) > org.apache.qpid.server.subscription.SubscriptionList leaks memory > - > > Key: QPID-3319 > URL: https://issues.apache.org/jira/browse/QPID-3319 > Project: Qpid > Issue Type: Bug >Reporter: Danushka Menikkumbura >Assignee: Keith Wall >Priority: Critical > Attachments: QPID-3319-26-07-2011.patch, QPID-3319-26-07-2011.patch, > QPID-3319.2.patch, QPID-3319.3.patch, QPID-3319.patch > > -- 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-3319) org.apache.qpid.server.subscription.SubscriptionList leaks memory
[ https://issues.apache.org/jira/browse/QPID-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-3319: - Status: Ready To Review (was: In Progress) > org.apache.qpid.server.subscription.SubscriptionList leaks memory > - > > Key: QPID-3319 > URL: https://issues.apache.org/jira/browse/QPID-3319 > Project: Qpid > Issue Type: Bug >Reporter: Danushka Menikkumbura >Assignee: Robbie Gemmell >Priority: Critical > Attachments: QPID-3319-26-07-2011.patch, QPID-3319-26-07-2011.patch, > QPID-3319.2.patch, QPID-3319.3.patch, QPID-3319.patch > > -- 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-3157) 'removed' subscriptions may be held in memory by the queues SubscriptionList or 'lastSubscriptionNode' reference
[ https://issues.apache.org/jira/browse/QPID-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073212#comment-13073212 ] Robbie Gemmell commented on QPID-3157: -- Just a note, QPID-3319 should be closed out at the same time as this is (without a fix-for; no point having 2 JIRAs for the same issue in the release notes). > 'removed' subscriptions may be held in memory by the queues SubscriptionList > or 'lastSubscriptionNode' reference > > > Key: QPID-3157 > URL: https://issues.apache.org/jira/browse/QPID-3157 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.5, 0.6, 0.7, 0.8, 0.9, 0.10, 0.11, 0.12 >Reporter: Robbie Gemmell >Assignee: Keith Wall >Priority: Critical > Fix For: 0.13 > > > subscriptions 'removed' from a queue subscription list are only marked > deleted and can not actually bereleased from memory until the head of the > subscription list advances beyond them. Additionally and perhaps more > troublesome, a queues 'lastSubscriptionNode' can refer to a particular > subscription but hold *all* subscequent subscriptions in memory whether they > have been deleted or not and regardless whether the head of the > SubscriptionList has advanced beyond them, > As a result any memory in use by the now-closed subscription will not be > released until the queue is deleted, or all the subscriptions prior to it are > closed and removed from the list *and* the 'lastSubscriptionNode' advances > beyond them.. This also holds the associated ServerSession in memory, which > is currently a rather heavyweight object. > This issue is further compounded when the queue has a backlog of messages and > consumers are then created, used to recieve one message, and closed. In this > scenario the broker sends the client as many messages as it can prefetch, > leading to creation of up to MessageTransfer > commands, all which are recorded in the ServerSession but then left retained > as 'unprocessed' in the closed session, which might be held in memory as > described above. This results in an explosion in the number of > MessageTransfer commands retained in memory as each message can have up to > MessageTransfer commands associated with it before it is > eventually consumed by a client and all of thse will also be retained in > memory by a 'removed' but not deleted subscription. The last effect can be > combated by restricting the preftech size (eg appending &maxprefetch='1' to > the connection url). -- 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-3157) 'removed' subscriptions may be held in memory by the queues SubscriptionList or 'lastSubscriptionNode' reference
[ https://issues.apache.org/jira/browse/QPID-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-3157: - Assignee: Robbie Gemmell (was: Keith Wall) Status: Open (was: Ready To Review) Bumping this back to In Progress because I just thought of a corner case I didnt cover when cleaning up the marker node, will fix it up soon. > 'removed' subscriptions may be held in memory by the queues SubscriptionList > or 'lastSubscriptionNode' reference > > > Key: QPID-3157 > URL: https://issues.apache.org/jira/browse/QPID-3157 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.5, 0.6, 0.7, 0.8, 0.9, 0.10, 0.11, 0.12 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Critical > Fix For: 0.13 > > > subscriptions 'removed' from a queue subscription list are only marked > deleted and can not actually bereleased from memory until the head of the > subscription list advances beyond them. Additionally and perhaps more > troublesome, a queues 'lastSubscriptionNode' can refer to a particular > subscription but hold *all* subscequent subscriptions in memory whether they > have been deleted or not and regardless whether the head of the > SubscriptionList has advanced beyond them, > As a result any memory in use by the now-closed subscription will not be > released until the queue is deleted, or all the subscriptions prior to it are > closed and removed from the list *and* the 'lastSubscriptionNode' advances > beyond them.. This also holds the associated ServerSession in memory, which > is currently a rather heavyweight object. > This issue is further compounded when the queue has a backlog of messages and > consumers are then created, used to recieve one message, and closed. In this > scenario the broker sends the client as many messages as it can prefetch, > leading to creation of up to MessageTransfer > commands, all which are recorded in the ServerSession but then left retained > as 'unprocessed' in the closed session, which might be held in memory as > described above. This results in an explosion in the number of > MessageTransfer commands retained in memory as each message can have up to > MessageTransfer commands associated with it before it is > eventually consumed by a client and all of thse will also be retained in > memory by a 'removed' but not deleted subscription. The last effect can be > combated by restricting the preftech size (eg appending &maxprefetch='1' to > the connection url). -- 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-3157) 'removed' subscriptions may be held in memory by the queues SubscriptionList or 'lastSubscriptionNode' reference
[ https://issues.apache.org/jira/browse/QPID-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-3157: - Status: Ready To Review (was: In Progress) > 'removed' subscriptions may be held in memory by the queues SubscriptionList > or 'lastSubscriptionNode' reference > > > Key: QPID-3157 > URL: https://issues.apache.org/jira/browse/QPID-3157 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.5, 0.6, 0.7, 0.8, 0.9, 0.10, 0.11, 0.12 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell >Priority: Critical > Fix For: 0.13 > > > subscriptions 'removed' from a queue subscription list are only marked > deleted and can not actually bereleased from memory until the head of the > subscription list advances beyond them. Additionally and perhaps more > troublesome, a queues 'lastSubscriptionNode' can refer to a particular > subscription but hold *all* subscequent subscriptions in memory whether they > have been deleted or not and regardless whether the head of the > SubscriptionList has advanced beyond them, > As a result any memory in use by the now-closed subscription will not be > released until the queue is deleted, or all the subscriptions prior to it are > closed and removed from the list *and* the 'lastSubscriptionNode' advances > beyond them.. This also holds the associated ServerSession in memory, which > is currently a rather heavyweight object. > This issue is further compounded when the queue has a backlog of messages and > consumers are then created, used to recieve one message, and closed. In this > scenario the broker sends the client as many messages as it can prefetch, > leading to creation of up to MessageTransfer > commands, all which are recorded in the ServerSession but then left retained > as 'unprocessed' in the closed session, which might be held in memory as > described above. This results in an explosion in the number of > MessageTransfer commands retained in memory as each message can have up to > MessageTransfer commands associated with it before it is > eventually consumed by a client and all of thse will also be retained in > memory by a 'removed' but not deleted subscription. The last effect can be > combated by restricting the preftech size (eg appending &maxprefetch='1' to > the connection url). -- 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-3157) 'removed' subscriptions may be held in memory by the queues SubscriptionList or 'lastSubscriptionNode' reference
[ https://issues.apache.org/jira/browse/QPID-3157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned QPID-3157: Assignee: Keith Wall (was: Robbie Gemmell) Added a test to pick up the problem, then fixed up the issue, which was: the marker cleanup could run off the end of the list if the previously-tail node was being removed, and so would end up pointing a dummy marker nodes 'next' reference at null instead of the new list tail, meaning it then wouldnt pick up future Subscriptions added to the list, which would cause the queue to cycle back to the list head preumaturely. Back over to you Keith. > 'removed' subscriptions may be held in memory by the queues SubscriptionList > or 'lastSubscriptionNode' reference > > > Key: QPID-3157 > URL: https://issues.apache.org/jira/browse/QPID-3157 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.5, 0.6, 0.7, 0.8, 0.9, 0.10, 0.11, 0.12 >Reporter: Robbie Gemmell >Assignee: Keith Wall >Priority: Critical > Fix For: 0.13 > > > subscriptions 'removed' from a queue subscription list are only marked > deleted and can not actually bereleased from memory until the head of the > subscription list advances beyond them. Additionally and perhaps more > troublesome, a queues 'lastSubscriptionNode' can refer to a particular > subscription but hold *all* subscequent subscriptions in memory whether they > have been deleted or not and regardless whether the head of the > SubscriptionList has advanced beyond them, > As a result any memory in use by the now-closed subscription will not be > released until the queue is deleted, or all the subscriptions prior to it are > closed and removed from the list *and* the 'lastSubscriptionNode' advances > beyond them.. This also holds the associated ServerSession in memory, which > is currently a rather heavyweight object. > This issue is further compounded when the queue has a backlog of messages and > consumers are then created, used to recieve one message, and closed. In this > scenario the broker sends the client as many messages as it can prefetch, > leading to creation of up to MessageTransfer > commands, all which are recorded in the ServerSession but then left retained > as 'unprocessed' in the closed session, which might be held in memory as > described above. This results in an explosion in the number of > MessageTransfer commands retained in memory as each message can have up to > MessageTransfer commands associated with it before it is > eventually consumed by a client and all of thse will also be retained in > memory by a 'removed' but not deleted subscription. The last effect can be > combated by restricting the preftech size (eg appending &maxprefetch='1' to > the connection url). -- 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-2345) Java Client not detecting cause of session close from client thread
[ https://issues.apache.org/jira/browse/QPID-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073394#comment-13073394 ] Robbie Gemmell commented on QPID-2345: -- This seems like it was raised against the 0-8 / 0-9 code path as outcome of QPID-2262, but the 0-10 path can be seen doing similar things as shown via this comment in QPID-3339: https://issues.apache.org/jira/browse/QPID-3339?focusedCommentId=13073196&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13073196 > Java Client not detecting cause of session close from client thread > --- > > Key: QPID-2345 > URL: https://issues.apache.org/jira/browse/QPID-2345 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.6 >Reporter: Martin Ritchie > Fix For: Future > > > As exemplified by the SimpleACLTest when the broker closes the connection the > client attempts to stop the current activity and remember the cause of the > closure to report to the client. However, if the client is in the process of > performing a operation such as session.createQueue() the closed state can be > deteted before the cause has been set as a result the IllegalStateException > is thrown and no cause has been set. > This was working on 0.5. However, it is possible that the new IO layer is > highlighting another race condition. Or that it is not correctly setting the > state to CLOSED. Which is required to be done to prompt the client threads to > check for a causal exception. -- 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-2345) Java Client not detecting cause of session close from client thread
[ https://issues.apache.org/jira/browse/QPID-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-2345: - Fix Version/s: Future > Java Client not detecting cause of session close from client thread > --- > > Key: QPID-2345 > URL: https://issues.apache.org/jira/browse/QPID-2345 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.6 >Reporter: Martin Ritchie > Fix For: Future > > > As exemplified by the SimpleACLTest when the broker closes the connection the > client attempts to stop the current activity and remember the cause of the > closure to report to the client. However, if the client is in the process of > performing a operation such as session.createQueue() the closed state can be > deteted before the cause has been set as a result the IllegalStateException > is thrown and no cause has been set. > This was working on 0.5. However, it is possible that the new IO layer is > highlighting another race condition. Or that it is not correctly setting the > state to CLOSED. Which is required to be done to prompt the client threads to > check for a causal exception. -- 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-3339) Occasional test failures from ExternalACLTest under java.0.10
[
https://issues.apache.org/jira/browse/QPID-3339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073396#comment-13073396
]
Robbie Gemmell commented on QPID-3339:
--
It doesn't seem like QPID-2345 was raised due to it, and I dont think I've ever
seen the 0-8/0-9 profiles fail ExternalACLTest due to it, but the described
outcome/behaviour appears the same yes. I have linked the issues, but I'm as
yet undecided on whether that means this one should be closed since there
obviously are still "Occasional test failures from ExternalACLTest under
java.0.10":)
> Occasional test failures from ExternalACLTest under java.0.10
> --
>
> Key: QPID-3339
> URL: https://issues.apache.org/jira/browse/QPID-3339
> Project: Qpid
> Issue Type: Bug
> Components: Java Broker, Java Tests
>Affects Versions: 0.10, 0.11, 0.12
>Reporter: Keith Wall
>Assignee: Robbie Gemmell
> Attachments:
> 0001-QPID-3339-Occasional-test-failures-from-ExternalACLT.patch
>
>
> Running system test ExternalACLTest shows occasional test failures on the
> java.0.10 test profile.The stack trace always indicates a timeout during
> close (see below).
> Running the test in a loop from the shell, I see a failure rate of roughly
> one time in ten on my machine. This is a longstanding issue (at least five
> months)
> {code}
> $ while /bin/true; do ant -f build.xml test -Dprofile=java.0.10
> -Dtest=ExternalACLTest | grep junit; done
> [echo] Running ant for module : junit-toolkit
> [junit] Running org.apache.qpid.server.security.acl.ExternalACLTest
> [junit] Tests run: 21, Failures: 0, Errors: 0, Time elapsed: 39.928 sec
> [echo] Running ant for module : junit-toolkit
> [junit] Running org.apache.qpid.server.security.acl.ExternalACLTest
> [junit] Tests run: 21, Failures: 0, Errors: 1, Time elapsed: 99.137 sec
> [junit] Test org.apache.qpid.server.security.acl.ExternalACLTest FAILED
> [echo] Running ant for module : junit-toolkit
> [junit] Running org.apache.qpid.server.security.acl.ExternalACLTest
> [junit] Tests run: 21, Failures: 0, Errors: 0, Time elapsed: 39.897 sec
> [echo] Running ant for module : junit-toolkit
> [junit] Running org.apache.qpid.server.security.acl.ExternalACLTest
> [junit] Tests run: 21, Failures: 0, Errors: 0, Time elapsed: 40.134 sec
> [echo] Running ant for module : junit-toolkit
> [junit] Running org.apache.qpid.server.security.acl.ExternalACLTest
> [junit] Tests run: 21, Failures: 0, Errors: 1, Time elapsed: 99.792 sec
> [junit] Test org.apache.qpid.server.security.acl.ExternalACLTest FAILED
> {code}
> The test output:
> {code}
> cat
> build/results/systests/TEST-org.apache.qpid.server.security.acl.ExternalACLTest.txt
>
> Testsuite: org.apache.qpid.server.security.acl.ExternalACLTest
> Tests run: 21, Failures: 0, Errors: 1, Time elapsed: 99.137 sec
> - Standard Output ---
> Testcase: testAccessAuthorizedSuccess took 2.447 sec
> Testcase: testAccessVhostAuthorisedGuestSuccess took 2.168 sec
> Testcase: testAccessNoRightsFailure took 1.74 sec
> Testcase: testClientDeleteQueueSuccess took 2.135 sec
> Testcase: testServerDeleteQueueFailure took 2.015 sec
> Testcase: testClientConsumeFromTempQueueSuccess took 1.889 sec
> Testcase: testClientConsumeFromNamedQueueFailure took 1.859 sec
> Testcase: testClientCreateTemporaryQueueSuccess took 1.806 sec
> Testcase: testClientCreateNamedQueueFailure took 1.779 sec
> Testcase: testClientPublishUsingTransactionSuccess took 1.776 sec
> Testcase: testClientPublishValidQueueSuccess took 1.769 sec
> Testcase: testClientPublishInvalidQueueSuccess took 1.771 sec
> Testcase: testServerConsumeFromNamedQueueValid took 1.838 sec
> Testcase: testServerConsumeFromNamedQueueInvalid took 1.856 sec
> Testcase: testServerConsumeFromTemporaryQueue took 1.42 sec
> Testcase: testServerCreateNamedQueueValid took 1.456 sec
> Testcase: testServerCreateNamedQueueInvalid took 1.777 sec
> Testcase: testServerCreateTemporaryQueueInvalid took 1.786 sec
> Testcase: testServerCreateAutoDeleteQueueInvalid took 1.787 sec
> Testcase: testServerPublishUsingTransactionSuccess took 62.239 sec
> Caused an ERROR
> Error closing connection: org.apache.qpid.AMQException: close() timed out
> javax.jms.JMSException: Error closing connection:
> org.apache.qpid.AMQException: close() timed out
> at
> org.apache.qpid.client.AMQConnection.doClose(AMQConnection.java:913)
> at
> org.apache.qpid.client.AMQConnection.doClose(AMQConnection.java:864)
> at org.apache.qpid.client.AMQConnection.close(AMQConnection.java:848)
> at org.apache.qpid.client.AMQConnection.close(AMQConnection.java:839)
> at org.apache.qpid.client.AMQConnection.close(AMQCon
[jira] [Assigned] (QPID-2899) SelectorTest#testRuntimeSelectorError fails when using 0-10
[ https://issues.apache.org/jira/browse/QPID-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned QPID-2899: Assignee: Robbie Gemmell > SelectorTest#testRuntimeSelectorError fails when using 0-10 > --- > > Key: QPID-2899 > URL: https://issues.apache.org/jira/browse/QPID-2899 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.6 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.13 > > > org.apache.qpid.test.client.message.SelectorTest#testRuntimeSelectorError > fails when using 0-10 because the broker fails to close the connection when > the deliberate error occurs, as it does when using 0-8/0-9 > QpidBrokerTestCase behaviour is to close connections during teardown that > were created using the getConnection() utility method, and the teardown close > is failing because it tries to sync outstanding 0-10 commands with the broker > and times out. This test should already have caused the connection to be > closed due to a (deliberate) error when evaluating the selector. > However, in addition to the original exception it can be seen that there are > IllegalArgumentException occurrences immediately afterwards because the > InputHandler is continuing to process recieved data on the connection (whcih > should have been closed) and then ends up trying to add the contents of a > ByteBuffer to itself in the received() method (possibly because the exception > being throwing prevented an instance variable being set to null on completion > of a process), prompting the throwing of the IllegalArgumentException. > Commenting out the connection close during teardown reveals the test would > otherwise have failed because the connection was not closed due to the > original error as it should have been. It appears that the 0-8 broker code > closes the mina protocol session in this situation when the first exception > is thrown, but the 0-10 broker code proceeds using a crippled connection and > then gets into further difficulty. -- 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-2899) SelectorTest#testRuntimeSelectorError fails when using 0-10
[ https://issues.apache.org/jira/browse/QPID-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-2899: - Description: org.apache.qpid.test.client.message.SelectorTest#testRuntimeSelectorError fails against the Java broker when using 0-10 because the broker fails to close the Session when the deliberate error occurs, as it does when using 0-8/0-9. QpidBrokerTestCase behaviour is to close connections during teardown that were created using the getConnection() utility method, and the teardown close is failing in this test because it tries to sync outstanding 0-10 commands with the broker and times out, as the previous exception has crippled it. The exception should be caught and used to close the producer Session with an ExecutionException. was: org.apache.qpid.test.client.message.SelectorTest#testRuntimeSelectorError fails when using 0-10 because the broker fails to close the connection when the deliberate error occurs, as it does when using 0-8/0-9 QpidBrokerTestCase behaviour is to close connections during teardown that were created using the getConnection() utility method, and the teardown close is failing because it tries to sync outstanding 0-10 commands with the broker and times out. This test should already have caused the connection to be closed due to a (deliberate) error when evaluating the selector. However, in addition to the original exception it can be seen that there are IllegalArgumentException occurrences immediately afterwards because the InputHandler is continuing to process recieved data on the connection (whcih should have been closed) and then ends up trying to add the contents of a ByteBuffer to itself in the received() method (possibly because the exception being throwing prevented an instance variable being set to null on completion of a process), prompting the throwing of the IllegalArgumentException. Commenting out the connection close during teardown reveals the test would otherwise have failed because the connection was not closed due to the original error as it should have been. It appears that the 0-8 broker code closes the mina protocol session in this situation when the first exception is thrown, but the 0-10 broker code proceeds using a crippled connection and then gets into further difficulty. Affects Version/s: 0.12 0.11 0.7 0.8 0.9 0.10 > SelectorTest#testRuntimeSelectorError fails when using 0-10 > --- > > Key: QPID-2899 > URL: https://issues.apache.org/jira/browse/QPID-2899 > 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: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.13 > > > org.apache.qpid.test.client.message.SelectorTest#testRuntimeSelectorError > fails against the Java broker when using 0-10 because the broker fails to > close the Session when the deliberate error occurs, as it does when using > 0-8/0-9. > QpidBrokerTestCase behaviour is to close connections during teardown that > were created using the getConnection() utility method, and the teardown close > is failing in this test because it tries to sync outstanding 0-10 commands > with the broker and times out, as the previous exception has crippled it. The > exception should be caught and used to close the producer Session with an > ExecutionException. -- 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-2899) SelectorTest#testRuntimeSelectorError fails against the Java broker when running the 0-10 profiles
[ https://issues.apache.org/jira/browse/QPID-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-2899: - Summary: SelectorTest#testRuntimeSelectorError fails against the Java broker when running the 0-10 profiles (was: SelectorTest#testRuntimeSelectorError fails when using 0-10) > SelectorTest#testRuntimeSelectorError fails against the Java broker when > running the 0-10 profiles > -- > > Key: QPID-2899 > URL: https://issues.apache.org/jira/browse/QPID-2899 > 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: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.13 > > > org.apache.qpid.test.client.message.SelectorTest#testRuntimeSelectorError > fails against the Java broker when using 0-10 because the broker fails to > close the Session when the deliberate error occurs, as it does when using > 0-8/0-9. > QpidBrokerTestCase behaviour is to close connections during teardown that > were created using the getConnection() utility method, and the teardown close > is failing in this test because it tries to sync outstanding 0-10 commands > with the broker and times out, as the previous exception has crippled it. The > exception should be caught and used to close the producer Session with an > ExecutionException. -- 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-2899) SelectorTest#testRuntimeSelectorError fails against the Java broker when running the 0-10 profiles
[ https://issues.apache.org/jira/browse/QPID-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-2899: - Status: Ready To Review (was: In Progress) > SelectorTest#testRuntimeSelectorError fails against the Java broker when > running the 0-10 profiles > -- > > Key: QPID-2899 > URL: https://issues.apache.org/jira/browse/QPID-2899 > 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: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.13 > > > org.apache.qpid.test.client.message.SelectorTest#testRuntimeSelectorError > fails against the Java broker when using 0-10 because the broker fails to > close the Session when the deliberate error occurs, as it does when using > 0-8/0-9. > QpidBrokerTestCase behaviour is to close connections during teardown that > were created using the getConnection() utility method, and the teardown close > is failing in this test because it tries to sync outstanding 0-10 commands > with the broker and times out, as the previous exception has crippled it. The > exception should be caught and used to close the producer Session with an > ExecutionException. -- 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-2899) SelectorTest#testRuntimeSelectorError fails against the Java broker when running the 0-10 profiles
[ https://issues.apache.org/jira/browse/QPID-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned QPID-2899: Assignee: Keith Wall (was: Robbie Gemmell) Hi Keith, could you review this change please? Thanks. > SelectorTest#testRuntimeSelectorError fails against the Java broker when > running the 0-10 profiles > -- > > Key: QPID-2899 > URL: https://issues.apache.org/jira/browse/QPID-2899 > 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: Robbie Gemmell >Assignee: Keith Wall > Fix For: 0.13 > > > org.apache.qpid.test.client.message.SelectorTest#testRuntimeSelectorError > fails against the Java broker when using 0-10 because the broker fails to > close the Session when the deliberate error occurs, as it does when using > 0-8/0-9. > QpidBrokerTestCase behaviour is to close connections during teardown that > were created using the getConnection() utility method, and the teardown close > is failing in this test because it tries to sync outstanding 0-10 commands > with the broker and times out, as the previous exception has crippled it. The > exception should be caught and used to close the producer Session with an > ExecutionException. -- 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-3377) Sending message with a subject to a queue fails
[ https://issues.apache.org/jira/browse/QPID-3377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13078918#comment-13078918 ] Robbie Gemmell commented on QPID-3377: -- r1153299 caused the java 0-9-1 test profiles to fail (the Jenkins failure email didnt go to the notifications list because I'm setting up a new matrix test project and its a semi broken just now due to issues with 2 of the 3 the ubuntu slaves, so I only have it emailing me right now.) > Sending message with a subject to a queue fails > --- > > Key: QPID-3377 > URL: https://issues.apache.org/jira/browse/QPID-3377 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.10 >Reporter: Pavel Moravec >Assignee: Rajith Attapattu > Labels: patch > Fix For: 0.12 > > Attachments: qpid-java-0.10.JIRA3377.patch > > Original Estimate: 2h > Remaining Estimate: 2h > > Having a queue bound just to default exchange and sending a message with a > subject to the queue results in dropping the message by the default queue. > Replication steps: > 1) qpid-config add queue testQueue > 2) cd /usr/share/doc/qpid-java-0.10/examples > 3) ./run_example.sh org.apache.qpid.example.Spout testQueue/someSubject > 4) qpid-stat -e shows the default '' exchange dropped the message > Patch already proposed. -- 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-2899) SelectorTest#testRuntimeSelectorError fails against the Java broker when running the 0-10 profiles
[ https://issues.apache.org/jira/browse/QPID-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13078923#comment-13078923 ] Robbie Gemmell commented on QPID-2899: -- No it isnt being logged (it never was), so I have put that in now. > SelectorTest#testRuntimeSelectorError fails against the Java broker when > running the 0-10 profiles > -- > > Key: QPID-2899 > URL: https://issues.apache.org/jira/browse/QPID-2899 > 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: Robbie Gemmell >Assignee: Keith Wall > Fix For: 0.13 > > > org.apache.qpid.test.client.message.SelectorTest#testRuntimeSelectorError > fails against the Java broker when using 0-10 because the broker fails to > close the Session when the deliberate error occurs, as it does when using > 0-8/0-9. > QpidBrokerTestCase behaviour is to close connections during teardown that > were created using the getConnection() utility method, and the teardown close > is failing in this test because it tries to sync outstanding 0-10 commands > with the broker and times out, as the previous exception has crippled it. The > exception should be caught and used to close the producer Session with an > ExecutionException. -- 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-3381) Allow the AMQP 0-10 routing key to be retrieved via the message properties
[ https://issues.apache.org/jira/browse/QPID-3381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13078930#comment-13078930 ] Robbie Gemmell commented on QPID-3381: -- Hehe...I just posted on QPID-3377 about that :) > Allow the AMQP 0-10 routing key to be retrieved via the message properties > -- > > Key: QPID-3381 > URL: https://issues.apache.org/jira/browse/QPID-3381 > Project: Qpid > Issue Type: Improvement > Components: Java Client >Reporter: Rajith Attapattu >Assignee: Rajith Attapattu >Priority: Minor > Fix For: 0.14 > > > Some users have expressed their desire to figure out the routing key used for > a particular message. Ex for debugging. > We could use "x-amqp-0-10.routing-key" as a property name to retrieve this > from the underlying message delegate. > Please note "x-amqp-0-10.routing-key" is the same key used by the Qpid > messaging API (implemented in C++, Python, C#, Perl..etc) to retrieve the > routing key. -- 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-3385) 0-8/0-9/0-9-1 based connections share an ID generator, but 0-10 connection use their own
0-8/0-9/0-9-1 based connections share an ID generator, but 0-10 connection use their own Key: QPID-3385 URL: https://issues.apache.org/jira/browse/QPID-3385 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.10, 0.9, 0.8, 0.7, 0.6, 0.11, 0.12 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.13 0-8/0-9/0-9-1 based connections share a ID generator, but 0-10 connection use their own. As a result, if any 0-8/0-9/0-9-1 connections are made to the broker, you can have connections of differnt protocol versions sharing a connection ID number, making some logging unclear. The connection ID numbering sequence should be made uniform across all protocols. -- 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-3386) subscriptions on 0-8/0-9/0-9-1 based connections share a ID generator, but subscriptions on 0-10 connection use their own
subscriptions on 0-8/0-9/0-9-1 based connections share a ID generator, but subscriptions on 0-10 connection use their own - Key: QPID-3386 URL: https://issues.apache.org/jira/browse/QPID-3386 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.10, 0.9, 0.8, 0.7, 0.6, 0.11, 0.12 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.13 Subscriptions on 0-8/0-9/0-9-1 based connections share a ID generator, but subscriptions on 0-10 connection use their own. As a result, if any 0-8/0-9/0-9-1 connections are made to the broker, you can have subscriptions on differnt connections sharing a subscription ID number, making some logging unclear. The subscription ID numbering sequence should be made uniform across all connections. -- 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-3387) QueueEntries can hold the Subscriptions which rejected them in memory after they are closed
[ https://issues.apache.org/jira/browse/QPID-3387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-3387: - Description: QueueEntries can hold Subscriptions which rejected them in memory after they are closed, due to the implementation of the isRejectedBy() method. This is further compounded by the Subscriptions having a reference to the channel/session they belong to, which in the case of a 0-10 ServerSession can be an extremely heavy weight object in the wrong conditions. The isRejectedBy() implementation should be updated to function without requiring a reference to the Subscription itself, thus preventing the retention leak. I have had a simple patch for this for a while, its just waiting for QPID-3386 being done (which it almost is, will get it committed shortly). was: QueueEntries can hold Subscriptions which rejected them in memory after they are closed, due to the implementation of the isRejectedBy() method. This is further compounded by the Subscriptions having a reference to the channel/session they belong to, which in the case of a 0-10 ServerSession can be an extremely heavy weight object in the wrong conditions. The isRejectedBy() implementation should be updated to function without requiring a reference to the Subscription itself, thus preventing the retention leak. I have had a simple patch for this for a while, its just waiting for QPID-3336 being done (which it almost is, will get it committed shortly). > QueueEntries can hold the Subscriptions which rejected them in memory after > they are closed > --- > > Key: QPID-3387 > URL: https://issues.apache.org/jira/browse/QPID-3387 > Project: Qpid > Issue Type: Bug > Components: Java Broker >Affects Versions: 0.5, 0.6, 0.7, 0.8, 0.9, 0.10, 0.11, 0.12 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.13 > > > QueueEntries can hold Subscriptions which rejected them in memory after they > are closed, due to the implementation of the isRejectedBy() method. This is > further compounded by the Subscriptions having a reference to the > channel/session they belong to, which in the case of a 0-10 ServerSession can > be an extremely heavy weight object in the wrong conditions. The > isRejectedBy() implementation should be updated to function without requiring > a reference to the Subscription itself, thus preventing the retention leak. > I have had a simple patch for this for a while, its just waiting for > QPID-3386 being done (which it almost is, will get it committed shortly). -- 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-3387) QueueEntries can hold the Subscriptions which rejected them in memory after they are closed
QueueEntries can hold the Subscriptions which rejected them in memory after they are closed --- Key: QPID-3387 URL: https://issues.apache.org/jira/browse/QPID-3387 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.10, 0.9, 0.8, 0.7, 0.6, 0.5, 0.11, 0.12 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.13 QueueEntries can hold Subscriptions which rejected them in memory after they are closed, due to the implementation of the isRejectedBy() method. This is further compounded by the Subscriptions having a reference to the channel/session they belong to, which in the case of a 0-10 ServerSession can be an extremely heavy weight object in the wrong conditions. The isRejectedBy() implementation should be updated to function without requiring a reference to the Subscription itself, thus preventing the retention leak. I have had a simple patch for this for a while, its just waiting for QPID-3336 being done (which it almost is, will get it committed shortly). -- 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-3333) Make Python SWIG bindings a drop-in replacement for pure Python qpid.messaging package
[
https://issues.apache.org/jira/browse/QPID-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079317#comment-13079317
]
Robbie Gemmell commented on QPID-:
--
The commit for this, r1145698, seems to have broken (log below) the python
bindings build on my RHEL 5.3 installation, which has python 2.4.3 and swig
1.3.29 on it. Is a particular version of python or swig required but not being
enforced via the configure script?
Thanks,
Robbie
{noformat}
Making all in python
make[2]: Entering directory
`/home/gemmellr/workspace/qpid/qpid/cpp/bindings/qpid/python'
/usr/bin/swig -c++ -python -w362,401 -I../../../include -I../../../include
-I../../../src/qmf -I../../../src -I../../../src -I../../../src/qmf
-I/usr/include -o cqpid.cpp ./python.i
/usr/bin/swig -c++ -python -w362,401 -I../../../include -I../../../include
-I../../../src/qmf -I../../../src -I../../../src -I../../../src/qmf
-I/usr/include -o cqpid.cpp ./python.i
../../../include/qpid/messaging/Address.h:153: Warning(361): operator! ignored
../../../include/qpid/messaging/Address.h:153: Warning(361): operator! ignored
../../../include/qpid/messaging/Address.h:152: Warning(503): Can't wrap
'operator bool' unless renamed to a valid identifier.
../../../include/qpid/messaging/Address.h:152: Warning(503): Can't wrap
'operator bool' unless renamed to a valid identifier.
../../../include/qpid/messaging/Message.h:199: Warning(467): Overloaded
qpid::messaging::decode(qpid::messaging::Message const
&message,qpid::types::Variant::Map &map) not supported (no type checking rule
for 'qpid::types::Variant::Map &').
../../../include/qpid/messaging/Message.h:211: Warning(467): Overloaded
qpid::messaging::decode(qpid::messaging::Message const
&message,qpid::types::Variant::List &list,std::string const
&encoding=std::string()) not supported (no type checking rule for
'qpid::types::Variant::List &').
../../../include/qpid/messaging/Message.h:199: Warning(467): Overloaded
qpid::messaging::decode(qpid::messaging::Message const
&message,qpid::types::Variant::Map &map) not supported (no type checking rule
for 'qpid::types::Variant::Map &').
../../../include/qpid/messaging/Message.h:211: Warning(467): Overloaded
qpid::messaging::decode(qpid::messaging::Message const
&message,qpid::types::Variant::List &list,std::string const
&encoding=std::string()) not supported (no type checking rule for
'qpid::types::Variant::List &').
../../../include/qpid/messaging/Message.h:223: Warning(467): Overloaded
qpid::messaging::encode(qpid::types::Variant::Map const
&map,qpid::messaging::Message &message) not supported (no type checking rule
for 'qpid::types::Variant::Map const &').
../../../include/qpid/messaging/Message.h:235: Warning(467): Overloaded
qpid::messaging::encode(qpid::types::Variant::List const
&list,qpid::messaging::Message &message,std::string const
&encoding=std::string()) not supported (no type checking rule for
'qpid::types::Variant::List const &').
../../../include/qpid/messaging/Message.h:223: Warning(467): Overloaded
qpid::messaging::encode(qpid::types::Variant::Map const
&map,qpid::messaging::Message &message) not supported (no type checking rule
for 'qpid::types::Variant::Map const &').
../../../include/qpid/messaging/Message.h:235: Warning(467): Overloaded
qpid::messaging::encode(qpid::types::Variant::List const
&list,qpid::messaging::Message &message,std::string const
&encoding=std::string()) not supported (no type checking rule for
'qpid::types::Variant::List const &').
../../../include/qpid/messaging/Connection.h:80: Warning(467): Overloaded
qpid::messaging::Connection(std::string const &url,qpid::types::Variant::Map
const &options=qpid::types::Variant::Map()) not supported (no type checking
rule for 'qpid::types::Variant::Map const &').
../../../include/qpid/messaging/Connection.h:80: Warning(467): Overloaded
qpid::messaging::Connection(std::string const &url,qpid::types::Variant::Map
const &options=qpid::types::Variant::Map()) not supported (no type checking
rule for 'qpid::types::Variant::Map const &').
make all-am
make[3]: Entering directory
`/home/gemmellr/workspace/qpid/qpid/cpp/bindings/qpid/python'
if /bin/sh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
-I. -I../../../src -I../../../include -I../../../include -I../../../src/qmf
-I../../../src -I../../../src -I../../../include -I../../../include
-I../../../src/qmf -I../../../src -I../../../src -I/usr/include/python2.4
-fno-strict-aliasing -g -O2 -MT _cqpid_la-cqpid.lo -MD -MP -MF
".deps/_cqpid_la-cqpid.Tpo" -c -o _cqpid_la-cqpid.lo `test -f 'cqpid.cpp' ||
echo './'`cqpid.cpp; \
then mv -f ".deps/_cqpid_la-cqpid.Tpo" ".deps/_cqpid_la-cqpid.Plo";
else rm -f ".deps/_cqpid_la-cqpid.Tpo"; exit 1; fi
mkdir .libs
g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../include
-I../../../include -I../../../src/qmf -I../../../src -I../../../src
[jira] [Updated] (QPID-3390) the Java broker does not validate the exchange-declare arguments are supported
[ https://issues.apache.org/jira/browse/QPID-3390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-3390: - Issue Type: Bug (was: Improvement) > the Java broker does not validate the exchange-declare arguments are supported > -- > > Key: QPID-3390 > URL: https://issues.apache.org/jira/browse/QPID-3390 > 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: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.13 > > > The Java broker does not currently validate the arguments supplied are > supported, and simply ignores ones which are not. The 0-10 spec requires that > a 'NOT_IMPLEMENTED' session execution exception be raised when presented with > an exchange declare argument the broker doesn't have knowledge of; this > should be implemented. -- 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-3390) the Java broker does not validate the exchange-declare arguments are supported
the Java broker does not validate the exchange-declare arguments are supported -- Key: QPID-3390 URL: https://issues.apache.org/jira/browse/QPID-3390 Project: Qpid Issue Type: Improvement Components: Java Broker Affects Versions: 0.10, 0.9, 0.8, 0.7, 0.6, 0.11, 0.12 Reporter: Robbie Gemmell Assignee: Robbie Gemmell Fix For: 0.13 The Java broker does not currently validate the arguments supplied are supported, and simply ignores ones which are not. The 0-10 spec requires that a 'NOT_IMPLEMENTED' session execution exception be raised when presented with an exchange declare argument the broker doesn't have knowledge of; this should be implemented. -- 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-3391) the C++ broker does not validate the exchange-declare arguments are supported
the C++ broker does not validate the exchange-declare arguments are supported - Key: QPID-3391 URL: https://issues.apache.org/jira/browse/QPID-3391 Project: Qpid Issue Type: Bug Components: C++ Broker Affects Versions: 0.13 Reporter: Robbie Gemmell Fix For: Future The C++ broker does not currently validate the arguments supplied are supported, and simply ignores ones which are not. The 0-10 spec requires that a 'NOT_IMPLEMENTED' session execution exception be raised when presented with an exchange declare argument the broker doesn't have knowledge of; this should be implemented. -- 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-3392) Implement support for exchange creation arguments and associated functionality for the Java broker
Implement support for exchange creation arguments and associated functionality for the Java broker -- Key: QPID-3392 URL: https://issues.apache.org/jira/browse/QPID-3392 Project: Qpid Issue Type: Improvement Components: Java Broker Affects Versions: 0.13 Reporter: Robbie Gemmell Fix For: Future The Java broker does not currently support arguments being supplied during exchange creation, which was the cause of the failures being seen in QPID-2903 under the 0-10 test profile, particialy caused by its lack of validation for supported arguments (QPID-3390). The C++ broker supports exchange creation arguments such as 'qpid.ive' for the Initial Value Exchange functionality. Support for arguments should be added, along with the associated functionality required. -- 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-2903) AddressBasedDestinationTest#testCreateExchange fails on java.0.10 test profiles
[ https://issues.apache.org/jira/browse/QPID-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned QPID-2903: Assignee: Robbie Gemmell > AddressBasedDestinationTest#testCreateExchange fails on java.0.10 test > profiles > --- > > Key: QPID-2903 > URL: https://issues.apache.org/jira/browse/QPID-2903 > Project: Qpid > Issue Type: Bug >Affects Versions: 0.6 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > > AddressBasedDestinationTest#testCreateExchange fails on java.0.10 test > profiles (it is currently excluded). To rectify this an arguments parameter > must be added to exchange creation implementation in the broker. > Testcase: testCreateExchange took 3.644 sec > Caused an ERROR > null > java.lang.NullPointerException > at > org.apache.qpid.client.AMQSession_0_10.matchProps(AMQSession_0_10.java:1074) > at > org.apache.qpid.client.AMQSession_0_10.isExchangeExist(AMQSession_0_10.java:1022) > at > org.apache.qpid.test.client.destination.AddressBasedDestinationTest.testCreateExchange(AddressBasedDestinationTest.java:276) > at > org.apache.qpid.test.utils.QpidBrokerTestCase.runBare(QpidBrokerTestCase.java:232) > at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:120) -- 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] [Closed] (QPID-2903) AddressBasedDestinationTest#testCreateExchange fails on java.0.10 test profiles
[ https://issues.apache.org/jira/browse/QPID-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell closed QPID-2903. Resolution: Not A Problem Closing this JIRA out as 'not a problem' because this test should always have failed against the Java broker. An underyling issue was identified as the broker failing to validate the exchange declare arguments and close the session because they arent supported; this has been raised as QPID-3090, with a feature JIRA also raised seperately as QPID-3092 to add support for exxchange-declare arguments. > AddressBasedDestinationTest#testCreateExchange fails on java.0.10 test > profiles > --- > > Key: QPID-2903 > URL: https://issues.apache.org/jira/browse/QPID-2903 > Project: Qpid > Issue Type: Bug >Affects Versions: 0.6 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > > AddressBasedDestinationTest#testCreateExchange fails on java.0.10 test > profiles (it is currently excluded). To rectify this an arguments parameter > must be added to exchange creation implementation in the broker. > Testcase: testCreateExchange took 3.644 sec > Caused an ERROR > null > java.lang.NullPointerException > at > org.apache.qpid.client.AMQSession_0_10.matchProps(AMQSession_0_10.java:1074) > at > org.apache.qpid.client.AMQSession_0_10.isExchangeExist(AMQSession_0_10.java:1022) > at > org.apache.qpid.test.client.destination.AddressBasedDestinationTest.testCreateExchange(AddressBasedDestinationTest.java:276) > at > org.apache.qpid.test.utils.QpidBrokerTestCase.runBare(QpidBrokerTestCase.java:232) > at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:120) -- 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] [Issue Comment Edited] (QPID-2903) AddressBasedDestinationTest#testCreateExchange fails on java.0.10 test profiles
[ https://issues.apache.org/jira/browse/QPID-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079355#comment-13079355 ] Robbie Gemmell edited comment on QPID-2903 at 8/4/11 12:29 PM: --- Closing this JIRA out as 'not a problem' because this test should always have failed against the Java broker. An underyling issue was identified as the broker failing to validate the exchange declare arguments and close the session because they arent supported; this has been raised as QPID-3390, with a feature JIRA also raised seperately as QPID-3392 to add support for exxchange-declare arguments. was (Author: gemmellr): Closing this JIRA out as 'not a problem' because this test should always have failed against the Java broker. An underyling issue was identified as the broker failing to validate the exchange declare arguments and close the session because they arent supported; this has been raised as QPID-3090, with a feature JIRA also raised seperately as QPID-3092 to add support for exxchange-declare arguments. > AddressBasedDestinationTest#testCreateExchange fails on java.0.10 test > profiles > --- > > Key: QPID-2903 > URL: https://issues.apache.org/jira/browse/QPID-2903 > Project: Qpid > Issue Type: Bug >Affects Versions: 0.6 >Reporter: Robbie Gemmell >Assignee: Robbie Gemmell > > AddressBasedDestinationTest#testCreateExchange fails on java.0.10 test > profiles (it is currently excluded). To rectify this an arguments parameter > must be added to exchange creation implementation in the broker. > Testcase: testCreateExchange took 3.644 sec > Caused an ERROR > null > java.lang.NullPointerException > at > org.apache.qpid.client.AMQSession_0_10.matchProps(AMQSession_0_10.java:1074) > at > org.apache.qpid.client.AMQSession_0_10.isExchangeExist(AMQSession_0_10.java:1022) > at > org.apache.qpid.test.client.destination.AddressBasedDestinationTest.testCreateExchange(AddressBasedDestinationTest.java:276) > at > org.apache.qpid.test.utils.QpidBrokerTestCase.runBare(QpidBrokerTestCase.java:232) > at org.apache.qpid.test.utils.QpidTestCase.run(QpidTestCase.java:120) -- 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-3390) the Java broker does not validate the exchange-declare arguments are supported
[ https://issues.apache.org/jira/browse/QPID-3390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-3390: - Status: Ready To Review (was: In Progress) > the Java broker does not validate the exchange-declare arguments are supported > -- > > Key: QPID-3390 > URL: https://issues.apache.org/jira/browse/QPID-3390 > 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: Robbie Gemmell >Assignee: Robbie Gemmell > Fix For: 0.13 > > > The Java broker does not currently validate the arguments supplied are > supported, and simply ignores ones which are not. The 0-10 spec requires that > a 'NOT_IMPLEMENTED' session execution exception be raised when presented with > an exchange declare argument the broker doesn't have knowledge of; this > should be implemented. -- 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-3390) the Java broker does not validate the exchange-declare arguments are supported
[ https://issues.apache.org/jira/browse/QPID-3390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell reassigned QPID-3390: Assignee: Keith Wall (was: Robbie Gemmell) Hi Keith, can your review these changes please? The broker now validates the exchange-declare arguments to ensure none are present, since we don't currently support any. If arguments are found, an executionException is raised indicating support for the arguments is not implemented. A test was added to ensure the expected behaviour with nonsense argument, at the same time splitting 2 of the existing tests (which would now error due to the validation) into versions with valid arguments (for the C++ broker at least) and those with no arguments. This allows the rest of the functionality they test to be tested with the Java broker until such time as QPID-3092 is completed. > the Java broker does not validate the exchange-declare arguments are supported > -- > > Key: QPID-3390 > URL: https://issues.apache.org/jira/browse/QPID-3390 > 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: Robbie Gemmell >Assignee: Keith Wall > Fix For: 0.13 > > > The Java broker does not currently validate the arguments supplied are > supported, and simply ignores ones which are not. The 0-10 spec requires that > a 'NOT_IMPLEMENTED' session execution exception be raised when presented with > an exchange declare argument the broker doesn't have knowledge of; this > should be implemented. -- 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-3391) the C++ broker does not validate the exchange-declare arguments are supported
[ https://issues.apache.org/jira/browse/QPID-3391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-3391: - Description: The C++ broker does not currently validate the arguments supplied are supported, and simply ignores ones which are not known. The 0-10 spec requires that a 'NOT_IMPLEMENTED' session execution exception be raised when presented with an exchange declare argument the broker doesn't have knowledge of; this should be implemented. (was: The C++ broker does not currently validate the arguments supplied are supported, and simply ignores ones which are not. The 0-10 spec requires that a 'NOT_IMPLEMENTED' session execution exception be raised when presented with an exchange declare argument the broker doesn't have knowledge of; this should be implemented.) > the C++ broker does not validate the exchange-declare arguments are supported > - > > Key: QPID-3391 > URL: https://issues.apache.org/jira/browse/QPID-3391 > Project: Qpid > Issue Type: Bug > Components: C++ Broker >Affects Versions: 0.13 >Reporter: Robbie Gemmell > Fix For: Future > > > The C++ broker does not currently validate the arguments supplied are > supported, and simply ignores ones which are not known. The 0-10 spec > requires that a 'NOT_IMPLEMENTED' session execution exception be raised when > presented with an exchange declare argument the broker doesn't have knowledge > of; this should be implemented. -- 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-3390) the Java broker does not validate the exchange-declare arguments are supported
[ https://issues.apache.org/jira/browse/QPID-3390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robbie Gemmell updated QPID-3390: - Description: The Java broker does not currently validate the arguments supplied are supported, and simply ignores ones which are not known. The 0-10 spec requires that a 'NOT_IMPLEMENTED' session execution exception be raised when presented with an exchange declare argument the broker doesn't have knowledge of; this should be implemented. (was: The Java broker does not currently validate the arguments supplied are supported, and simply ignores ones which are not. The 0-10 spec requires that a 'NOT_IMPLEMENTED' session execution exception be raised when presented with an exchange declare argument the broker doesn't have knowledge of; this should be implemented.) > the Java broker does not validate the exchange-declare arguments are supported > -- > > Key: QPID-3390 > URL: https://issues.apache.org/jira/browse/QPID-3390 > 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: Robbie Gemmell >Assignee: Keith Wall > Fix For: 0.13 > > > The Java broker does not currently validate the arguments supplied are > supported, and simply ignores ones which are not known. The 0-10 spec > requires that a 'NOT_IMPLEMENTED' session execution exception be raised when > presented with an exchange declare argument the broker doesn't have knowledge > of; this should be implemented. -- 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
