Re: M4 post-release process review
On Tue, Feb 3, 2009 at 2:25 AM, Rajith Attapattu rajit...@gmail.com wrote: Agree that Qpid as a project needs to pay more attention to licensing issues. I had to update a ton of files for the ASF header across all languages and it wasn't fun at all :) The addition of a GPL library was a honest mistake and should have been caught during the review process. That's the thing I'm concerned about. Licensing Is Hard(tm), but we should really have caught this earlier than we did. Fortunately there was an obvious ASL-licensed drop-in replacement. Ripping out libs while rolling release candidates is not something I want to make a habit of though. If our review process didn't catch this, we need another way of managing dependency changes. It was ok this time, and I don't want to get into a finger pointing exercise. I just want to make sure that next time we don't roll a release which depends on GNU Frobnicator and there isn't an obvious replacement. That stuff seriously damages the hairline. The Java patch review has IMO improved compared to previous iterations. I got very good feedback for most of my patches. However I agree that certain areas had large code drops without much review, even when patches were posted and emails sent requesting review. It wasn't just large code drops, there were a number of commits which had their associated Jira either left Open or went straight to resolved, totally bypassing the process. - Aidan -- 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
Re: M5 - JIRAs/Scope
2009/1/29 Marnie McCormack marnie.mccorm...@googlemail.com: All, If you are working on (or plan to work on) the Java side for M5 - please can you scope anything you intend to do into M5 please ? Martin, Aidan I have scoped the items we're working on into M5 (and are posting about the design for new features). Aside from that, there are two other JIRAs in M5 on the Java side. If this is really the scope/plan for M5, then our roadmap needs revised for this release !! It'd be good to have some discussions about some of the bigger ticket items proposed for M5, but currently these don't appear to be on anyone's list for M5 ? C++ JIRAs for M5 would be good too, but not so dear to my heart ! FYI the Eclipse Management Console items are progressing separately to M5 as we're hoping (as raised before Xmas on the list) for a separate release of that component pre-M5. Regards, Marnie I'll start the ball rolling here with what I'm looking to achieve for M5. Remembering that we are time boxing our releases so I'll be working down this list and seeing what makes the dates: [QPID-949] Implement Flow To Disk [QPID-1168] Complete ACLv2 Implementation [QPID-1612] Split Java broker configuration into a number of files to allow validation. I'm also keen to get Robbie Gemmell's patches all committed as he has been providing a lot of patches for the Java Eclipse Management Console. Would be good to co-ordinate with the rest of the Java developers as I plan to start implementing these items directly. The designs are up on the wiki for people to look at, though as they have been there for a bit I'm sure you have all read them. :) Cheers Martin -- Martin Ritchie - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Assigned: (QPID-1374) Java client throws NullPointerException when header message properties is not set
[ https://issues.apache.org/jira/browse/QPID-1374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aidan Skinner reassigned QPID-1374: --- Assignee: Arnaud Simon (was: Aidan Skinner) Not really sure why this got assigned to me... Java client throws NullPointerException when header message properties is not set --- Key: QPID-1374 URL: https://issues.apache.org/jira/browse/QPID-1374 Project: Qpid Issue Type: Bug Components: Java Client Affects Versions: M4 Reporter: Arnaud Simon Assignee: Arnaud Simon Fix For: M5 The java JMS layer expects that all messages have message properties set. This is however not always the case as AMQP doesn't mandate the message properties header to always be set. For example the python client doesn't set the message properties when they are empty. How to reproduce: - Send messages using the python client - Consume those messages with a java consumer Solution: update AbstractJMSMessageFactory and MessageFactoryRegistry for dealing with null message properties header -- 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: version number proposal
On Tue, Feb 3, 2009 at 2:05 AM, Rajith Attapattu rajit...@gmail.com wrote: Having gone through 5 releases and looking at the queries on the user/dev list, my experience is that release by language has not quite worked. We're not doing release by language. We're doing releases of the whole codebase, some bits of which have lost the ability to talk to other bits over time. While that's certainly unfortunate, it's not something which slicing release by functional area is going to change. It's not a process issue, it's a decision about preserving compatability. Instead we have ended up with a very confusing matrix in our download page and this has confused potential users to no end. The matrix is really confusing, there's probably a clearer way to represent things. As I have suggested in another thread I think we need to do component releases in the future. i.e Have separate downloads for broker/clients/management tools than one monolithic file. I think having seperate downloads for each is a good plan. When we move to such a model it makes sense (As Rafi suggested) to have a common version number for brokers and one across all clients and one across all management tools. This seems rather odd given that they're all at different levels of maturity, evolve indepenently of each other and really share very little in common other than functional area. To take management as an example, the JMX GUI, CLI and Qman are all at different stages and that's not even taking the QMF bits into account. The above scheme will make it easy for potential users to make a clear decision. It also provides them with a clear path to upgrade and maintenance. A clear path to upgrade and maintenance would surely be to preserve compatability. I don't see how splitting releases into three broad functional areas makes any difference to this. P.S I also think that we need to organize our dir structure (as Rafi/Rob pointed out) and the wiki as client/broker/management tools. This seems insane to me for the reasons outlined above. Eventually a particular management tool should work with both java and c++ brokers. So it make sense to partition the wiki/documentation space by component rather than language. Right now the wiki is by language and it's kinda of all over the place. This does make more sense. Somewhere there's a freemind file with a reasonable hierarchy, and there's an old export organised something along those lines in branches/forrest-site. I ran out of steam on that and it's rotted a bit now though. - Aidan -- 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
Re: [ShortListing] Qpid Slogan
On Fri, Jan 30, 2009 at 10:58 AM, Martin Ritchie ritch...@apache.org wrote: Once we have a Top 10 then we can decide if we want to: a) Vote on a winner takes all b) Take the top n for use. c) Reopen the suggestions. +10 c) All the current ones make me sad panda to a greater or lesser extent. - Aidan -- 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
Re: version number proposal
Aidan Skinner wrote:
I'm of two minds on this. On the one hand I think your proposal probably
most accurately reflects the reality of the current situation. On the other
hand, I don't think the current situation is really a great place for us to
be as a project.
I think version numbers which reflect reality is probably a plus. I
don't think it would be detrimental to the one team, one project, one
qpid goal. There are definately issues there, but I don't think
independently varying version numbers would add to those.
Part of my point is that the extent to which they reflect reality
depends on where you want things to be going.
One view is that JMS is API stable, and other clients are not, therefore
JMS gets a nice stable version number, and the other components don't.
However in some ways that's a bit missleading since we're not trying to
version the JMS API (we don't need to, it already has its own version
number), we're versioning our *implementation* of JMS, and to a much
greater extent the maturity of our *implementation* does depend on the
other pieces of the project, e.g. the broker, and the level of interop
with other clients, and one version number better reflects *that* reality.
In particular, one of the core goals of qpid is to provide a consistent
cross-language messaging experience, and that includes equivalently stable
and similar looking/feeling APIs across all the client languages we support.
I'm not sure that similar looking/feeling APIs are really desierable.
I'd rather see idiomatic APIs that feel comfortable and natural in the
language than shoe-horning JMS into C++.
I'm not sure what would require shoe-horning. The JMS API is very
simple, and could easily be translated idiomatically into any of our
current client languages, e.g in ruby it would be quite possible to
model connection, session, producer, consumer, and message and yet still
have consumer.on_message {|m| blah ... } rather than
consumer.setMessageListener(...).
That said, my statement in no way implied that we should mindlessly
translate JMS into the other languages, simply that we need some set of
APIs that are at a similar level of abstraction such that they can each
support multiple protocols underneath.
The fact of the matter is that the various clients and brokers are at
differing levels of robustness, internal stability and API stability
and that's not something that I really see changing anytime soon.
Actually at the moment I think they're all fairly close. There are
really only two outliers: JMS and dotnet. JMS being more API stable due
to being JMS, and dotnet being in an exceptional category at the moment
since we haven't really settled on how we're going to provide something
there in a sustainable manner going forward.
IMHO the appropriate way to make the situation with the JMS client clear
is to actually state on our download page that it is a JMS client, and
maybe even put JMS in the artifact name. This will have infinitely more
meaning than any version number choice.
As for dotnet, I think that probably deserves its own discussion, since
the issue there is really more about how we are going to maintain the
thing going forward, and less about what it's current version number
should be.
So for me, I'd either stick with the Mx version numbers, or use a pre 1.0
version numbering scheme until we've reached that goal of a consistent cross
language messaging experience, and only from there move into post 1.0
territory.
I could buy into s/M/0./ for everything (but not s/M/1./). I know some
people are opposed to releasing 0.x versions for marketing reasons,
but that essentially removes any useful information from the rev.
I agree, and personally I don't think marketing should enter into the
version number discussion. I think once you let marketing in, you've
removed all hope for sane and useful version numbers. ;)
--Rafael
-
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Updated: (QPID-1627) Three T-Shirt Alternatives
[ https://issues.apache.org/jira/browse/QPID-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] michael j. goulish updated QPID-1627: - Attachment: qpid_shirts.jpg Three T-Shirt Alternatives -- Key: QPID-1627 URL: https://issues.apache.org/jira/browse/QPID-1627 Project: Qpid Issue Type: Wish Reporter: michael j. goulish Priority: Trivial Attachments: qpid_shirts.jpg All three are based on the I'm with Qpid! idea. Just different shapes for the arrow. Original, Manta, and Chevron. -- 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: version number proposal
On Tue, Feb 3, 2009 at 1:34 PM, Carl Trieloff cctriel...@redhat.com wrote: Marnie McCormack wrote: I am not passionate about version numbers or marketing etc etc, but at risk of physical harm from my right hand side .. i think having different versions for the different bits is very consuing for users. I'm all for 1.6 or even 0.6 across the board next time. My kevlar will be arriving soon. +1 -- well said Marnie Seems like we're coming to a consensus on s/M/0./... - Aidan -- 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
Re: Possible T-shirt image
Mark -- Thanks for kind words, and ideas about the logo. Here are 3 alternatives: https://issues.apache.org/jira/browse/QPID-1627 original -- the one you've already seen manta -- even more manta-like than the original, and chevron -- that looks more like your fast-forward idea. I do like the idea of it looking fast -- I actually think that Manta accomplishes that best because the shape itself looks fast, rather than suggesting a symbol from media-players that means fast forward. IMHO that's one indirection or abstraction too many. Also, personally, I think the arrow ought to point directly at the Qpid slogan -- not at the hypothetical person you're walking next to. So that, effectively, the logo says AMQP is fast and it's with Qpid. Please let us know your reactions to these three alternatives. ( And everybody else, please! ) We want it to say: 1. Fast 2. AMQP == Qpid 3. This is cool / sexy That's a lot to ask of 4 words, 6 polygons, and one exclamation point, but I think we're getting there! On Sat, 2009-01-31 at 12:11 +, Mark Atwell wrote: Great work Michael! I like the idea! Though currently it looks (to me) a little like a ray - i.e. a sting-ray or eagle-ray. Admittedly this appeals to me - I'm an underwater photographer - look for me on Flickr. However, if the blue bit could be made to stretch up and down a bit more to be the same size as the right-hand chevron, it would it look more arrow-like i.e. something like: = I'm no graphic artist! Actually thinking about it, also making the above change might also ape the classic 'fast-forward' symbol so it could subliminally imply speed (but crucially without any formal commitment! :o) ? Perhaps placing the arrow above or below the words would allow it to point to a nearby colleague a la the original T-shirt. Thoughts? -- Mark On Sat, Jan 31, 2009 at 8:06 AM, Lahiru Gunathilake lah...@apache.orgwrote: That's pretty good. I prefer to change the colors of the logo, but we have to keep AMQP colors which is not that colorful :-( Lahiru On Sat, Jan 31, 2009 at 12:02 AM, michael goulish mgoul...@redhat.com wrote: Oops, thanks. How about this: https://issues.apache.org/jira/browse/QPID-1624 On Fri, 2009-01-30 at 23:55 -0800, Lahiru Gunathilake wrote: Hi Michael, I think attachments are not allowed in the list. You have to upload it in to somewhere and send us the link. Lahiru On Fri, Jan 30, 2009 at 11:51 PM, michael goulish mgoul...@redhat.com wrote: here's a concept for a t-shirt image based on the i'm with qpid slogan (attached) :-) - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org -- Apache Qpid, Worlds dominant messaging middleware..!!! - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
[jira] Commented: (QPID-1627) Three T-Shirt Alternatives
[ https://issues.apache.org/jira/browse/QPID-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12669997#action_12669997 ] Aidan Skinner commented on QPID-1627: - The AMQP logo is (c) the AMQP working group, we shouldn't use it for our swag without written permission. As we're deforming the logo, we could keep the colours and remove the letters. Three T-Shirt Alternatives -- Key: QPID-1627 URL: https://issues.apache.org/jira/browse/QPID-1627 Project: Qpid Issue Type: Wish Reporter: michael j. goulish Priority: Trivial Attachments: qpid_shirts.jpg All three are based on the I'm with Qpid! idea. Just different shapes for the arrow. Original, Manta, and Chevron. -- 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
[jira] Created: (QPID-1628) Move shared state from AMQMessage to QueueEntry
Move shared state from AMQMessage to QueueEntry --- Key: QPID-1628 URL: https://issues.apache.org/jira/browse/QPID-1628 Project: Qpid Issue Type: Sub-task Reporter: Martin Ritchie Priority: Minor Summary: Currently items such as redelivered exist on the AMQMessage object but these are actually part of the QueueEntry. All such state should be moved to the QueueEntry. AMQMessage should be stateless and only contain the message Header and Bodies. -- 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
[jira] Created: (QPID-1630) Provide unified message creation mechanism
Provide unified message creation mechanism -- Key: QPID-1630 URL: https://issues.apache.org/jira/browse/QPID-1630 Project: Qpid Issue Type: Sub-task Reporter: Martin Ritchie -- 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
[jira] Updated: (QPID-1629) Merge *MessageHandles to AMQMessage
[ https://issues.apache.org/jira/browse/QPID-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Ritchie updated QPID-1629: - Component/s: Java Broker Description: The use of a WeakReference handle makes it more difficult for us to reason about the state of our messages. By merging these two handles with AMQMessage we will be better able to reason about message delivery and handle memory usage on the Queues. Affects Version/s: M4 Merge *MessageHandles to AMQMessage --- Key: QPID-1629 URL: https://issues.apache.org/jira/browse/QPID-1629 Project: Qpid Issue Type: Sub-task Components: Java Broker Affects Versions: M4 Reporter: Martin Ritchie The use of a WeakReference handle makes it more difficult for us to reason about the state of our messages. By merging these two handles with AMQMessage we will be better able to reason about message delivery and handle memory usage on the Queues. -- 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
[jira] Updated: (QPID-1630) Provide unified message creation mechanism (MessageFactory)
[ https://issues.apache.org/jira/browse/QPID-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Ritchie updated QPID-1630: - Affects Version/s: M4 Provide unified message creation mechanism (MessageFactory) --- Key: QPID-1630 URL: https://issues.apache.org/jira/browse/QPID-1630 Project: Qpid Issue Type: Sub-task Components: Java Broker Affects Versions: M4 Reporter: Martin Ritchie Currently, MessageHandleFactory is used to hand out the right handle type. WIth the removal of the MessageHandles this class will be redundant. However, a unified point for creating messages and so assigning message IDs would be beneficial. Currently the MessageStore is responsible for that task but a MessageFactory would localise that information and make it easier to see how a message is created. Currently IncomingMessage and the various MessageStores create the message in two different ways, understandable as one is recovery and one is normal delivery, however, using a MessageFactory would be a cleaner approach and localise the ID generation. -- 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
[jira] Created: (QPID-1633) Add new _queue*Memory, _flowed properties to SimpleAMQQueue
Add new _queue*Memory, _flowed properties to SimpleAMQQueue --- Key: QPID-1633 URL: https://issues.apache.org/jira/browse/QPID-1633 Project: Qpid Issue Type: Sub-task Reporter: Martin Ritchie -- 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
[jira] Created: (QPID-1632) Move reference counting from AMQMessage and Queue classes to TransactionLog
Move reference counting from AMQMessage and Queue classes to TransactionLog --- Key: QPID-1632 URL: https://issues.apache.org/jira/browse/QPID-1632 Project: Qpid Issue Type: Sub-task Reporter: Martin Ritchie -- 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
[jira] Created: (QPID-1631) Create TransactionLog and RoutingTable interfaces from MessageStore
Create TransactionLog and RoutingTable interfaces from MessageStore --- Key: QPID-1631 URL: https://issues.apache.org/jira/browse/QPID-1631 Project: Qpid Issue Type: Sub-task Reporter: Martin Ritchie -- 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
[jira] Updated: (QPID-1629) Merge *MessageHandles to AMQMessage
[ https://issues.apache.org/jira/browse/QPID-1629?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Ritchie updated QPID-1629: - Fix Version/s: M5 Remaining Estimate: 3h Original Estimate: 3h Merge *MessageHandles to AMQMessage --- Key: QPID-1629 URL: https://issues.apache.org/jira/browse/QPID-1629 Project: Qpid Issue Type: Sub-task Components: Java Broker Affects Versions: M4 Reporter: Martin Ritchie Fix For: M5 Original Estimate: 3h Remaining Estimate: 3h The use of a WeakReference handle makes it more difficult for us to reason about the state of our messages. By merging these two handles with AMQMessage we will be better able to reason about message delivery and handle memory usage on the Queues. -- 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
[jira] Updated: (QPID-1631) Create TransactionLog and RoutingTable interfaces from MessageStore
[ https://issues.apache.org/jira/browse/QPID-1631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Ritchie updated QPID-1631: - Component/s: Java Broker Fix Version/s: M5 Description: Replace existing MessageStore interface with TransactionLog and RoutingTable. There should be minimal change to the existing code as a result of this. Our existing *MessageStores can continue to operate as before but this gives us freedom to create new TransactionLogs and RoutingTable implementations. Some changes will be required in the broker startup as it currently requires the specified configuration class implements MessageStore. Backward compatibility will be key here. Existing configuration files should still be able to work as the underlying code has not changed only the interface names. Affects Version/s: M4 Remaining Estimate: 4h Original Estimate: 4h Create TransactionLog and RoutingTable interfaces from MessageStore --- Key: QPID-1631 URL: https://issues.apache.org/jira/browse/QPID-1631 Project: Qpid Issue Type: Sub-task Components: Java Broker Affects Versions: M4 Reporter: Martin Ritchie Fix For: M5 Original Estimate: 4h Remaining Estimate: 4h Replace existing MessageStore interface with TransactionLog and RoutingTable. There should be minimal change to the existing code as a result of this. Our existing *MessageStores can continue to operate as before but this gives us freedom to create new TransactionLogs and RoutingTable implementations. Some changes will be required in the broker startup as it currently requires the specified configuration class implements MessageStore. Backward compatibility will be key here. Existing configuration files should still be able to work as the underlying code has not changed only the interface names. -- 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: version number proposal
On Tue, Feb 3, 2009 at 1:34 AM, Rafael Schloming rafa...@redhat.com wrote: Aidan Skinner wrote: [...] I think we should adopt APR[1] style version numbers, they convey meaningful information and are widely understood. As a result of this, I think we should have different version numbers for the individual components. The C++ API, the Java API and the .Net [...] I'm of two minds on this. On the one hand I think your proposal probably most accurately reflects the reality of the current situation. On the other hand, I don't think the current situation is really a great place for us to be as a project. I think version numbers which reflect reality is probably a plus. I don't think it would be detrimental to the one team, one project, one qpid goal. There are definately issues there, but I don't think independently varying version numbers would add to those. In particular, one of the core goals of qpid is to provide a consistent cross-language messaging experience, and that includes equivalently stable and similar looking/feeling APIs across all the client languages we support. I'm not sure that similar looking/feeling APIs are really desierable. I'd rather see idiomatic APIs that feel comfortable and natural in the language than shoe-horning JMS into C++. The fact of the matter is that the various clients and brokers are at differing levels of robustness, internal stability and API stability and that's not something that I really see changing anytime soon. Unfortunately, to date we haven't been particularly good at cross language coordination, and so in some respects the project starts to feel like several completely independent sub-projects. This of course makes it tempting to treat Qpid as a distro/umbrella project as you propose, but I can't help but feel that doing that is giving up on an important goal. I don't think having seperate release numbers is giving up on that goal. There are some obvious disconnects in the team regarding attitudes towards things like backward API and ABI compatability, appropriate levels of change at particular points in the release cycle etc. that should be addressed, but it's a seperate issue IMHO. So for me, I'd either stick with the Mx version numbers, or use a pre 1.0 version numbering scheme until we've reached that goal of a consistent cross language messaging experience, and only from there move into post 1.0 territory. I could buy into s/M/0./ for everything (but not s/M/1./). I know some people are opposed to releasing 0.x versions for marketing reasons, but that essentially removes any useful information from the rev. - Aidan -- 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
[jira] Created: (QPID-1626) Pluggable authorization modules
Pluggable authorization modules --- Key: QPID-1626 URL: https://issues.apache.org/jira/browse/QPID-1626 Project: Qpid Issue Type: Improvement Components: Java Broker Reporter: Aidan Skinner Assignee: Aidan Skinner Fix For: M5 Authorization is almost, but not quite, pluggable atm. A sketch design is at http://qpid.apache.org/java-authorization-plugins.html and broadly involves implementing an AuthorizationManager which talks to a collection of plugins to authorize requests. -- 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: M5 - JIRAs/Scope
On Tue, Feb 3, 2009 at 9:54 AM, Marnie McCormack marnie.mccorm...@googlemail.com wrote: Anyone else working on something for M5 ? Be great if we could start getting a handle on what M5 will be. The only exciting thing I'm planning on doing is IP White/Black lists (QPID-1583). There are a few other bug fixes I'm planning on getting to for M5, QPID-1621, QPID-1623. - Aidan -- 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
Re: Interesting piece of work for C++
I think APR tries to do this. However, some people don't want to take all of APR is there no other project in Apache or indeed Boost that has this construct already? john 2009/2/2 Carl Trieloff cctriel...@redhat.com Some of the work being done has been around performance. At this point we have 2 locks that still need some work. One of these locks are in the OS memory allocator, to this end I have spoken to the glic/gcc maintainers and they are working on a better malloc/free for us. However the other side of the equation is to do some optional memory caching. The biggest area where this will help us is around frame caching. An experiment in this area has been done with TLS caching (did not work out as the caches need to be cross thread) and a global pool test has determined that we can reduce the number of allocations by 25% with such a cache. However to do this we need a lock free bucket. So, if someone has interest to create a lock free bucket. I.e. a lock free structure that you can push pointers into and pop them back off from many threads at the same time. If the bucket is empty return NULL. No ordering is required. What is interesting in that all the cost in a lock free fifo is the corrections to maintain order which we don't need. so the CAS or DCAS impls of fifo without order can be used. For algorithms see work from Maged M. Michael Michael L. Scott -- or google a bit The bucket needs to be able to do at least 2 million insertions and 2M removals per second without breaking a sweat. anyone interested? - nice isolated task, and fun. thought I would toss it out before I started working on it. Carl. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
Re: Generating more useful Python API docs
i can create a lot better Python docs by enumerating the starting points we care about. This incantation seems to work for me: $ epydoc -v -u http://qpid.apache.org -n Apache Qpid: Open Source AMQP Enterprise Messaging qpid.session qpid.connection qpid.datatypes qpid.exceptions qmf.console I'll try to find an appropriate place on the Wiki to enshrine that knowledge. Jonathan - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
