Re: Review Request: Develop Asynchronous Store Interface for Qpid (v.2)

On 02/28/2012 09:47 PM, Andrew Stitcher wrote: On Tue, 2012-02-28 at 21:16 +, Gordon Sim wrote: Why do we need AsyncResult objects as distinct from a callback context and the status of the operation? That goes with using a single callback for the result - there needs to be a single base cl

[jira] [Commented] (QPID-3799) ACL processing by C++ broker produces unexpected results

[ https://issues.apache.org/jira/browse/QPID-3799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13218947#comment-13218947 ] jirapos...@reviews.apache.org commented on QPID-3799: - ---

Re: Review Request: QPID-3799 C++ Broker ACL additions and cleanup

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/4063/#review5447 --- Ship it! - Gordon On 2012-02-27 22:26:16, Chug Rolke wrote: > > --

[jira] [Assigned] (QPID-3605) Durable subscriber with no-local true receives messages on re-connection

[ https://issues.apache.org/jira/browse/QPID-3605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey reassigned QPID-3605: - Assignee: Robbie Gemmell (was: Rob Godfrey) Robbie - could you review - thx > Du

[jira] [Updated] (QPID-3605) Durable subscriber with no-local true receives messages on re-connection

[ https://issues.apache.org/jira/browse/QPID-3605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-3605: -- Status: Ready To Review (was: In Progress) > Durable subscriber with no-local true receives message

[jira] [Commented] (QPID-3605) Durable subscriber with no-local true receives messages on re-connection

[ https://issues.apache.org/jira/browse/QPID-3605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13218681#comment-13218681 ] Rob Godfrey commented on QPID-3605: --- I've updated the client/broker so that the binding b

[jira] [Assigned] (QPID-3605) Durable subscriber with no-local true receives messages on re-connection

[ https://issues.apache.org/jira/browse/QPID-3605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey reassigned QPID-3605: - Assignee: Rob Godfrey > Durable subscriber with no-local true receives messages on re-connecti

Re: Review Request: Develop Asynchronous Store Interface for Qpid (v.2)

On Tue, 2012-02-28 at 21:16 +, Gordon Sim wrote: > On 02/28/2012 08:45 PM, Andrew Stitcher wrote: > > On Tue, 2012-02-28 at 20:24 +, Gordon Sim wrote: > >> What I do think is important is that the broker can easily get specific > >> context passed back in some way. I don't see how your desi

Re: Review Request: Develop Asynchronous Store Interface for Qpid (v.2)

On 02/28/2012 08:45 PM, Andrew Stitcher wrote: On Tue, 2012-02-28 at 20:24 +, Gordon Sim wrote: What I do think is important is that the broker can easily get specific context passed back in some way. I don't see how your design would allow this but as you note below that may simply be becau

Re: Review Request: Develop Asynchronous Store Interface for Qpid (v.2)

On Tue, 2012-02-28 at 20:24 +, Gordon Sim wrote: > ... > > Another simplification is that it uses a single result callback for each > > operation - success and failure being distinguished by the type of the > > result, and left up to the broker to arrange (probably by having a > > virtual metho

Re: Review Request: Develop Asynchronous Store Interface for Qpid (v.2)

On 02/28/2012 07:48 PM, Andrew Stitcher wrote: What I mostly want to illustrate here is that very few of the actual types used needs to be visible in the interface. Yes, that is indeed a good point. Having different handle types for clarity without needing to define any inheritance between the

Re: Review Request: Develop Asynchronous Store Interface for Qpid (v.2)

On 02/28/2012 07:30 PM, Andrew Stitcher wrote: On Tue, 2012-02-28 at 19:08 +, Gordon Sim wrote: On 02/28/2012 06:00 PM, Andrew Stitcher wrote: I have attached a simplification of this proposal which I believe encapsulates most of the ways it improves on the original design Could you elabo

Re: Review Request: Develop Asynchronous Store Interface for Qpid (v.2)

I attach a slightly more elaborated sketch of the interface. What I mostly want to illustrate here is that very few of the actual types used needs to be visible in the interface. Don't take the use of pointers too literally - they might well be references in an actual design. Andrew #include #

Re: Review Request: Develop Asynchronous Store Interface for Qpid (v.2)

On Tue, 2012-02-28 at 19:08 +, Gordon Sim wrote: > On 02/28/2012 06:00 PM, Andrew Stitcher wrote: > > I have attached a simplification of this proposal which I believe > > encapsulates most of the ways it improves on the original design > > Could you elaborate on those improvements? Functiona

Re: Review Request: Develop Asynchronous Store Interface for Qpid (v.2)

On 02/28/2012 06:00 PM, Andrew Stitcher wrote: I have attached a simplification of this proposal which I believe encapsulates most of the ways it improves on the original design Could you elaborate on those improvements? - Apa

RE: Interest in Coverity scan?

Thanks to everyone for the quick +1s... I've sent off a request to Coverity to find out what to do next. > -Original Message- > From: Ken Giusti [mailto:kgiu...@redhat.com] > Sent: Tuesday, February 28, 2012 1:12 PM > To: dev@qpid.apache.org > Subject: Re: Interest in Coverity scan? > > +

Re: Review Request: Develop Asynchronous Store Interface for Qpid (v.2)

> On 2012-02-28 17:27:10, Andrew Stitcher wrote: > > branches/asyncstore/cpp/src/qpid/broker/AsyncInterface.h, line 14 > > > > > > This is a strange looking sequence diagram, probably better to use a > > more standard typ

Re: Interest in Coverity scan?

+1 - I'd certainly be willing to help review the C++ results. -K - Original Message - > Coverity makes a very nice set of code analysis tools, one of which > is > static analysis. They offer a service whereby they'll scan open > source > projects free and we can access the results online

Re: Review Request: Develop Asynchronous Store Interface for Qpid (v.2)

I have attached a simplification of this proposal which I believe encapsulates most of the ways it improves on the original design, but still leaves a pretty simple interface. [I couldn't think of a sensible way to put this into the reviewboard stream sorry] This is still pretty rough so don't ta

Re: Address validation Queues vs Topics

Based on the discussion I would like to outline the following proposal. I believe it reflects the consensus so far. Please correct me if anything is amiss. 1. If the user wants to use the specialized interfaces (JMS 1.0) and pass in either a Queue or a Topic, then they should be using "queue" or "

Re: Review Request: Develop Asynchronous Store Interface for Qpid (v.2)

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/4085/#review5395 --- branches/asyncstore/cpp/src/qpid/broker/AsyncInterface.h

Re: Review Request: Develop Asynchronous Store Interface for Qpid (v.2)

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/4085/#review5397 --- I don't like this. I much preferred your first interface. This seems c

Re: Review Request: Develop Asynchronous Store Interface for Qpid (v.2)

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/4085/#review5396 --- branches/asyncstore/cpp/src/qpid/broker/AsyncInterface.h

[jira] [Commented] (QPID-3858) Develop asyncronous store interface for qpid

[ https://issues.apache.org/jira/browse/QPID-3858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13218332#comment-13218332 ] Kim van der Riet commented on QPID-3858: Second proposal for interface is at https:

Review Request: Develop Asynchronous Store Interface for Qpid (v.2)

--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/4085/ --- Review request for qpid, Andrew Stitcher, Alan Conway, Gordon Sim, Kenneth Giusti

[jira] [Commented] (QPID-3832) Qpid 0.14 broke transport connection setting

[ https://issues.apache.org/jira/browse/QPID-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13218291#comment-13218291 ] jirapos...@reviews.apache.org commented on QPID-3832: - ---

RE: Interest in Coverity scan?

Thanks for the previous results, Chuck - I didn't realize this was there. I don't have hardware to test if I touch RDMA or cluster, so I'm not gonna go near those patches :-) but some who maybe worked at Red Hat might have access to those ;-) -Steve > -Original Message- > From: Chuck

Re: Interest in Coverity scan?

On 02/28/2012 10:06 AM, Steve Huston wrote: Coverity makes a very nice set of code analysis tools, one of which is static analysis. They offer a service whereby they'll scan open source projects free and we can access the results online (http://scan.coverity.com/developers-faq.html). I don't see

[jira] [Commented] (QPID-3832) Qpid 0.14 broke transport connection setting

[ https://issues.apache.org/jira/browse/QPID-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13218276#comment-13218276 ] jirapos...@reviews.apache.org commented on QPID-3832: - bq. On 2012-0

Re: Interest in Coverity scan?

Steve, +1 Sounds great. I see no harm in having Qpid getting a scan. I ran some Coverity some time ago (https://issues.apache.org/jira/browse/QPID-2645) and to be honest Qpid is the cleanest project I've ever scanned. That said, I don't think the patches I posted ever got applied. -Chuck --

Re: Interest in Coverity scan?

Sounds interesting to me (from the Java side), and I would definitely be interested in looking at the results Cheers, Rob On 28 February 2012 16:06, Steve Huston wrote: > Coverity makes a very nice set of code analysis tools, one of which is > static analysis. They offer a service whereby they'l

Interest in Coverity scan?

Coverity makes a very nice set of code analysis tools, one of which is static analysis. They offer a service whereby they'll scan open source projects free and we can access the results online (http://scan.coverity.com/developers-faq.html). I don't see Qpid listed and would like to know if this is

[jira] [Commented] (QPID-3832) Qpid 0.14 broke transport connection setting

[ https://issues.apache.org/jira/browse/QPID-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13218251#comment-13218251 ] jirapos...@reviews.apache.org commented on QPID-3832: - ---

Re: Address validation Queues vs Topics

Rob, Addressing is indeed a pain point and most of it is due to grey areas causing undesirable side effects. I've got some work that I'm hoping to post today. Let me first check that into a branch and then I will post a brief outline of the design and the code in review board. I'm hoping to wrap

[jira] [Commented] (QPID-3832) Qpid 0.14 broke transport connection setting

[ https://issues.apache.org/jira/browse/QPID-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13218242#comment-13218242 ] jirapos...@reviews.apache.org commented on QPID-3832: - bq. On 2012-0

Re: Address validation Queues vs Topics

On Tue, Feb 28, 2012 at 3:19 AM, Rob Godfrey wrote: > On 28 February 2012 05:37, Rajith Attapattu wrote: >> If the "queue" and "topic" qualifiers are used then I guess it makes >> it really easy for us to work out the validation. >> >> What are we going to do with the "destination" qualifier ? >>

[jira] [Commented] (QPID-3832) Qpid 0.14 broke transport connection setting

[ https://issues.apache.org/jira/browse/QPID-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13218215#comment-13218215 ] jirapos...@reviews.apache.org commented on QPID-3832: - ---

[jira] [Commented] (QPID-3832) Qpid 0.14 broke transport connection setting

[ https://issues.apache.org/jira/browse/QPID-3832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13218170#comment-13218170 ] jirapos...@reviews.apache.org commented on QPID-3832: - ---

Re: Address validation Queues vs Topics

On 02/28/2012 04:30 AM, Rajith Attapattu wrote: As per the discussion on QPID-792, I'm moving the discussion onto the dev list under. I have attempted to summarise the current behaviour and some of the comments expressed by Rob and Robbie. Currently the clients (C++, python and JMS) resolves an

Re: Address validation Queues vs Topics

As an aside, I have been labeling the open Java Client JIRAs so its easier to pick out clusters of JIRAs that can be worked on together / see where the real pain points are. A quick report on open JIRAs per label: 17 - addressing 9 - failover 9 - exception-handling 4 - deadlock 3 - timestamp

[jira] [Updated] (QPID-3576) Test AddressBasedDestinationTest#testDeleteOptions fails against CPP broker occasionally

[ https://issues.apache.org/jira/browse/QPID-3576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-3576: -- Component/s: (was: Java Client) Java Tests C++ Broker > Test A

[jira] [Updated] (QPID-3431) SessionCreateTest gets progressively slower under cpp.ssl profile

[ https://issues.apache.org/jira/browse/QPID-3431?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-3431: -- Component/s: (was: Java Client) > SessionCreateTest gets progressively slower under cpp.ssl prof

Re: Address validation Queues vs Topics

On 28 February 2012 05:37, Rajith Attapattu wrote: > If the "queue" and "topic" qualifiers are used then I guess it makes > it really easy for us to work out the validation. > > What are we going to do with the "destination" qualifier ? > Ex destination.my-dest= > > 1. We deprecate this and get qp