GSoC project
Hi everyone, Just thought I would let those who don't already know that my recent GSoC application was successful. I will be working on a new user interface and replacing some of the guts of the JMX Management Console for the Java broker, plus any associated JMX work required on the broker. Aidan will be my wise owl during the process. We are going to sit down for a bit of planning at some point soon, but there are some topics it would be good for everyone to discuss in advance of that. I will kick that off later today. Robbie
[jira] Updated: (QPID-1766) Implemention of selector using Xquery
[ https://issues.apache.org/jira/browse/QPID-1766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] chenta lee updated QPID-1766: - Attachment: selector.diff Fix the segmentation fault. The declaration order of XQilla and selectorQuery is wrong. XQilla should be declared before selectorQuery, because the selectorQuery should be destruct before XQilla. It is the reason we got segmentation fault when destructing the ConsumerImpl. Implemention of selector using Xquery - Key: QPID-1766 URL: https://issues.apache.org/jira/browse/QPID-1766 Project: Qpid Issue Type: Improvement Components: C++ Broker, C++ Client Environment: Linux Reporter: chenta lee Attachments: Makefile.patch, Makefile.patch, selector.diff, selector.diff, selector.patch, selector.patch, selector_broker.patch, selector_client.patch, selector_client.patch, selector_example.zip I implemented the message selector for C++ broker and client using Xquery. I will attach an example later. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Cmake build update
Steve Huston wrote: Hi Andrew, On Tue, 2009-04-21 at 15:01 -0400, Steve Huston wrote: Hi Qpideers, A while back I mentioned that Microsoft funded efforts to improve the qpid C++ build process, align the Linux/UNIX and Windows build processes and end the problem where the Windows builds are a step behind the Linux builds when files change. As mentioned here previously, the initial approach to this is to try Cmake (www.cmake.org) and that has been going along well. The basic libraries (common, client, broker, cluster, ssl) and broker build are integrated. It's not yet ready for prime time, as the test build and execution isn't yet integrated. That'll probably be ready for general evaluation within a couple of weeks, but for the adventurous among us who want an early look, the work is happening on the subversion cmake branch (https://svn.apache.org/repos/asf/qpid/branches/cmake) Can this work sit alongside the existing build systems? If so I don't think there's any reason not to do this work on the trunk. It almost can at this point. The only real speed bump is one of the code generators - it was changed to generate cmake lists in a way that doesn't preserve the Makefile way. The other generator was modified in a compatible way. I'll look into making them both be able to do both .mk and .cmake output. Other than that there were minor macro changes. As I recall, it's primarily that CONF_FILE and MODULE_PATH. These are used in both client and broker cases and specified with different values depending on the component being built. I changed this to QPIDD_CONF_FILE, and QPIDC_CONF_FILE (and similar for MODULE_PATH) and they're all set in the configuration step for cmake. It would certainly be an easier transition if the cmake infrastructure doesn't happen at a stroke, dismantling the existing build system, but overlapping if possible for a short while (say a week or two). I agree. I think having both on trunk is essential for cmake adoption. If we can have the two co-exist while all concerned migrate their build systems in their own time then I think we will be able to get rid of libtool in fairly short order. On the other hand if try to propose a big bang where libtool vanishes and cmake appears, we'll probably never get everyone to agree on the right time to do it. I'm looking forward to seeing cmake on the trunk :) - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
JMX interface stability and versioning
Hi all. Just kicking off some discussion on issues likely to affect what I do during the GSoC work, to help Aidan and I put together a better plan of action. One upcoming elephant to consider is going to be AMQP 1.0 support and how its new messaging/component model will affect the management interfaces. As the Java broker is presumably going to support the current protocol versions and gain 1.0 (+ 0-10), this could/will somewhat muddy the management waters. Eg, Exchanges (sort of) going away, Links being added...VirtualHosts becoming merely part of the implementation details etc. This would presumably mean some methods being added, removed, or possibly moved to new/existing MBeans. Alternatively, an entirely new set of JMX interfaces could be exposed and coexist with the existing set to handle the new model and old models seperately, moving to just the new set at some future time. So many possible options... Another issue for discussion is versioning. In the previous work I did on the broker JMX capabilities, some issues cropped up with compatibility due to a required a change in the expected input (going from MD5-hashed password input to plain text to support a consistent user management interface) for some of the methods. Additional changes included altering of some attribute units for correctness and consistency, and introduction of some new attributes for FTD (since removed). These changes made it necessary and/or desirable to be able to distinguish the versions of each JMX MBean encountered, so a version property was added to the JMX ObjectName to do so. Depending on changes made to account for 1.0 management, it may be necessary or useful to rework this as well. Any thoughts out there? :) Robbie - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [python]: sketch of high-level API
I like what I see, I have a bunch of questions. from qpid.api import * # open a connection conn = Connection.open(localhost) conn.start() If I start the connection before creating sessions, does that mean each connection starts as soon as it is created? # create a session ssn = conn.session() # send a message sender = ssn.sender(my-queue) sender.send(Hello World!) # fetch the message receiver = ssn.receiver(my-queue) msg = receiver.fetch(0) print msg # acknowledge the message ssn.acknowledge(msg) How does this work with Topic Exchanges? The XML Exchange? Could there be a default timeout for receiverfetch()? # define a listener def printer(msg): print L: %r % msg ssn.acknowledge(msg) # register the listener receiver.listen(printer) # send a bunch more messages for content in [this, is, a, test]: sender.send(content) # disconnect for a while conn.stop() conn.disconnect() # reconnect and continue doing work conn.connect() conn.start() # unregister the listener receiver.listen(None) Can a receiver have only one listener? # send more messages sender.send(Hello Again!) # drain the queue while True: try: msg = receiver.fetch(0) print D: %r % msg except Empty: break # acknowledge all outstanding messages ssn.acknowledge() print done # close the connection conn.close() How do I set delivery properties? Message properties? How do I create queues? Bindings? Jonathan - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: [0.5][README] Upcoming SVN surgery
Hi Aidan, I was wondering whether you have an update on the planned schedule for 0.5. I know you're all working hard to stabilize the Java side of the house but, selfishly, I'm keen to get the Windows updates to the C++ that Steve has been working on out to the public in an official build. I know we were originally targeting 3/27, what's your best guess on a revised schedule. Thanks, Dave. -Original Message- From: aidan.skin...@gmail.com [mailto:aidan.skin...@gmail.com] On Behalf Of Aidan Skinner Sent: Friday, April 10, 2009 8:35 AM To: dev@qpid.apache.org Subject: [0.5][README] Upcoming SVN surgery This is a watch your head, incoming svn surgery email. Sorry. The Java server is currently the long sticking out thing that's holding up 0.5, and there's significant enough concern about some of the changes that have gone in that it's probably best to revert them. Martin, Marnie and, to a lesser extent, I have been working on these issues and feel that the best way forward is to back out the work around TransactionLog and flow to disk and ship without them. In the interests of doing so expediently and preserving a clear, coherent SVN history, we're going to do the following: 1. copy trunk at a known good revision from before this work started onto a newtip[1] branch 2. use the new 1.5 svn merge tooling to take the good patches from trunk to newtip 2.5 test newtip to ensure that the resulting broker is sound, safe and sane. 3. move trunk/qpid/java/broker to a holding branch so that the work isn't lost and can be easily retrieved later 4. move newtip/qpid/java/broker to trunk/qpid/java/broker and copy it to 0.5-release/qpid/java/broker and then proceed from there. This should be the shortest path to a releasable code base, albiet unfortunately losing some features we'd love to have. That seems like a better plan than continuing to bug fix and delaying the other components unnecessarily. I'm not entirely sure about timescales, I expect that 4 will occur towards the middle of next week. Shout if you have a problem with this. - Aidan [1] probably not its actual name -- Apache Qpid - World Domination through Advanced Message Queueing http://qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: Cmake build update
Good points, Alan and Andrew... I fixed up the rubygen script to be able to generate Makefile and Cmake fragments, and have run a autoconf-style build on the cmake branch successfully... Will now work on merging things back to trunk. I'll let you know when it's available. Thanks for the suggestions and support. -Steve -Original Message- From: Alan Conway [mailto:acon...@redhat.com] Sent: Wednesday, April 22, 2009 9:38 AM To: dev@qpid.apache.org Subject: Re: Cmake build update Steve Huston wrote: Hi Andrew, On Tue, 2009-04-21 at 15:01 -0400, Steve Huston wrote: Hi Qpideers, A while back I mentioned that Microsoft funded efforts to improve the qpid C++ build process, align the Linux/UNIX and Windows build processes and end the problem where the Windows builds are a step behind the Linux builds when files change. As mentioned here previously, the initial approach to this is to try Cmake (www.cmake.org) and that has been going along well. The basic libraries (common, client, broker, cluster, ssl) and broker build are integrated. It's not yet ready for prime time, as the test build and execution isn't yet integrated. That'll probably be ready for general evaluation within a couple of weeks, but for the adventurous among us who want an early look, the work is happening on the subversion cmake branch (https://svn.apache.org/repos/asf/qpid/branches/cmake) Can this work sit alongside the existing build systems? If so I don't think there's any reason not to do this work on the trunk. It almost can at this point. The only real speed bump is one of the code generators - it was changed to generate cmake lists in a way that doesn't preserve the Makefile way. The other generator was modified in a compatible way. I'll look into making them both be able to do both .mk and .cmake output. Other than that there were minor macro changes. As I recall, it's primarily that CONF_FILE and MODULE_PATH. These are used in both client and broker cases and specified with different values depending on the component being built. I changed this to QPIDD_CONF_FILE, and QPIDC_CONF_FILE (and similar for MODULE_PATH) and they're all set in the configuration step for cmake. It would certainly be an easier transition if the cmake infrastructure doesn't happen at a stroke, dismantling the existing build system, but overlapping if possible for a short while (say a week or two). I agree. I think having both on trunk is essential for cmake adoption. If we can have the two co-exist while all concerned migrate their build systems in their own time then I think we will be able to get rid of libtool in fairly short order. On the other hand if try to propose a big bang where libtool vanishes and cmake appears, we'll probably never get everyone to agree on the right time to do it. I'm looking forward to seeing cmake on the trunk :) - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: [c++]: Sketch of a high-level, protocol independent API
On the whole, I really like this. Comparing the example programs to the existing examples, I think it does simplify quite a bit. A few thoughts: 1. Streaming data into or out of messages I really want to be able to stream into or out of messages directly. Instead of: message_data Message i; message.setData(message_data.str()); I would like to be able to do something like: message.getData() Message i; 2. Having a Subscription object is really very helpful. 3. These examples don't create queeus and bindings explicitly - is that intentional? I assume the existing APIs continue to exist for this, but that is not going to bridget API versions. 4. I notice you do not use keyword arguments. Is the move away from them intentional? Why? Jonathan - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: GSoC project
Congrads Robbie. Just thought I would let those who don't already know that my recent GSoC application was successful. I will be working on a new user interface and replacing some of the guts of the JMX Management Console for the Java broker, plus any associated JMX work required on the broker. Aidan will be my wise owl during the process. Aidan is the best mentor... You are so lucky to be a student of him :-) Lahiru We are going to sit down for a bit of planning at some point soon, but there are some topics it would be good for everyone to discuss in advance of that. I will kick that off later today. Robbie -- Apache Qpid, Worlds dominant messaging middleware..!!!
