Re: [JMS] Creating connections & destinations dynamically
On Mon, Feb 7, 2011 at 6:55 PM, Andrew Kennedy < andrewinternatio...@gmail.com> wrote: > On 7 Feb 2011, at 17:00, Rajith Attapattu wrote: > >> So far I have only heard positive comments about this approach. >> Does anybody have any concerns about the approach in general or any >> comments >> about how it should be done if it's needed ? >> > > Well, not negative, but I *do* have some questions, which are possibly just > due to my lack of knowledge of existing documentation and processes. > > Basically, how are we going to ensure that this new API never gets > deprecated? Where do we state/promise these things? There isn't a page of > Javadoc on the Qpid site showing our fixed, stable, public API sets. I'm > aware of the docbook/PDF documentation and Java programming guides, but I > was thinking of something more formal. Anyway, if we can make such a > statement about your proposed API, Very good question. I have the same concern as yours for all our public APIs not just the java client. We do proclaim that we have a common Messaging API for all our non JMS clients (Ex. Python, C++, Perl ..etc) But no where in our website (or for that matter in our documentation) we specify what this common API is. I think we need to specify this prominently somewhere in our documentation. We could list our Java client extensions in the same location. > why can't we just make that same statement about AMQConnectionFactory, and > add some extra helper methods to it, as needed, documenting and publishing > as we go? I believe the effect would be identical... > To begin with I don't think the AMQConnectionFactory is a good candidate to expose as a public interface as it is. There are many public methods in it that are unnecessary for our purpose and will only confuse users. There are also several helper methods that we may need to add like createDestination which will only make the ConnectionFactory implementation bloated. Also there can be more than one ConnectionFactory implementation in the code base. There has been some interest in one which can do connection pooling. We need to find a way to hide all these complexities behind a simple stable interface that can be easily maintained. Exposing the AMQConnectionFactory as it is will not cut it. > In principle, I agree we need to set up some stable APIs but, why not start > off by documenting and improving the existing ones first, and then add your > proposed code in there? > I am not against this at all. But I am not sure which of the existing ones are good candidates for being promoted as public interfaces (obviously after some rework) ? > > I would suggest firstly deprecating AMQConnectionFactory entirely and > making a QpidConnectionFactory interface, and having some implementations > such as an AbstractQpidConnectionfractory parent and then > QpidJndiConnectionFactory, QpidPropertiesFileConnectionfactory or > QpidUrlConnectionFactory, and also a QpidConnectionFactoryHelper class with > your static methods. We then document the static methods and the interface > methods as public APIs, as well as any extra methods provided by the other > implementations. Note that this gets rid of AMQP in the class name, which > is, IMHO, a Bad Thing. I suspect most of the API will probably consist of > constructors, or maybe static methods to get concrete implementations, and > there's still a few more things we need to think about here in terms of API > design. > > Does any of this fit in with your ideas at all? > I think regardless of exposing a public interface or not, we probably need to do some refactoring along the lines you are proposing. The JMS client is certainly in need of some refactoring, especially the various AMQXXX classes. However IMO any of that work should be done with keeping 1.0 in mind. There are lots of ideas about how the restructuring should be and the timing etc.. That is why I think it's all the more important that we come up with a very simple interface where we can easily swap any implementation at any time without affecting our users. Exposing what we have now, might not help us here. > If we do this properly, we can also improve our Spring integration, since > the org.apache.qpid.jndi.PropertiesFileInitialContextFactory is a bit too > generic, replacing it with the above factory concrete implementations? > Integration with various containers is becoming increasingly important. There have been various queries about integrating into other jndi mechanisms, various app servers, ESB's, containers like spring etc.. Therefore we need to consider all these possibilities when designing our interface. > Other classes we need to expose with proper Javadoc documentation would be > the URL classes, which possibly need a bit of attention if we want to add > the new JMS URL syntax as well. These can maybe all extend a generic QpidUrl > class, with JmsUrl, BindingUrl, AddressUrl, AmqpUrl or whatever as concrete > implementations to choose from, making
Re: svn commit: r1069126 [1/24] - in /qpid/site/docs/books: 0.7/AMQP-Messaging-Broker-CPP-Book/html-single/ 0.7/AMQP-Messaging-Broker-CPP-Book/html/ 0.7/AMQP-Messaging-Broker-CPP-Book/pdf/ 0.7/AMQP-Me
On 02/09/2011 04:52 PM, Robbie Gemmell wrote: These weren't missing in so much as I deliberately elected not to commit them, being that its several megabytes of stuff we don't appear to even be using. The single-page html output has never been linked from the website that I can see, there are 6 copies of the same image files now, and the .fo files generated while making the PDF don't seem like they should ever be getting committed? Robbie Some of these pages really are missing, e.g. new chapters that have been added to Programming in Apache Qpid and some other content. I made this commit because someone was clicking on links that didn't resolve. The .fo files aren't needed. I like the single-page html, some things look a lot better there than in the PDF, and it's very easy to search for things in it. I'd like to see that linked to from the site. The documents are meant to be standalone, so that a single directory and its subdirectories can be used as a document. That's the reason the image files are copied. We could try to optimize this if there's a reason to. Jonathan - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: svn commit: r1069126 [1/24] - in /qpid/site/docs/books: 0.7/AMQP-Messaging-Broker-CPP-Book/html-single/ 0.7/AMQP-Messaging-Broker-CPP-Book/html/ 0.7/AMQP-Messaging-Broker-CPP-Book/pdf/ 0.7/AMQP-Me
These weren't missing in so much as I deliberately elected not to commit them, being that its several megabytes of stuff we don't appear to even be using. The single-page html output has never been linked from the website that I can see, there are 6 copies of the same image files now, and the .fo files generated while making the PDF don't seem like they should ever be getting committed? Robbie > -Original Message- > From: jonat...@apache.org [mailto:jonat...@apache.org] > Sent: 09 February 2011 21:40 > To: comm...@qpid.apache.org > Subject: svn commit: r1069126 [1/24] - in /qpid/site/docs/books: > 0.7/AMQP-Messaging-Broker-CPP-Book/html-single/ 0.7/AMQP-Messaging- > Broker-CPP-Book/html/ 0.7/AMQP-Messaging-Broker-CPP-Book/pdf/ 0.7/AMQP- > Messaging-Broker-Java-Book/AMQP-Messaging-Broker-Java-Book... > > Author: jonathan > Date: Wed Feb 9 21:39:27 2011 > New Revision: 1069126 > > URL: http://svn.apache.org/viewvc?rev=1069126&view=rev > Log: > Adding missing pages that were not being tracked by svn. > - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Resolved: (QPID-3040) Closed Receivers Do Not Delete Queues and Do Not Reroute Acquired Messages to Alternate Exchange
[ https://issues.apache.org/jira/browse/QPID-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Robie resolved QPID-3040. -- Resolution: Fixed Fix Version/s: 0.9 Fixed in revision 1069030 The C++ messaging client library now releases pending messages when a Receiver is closed. This releases only messages in the client's cache that have not been read. It does not release messages that have been read by the client application, but not acknowledged. > Closed Receivers Do Not Delete Queues and Do Not Reroute Acquired Messages to > Alternate Exchange > - > > Key: QPID-3040 > URL: https://issues.apache.org/jira/browse/QPID-3040 > Project: Qpid > Issue Type: Bug >Reporter: Jonathan Robie >Assignee: Jonathan Robie > Fix For: 0.9 > > > Bug description is here: > https://bugzilla.redhat.com/show_bug.cgi?id=674678 -- 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-3041) Make dist process does not package the .NET Binding source
[ https://issues.apache.org/jira/browse/QPID-3041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12992538#comment-12992538 ] Chuck Rolke commented on QPID-3041: --- >From the dev mailing list: When I add the sources to a Makefile.am then I get a packaging error from tar: file name too long. I can see several solutions: 1. Rename or move the source files. This would be tedious and not a great long term solution. 2. Use a different version of tar. Support for 256 character file names has been around for a while and would satisfy the name length problem. However, I don't take changing the tar format lightly. 3. Tar/zip the .NET Binding sources and package the resulting tar.gz file instead of the individual files. I tend to favor this approach. Any ideas or opinions? After further review option #2 is what I plan to use. Simply adding "tar-ustar" to AM_INIT_AUTOMAKE([dist-bzip2 subdir-objects tar-ustar]) fixes the issue. From the automake doc: tar-ustar selects the ustar format defined by POSIX 1003.1-1988. This format is believed to be old enough to be portable. 1988 is more than half way back to the epoch! No worries. > Make dist process does not package the .NET Binding source > -- > > Key: QPID-3041 > URL: https://issues.apache.org/jira/browse/QPID-3041 > Project: Qpid > Issue Type: Bug > Components: Dot Net Client >Affects Versions: 0.8 > Environment: Packaging >Reporter: Chuck Rolke >Assignee: Chuck Rolke > > The 0.8 kit qpid-cpp-0.8.tar.gz does not include the .NET Binding source. -- 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-3047) The QueueDepthWithSelectorTest fails on 0-10 profiles
[ https://issues.apache.org/jira/browse/QPID-3047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12992529#comment-12992529 ] Andrew Kennedy commented on QPID-3047: -- Understood. This fixes the situation where the client is requesting the queue depth, and there are queued up unsent acks because neither 1 or 2 has happenend yet. In this case, the reported queue depth will be wrong, so sending any unflushed acks beforehand is the correct thing to do for this type of synchronous operation. > The QueueDepthWithSelectorTest fails on 0-10 profiles > - > > Key: QPID-3047 > URL: https://issues.apache.org/jira/browse/QPID-3047 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.9 >Reporter: Andrew Kennedy >Assignee: Andrew Kennedy > Fix For: 0.9 > > > The QueueDepthWithSelector needs refactored to use QpidBrokerTestCase rather > than being hardcoded simply the 0-8 iVM broker. Once this is done, the test > fails on 0-10 profiles, as the session is not flushing acks correctly. -- 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-3048) InternalBrokerBasecase not removing all log actors
InternalBrokerBasecase not removing all log actors -- Key: QPID-3048 URL: https://issues.apache.org/jira/browse/QPID-3048 Project: Qpid Issue Type: Bug Components: Java Broker Affects Versions: 0.9 Reporter: Andrew Kennedy Assignee: Andrew Kennedy Priority: Minor Fix For: 0.9 The InternalBrokerbaseCase checks if CurrentActor.get() returns null, however in CurrentActor this can never happen, since we return a default if the stack is empty. Adding a removeAll method to CurrentActor will allow test cases to clean up properly. -- 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-3047) The QueueDepthWithSelectorTest fails on 0-10 profiles
[ https://issues.apache.org/jira/browse/QPID-3047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12992521#comment-12992521 ] Rajith Attapattu commented on QPID-3047: In AMQSession_0_10.java, when using AUTO_ACK or DUPS_OK the acknowledgements are batched to improve performance. The ack are flushed based one of the following conditions (which ever happens first). 1. When the ack timer fires. The ack-time is configure via qpid.session.max_ack_delay 2. if un_acked_msg_count > max_prefetch/2. For the test case you could force it to ack more frequently by having a smaller prefetch. (Please note as per the JMS spec AUTO_ACK should ack each message before it serves up the next message. However by default our AUTO_ACK acts the same as DUPS_OK.) > The QueueDepthWithSelectorTest fails on 0-10 profiles > - > > Key: QPID-3047 > URL: https://issues.apache.org/jira/browse/QPID-3047 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.9 >Reporter: Andrew Kennedy >Assignee: Andrew Kennedy > Fix For: 0.9 > > > The QueueDepthWithSelector needs refactored to use QpidBrokerTestCase rather > than being hardcoded simply the 0-8 iVM broker. Once this is done, the test > fails on 0-10 profiles, as the session is not flushing acks correctly. -- 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-3047) The QueueDepthWithSelectorTest fails on 0-10 profiles
The QueueDepthWithSelectorTest fails on 0-10 profiles - Key: QPID-3047 URL: https://issues.apache.org/jira/browse/QPID-3047 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: 0.9 Reporter: Andrew Kennedy Assignee: Andrew Kennedy Fix For: 0.9 The QueueDepthWithSelector needs refactored to use QpidBrokerTestCase rather than being hardcoded simply the 0-8 iVM broker. Once this is done, the test fails on 0-10 profiles, as the session is not flushing acks correctly. -- 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-1688) Need more powerful search functionality
[ https://issues.apache.org/jira/browse/QPID-1688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Ross resolved QPID-1688. Resolution: Fixed Fix Version/s: 0.9 This request is resolved by QPID-3046 in which a generalized, agent-side predicate capability has been introduced. > Need more powerful search functionality > --- > > Key: QPID-1688 > URL: https://issues.apache.org/jira/browse/QPID-1688 > Project: Qpid > Issue Type: Wish > Components: Qpid Managment Framework >Reporter: Ian Main >Assignee: Ted Ross > Fix For: 0.9 > > > It would be very nice to have more powerful search functionality in qpid. > Right now we just have key/value equality tests. Be nice to have regular > expressions, negation of values etc. -- 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
