[jira] [Updated] (QPID-3387) QueueEntries can hold the Subscriptions which rejected them in memory after they are closed

2011-08-08 Thread Robbie Gemmell (JIRA) 

 [ 
https://issues.apache.org/jira/browse/QPID-3387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated QPID-3387:
-

Status: Ready To Review  (was: In Progress)

> 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] [Assigned] (QPID-3387) QueueEntries can hold the Subscriptions which rejected them in memory after they are closed

2011-08-08 Thread Robbie Gemmell (JIRA) 

 [ 
https://issues.apache.org/jira/browse/QPID-3387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell reassigned QPID-3387:


Assignee: Keith Wall  (was: Robbie Gemmell)

Hi Keith, could you review these changes please? Thanks, Robbie.

> 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: Keith Wall
> 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] [Updated] (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

2011-08-08 Thread Robbie Gemmell (JIRA) 

 [ 
https://issues.apache.org/jira/browse/QPID-3386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated QPID-3386:
-

Status: Ready To Review  (was: In Progress)

> 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.6, 0.7, 0.8, 0.9, 0.10, 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] [Assigned] (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

2011-08-08 Thread Robbie Gemmell (JIRA) 

 [ 
https://issues.apache.org/jira/browse/QPID-3386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell reassigned QPID-3386:


Assignee: Keith Wall  (was: Robbie Gemmell)

Hi Keith, could you review these changes please? Thanks, Robbie.

> 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.6, 0.7, 0.8, 0.9, 0.10, 0.11, 0.12
>Reporter: Robbie Gemmell
>Assignee: Keith Wall
> 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] [Assigned] (QPID-3385) 0-8/0-9/0-9-1 based connections share an ID generator, but 0-10 connection use their own

2011-08-08 Thread Robbie Gemmell (JIRA) 

 [ 
https://issues.apache.org/jira/browse/QPID-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell reassigned QPID-3385:


Assignee: Keith Wall  (was: Robbie Gemmell)

Hi Keith, could you review these changes please? Thanks, Robbie.

> 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.6, 0.7, 0.8, 0.9, 0.10, 0.11, 0.12
>Reporter: Robbie Gemmell
>Assignee: Keith Wall
> 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] [Updated] (QPID-3385) 0-8/0-9/0-9-1 based connections share an ID generator, but 0-10 connection use their own

2011-08-08 Thread Robbie Gemmell (JIRA) 

 [ 
https://issues.apache.org/jira/browse/QPID-3385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Robbie Gemmell updated QPID-3385:
-

Status: Ready To Review  (was: In Progress)

> 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.6, 0.7, 0.8, 0.9, 0.10, 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] [Updated] (QPID-3346) Support message grouping with stricted sequence consumption across multiple consumers.

2011-08-08 Thread Ken Giusti (JIRA) 

 [ 
https://issues.apache.org/jira/browse/QPID-3346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ken Giusti updated QPID-3346:
-

Attachment: UI.txt

Proposed User Interface for this new feature.

> Support message grouping with stricted sequence consumption across multiple 
> consumers.
> --
>
> Key: QPID-3346
> URL: https://issues.apache.org/jira/browse/QPID-3346
> Project: Qpid
>  Issue Type: New Feature
>  Components: C++ Broker
>Affects Versions: 0.12
>Reporter: Ken Giusti
>Assignee: Ken Giusti
> Fix For: 0.14
>
> Attachments: UI.txt, msg_groups_0.2.txt
>
>
> This feature is described in the attached QIP as Policy #2: Sequenced 
> Consumers.

--
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-2899) SelectorTest#testRuntimeSelectorError fails against the Java broker when running the 0-10 profiles

2011-08-08 Thread Keith Wall (JIRA) 

 [ 
https://issues.apache.org/jira/browse/QPID-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall resolved QPID-2899.
--

Resolution: Fixed

Re-reviewed, no further comments.

> 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] [Resolved] (QPID-3319) org.apache.qpid.server.subscription.SubscriptionList leaks memory

2011-08-08 Thread Keith Wall (JIRA) 

 [ 
https://issues.apache.org/jira/browse/QPID-3319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall resolved QPID-3319.
--

Resolution: Fixed

Reviewed as part of QPID-3157 on 2011/08/02, no comments.

> 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] [Resolved] (QPID-3390) the Java broker does not validate the exchange-declare arguments are supported

2011-08-08 Thread Keith Wall (JIRA) 

 [ 
https://issues.apache.org/jira/browse/QPID-3390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Wall resolved QPID-3390.
--

Resolution: Fixed

Hi Robbie,

I've reviewed the change and I have no comments.

cheers Keith.

> 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

[jira] [Commented] (QPID-3375) qpid-route does not resolve hostname and this causes problems with localhost among others

2011-08-08 Thread William Henry (JIRA) 

[ 
https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081215#comment-13081215
 ] 

William Henry commented on QPID-3375:
-

Made some changes. Let me know what you think.

Allow localhost when both machines are localhost (but diff brokers)
I warn of a gai_error if it can't resolve locally but don't throw an exception. 
The gai_error gets caught elsewhere. (I think it is only thrown if the remote 
machine can't resolve either)

> qpid-route does not resolve hostname and this causes problems with localhost 
> among others
> -
>
> Key: QPID-3375
> URL: https://issues.apache.org/jira/browse/QPID-3375
> Project: Qpid
>  Issue Type: Bug
>  Components: python tools
>Affects Versions: 0.10
> Environment: All
>Reporter: William Henry
>Assignee: Gordon Sim
>  Labels: qpid-route
> Attachments: qpid-route, qpid-route.diff
>
>
> All the examples for Federation and qpid-route use localhost. For a multihost 
> environment this is not a good idea.
> 1. 'localhost': can end up in the routing table of remote host 
> erroneously.
> 2. Resolving localhost doesn't help as you'd end up with 127.0.0.1 in the 
> route erroneously
> 3. Even non localhost names don't get resolved and checked.
> Here is the test I was performing. 
> I was doing some playing/testing with federation and I used two machines: my
> laptop (sligo) and a remote machine (buzz).  I ran three brokers: 2 on sligo 
> on
> ports 5672 and 5682 and one on remote on port 5682.
> From sligo I set up some links between all the brokers.
> (The problem has already occurred on the links above. Listing the routes will 
> show the problem. But we'll go on)
> From sligo I set up a topic exchange on each broker:
> $ qpid-config -a localhost:5672 add exchange topic T.Prod
> $ qpid-config -a localhost:5682 add exchange topic T.Prod
> $ qpid-config -a buzz.somedomain.com:5682 add exchange topic T.Prod
> On sligo I set up dynamic routes from source localhost:5672 to localhost:5682
> and buzz.somedomain.com:5682.
> When I list the routes from sligo I see:
> $ qpid-route route list localhost:5682
> localhost:5682 localhost:5672 T.Prod 
> $ qpid-route route list buzz.somedomain.com:5682
> buzz.somedomain.com:5682 localhost:5672 T.Prod 
> When I run example program drain on localhost:5682 on sligo I get the 
> messages sent using the spout example program to default broker on sligo (on 
> 5672).
> When I run drain on buzz I don't see anything.
> I see references to "localhost:5672" in the trace output of buzz's broker.  
> This is BAD!
> We need qpid-route to resolve hostname before passing the arg to the remote
> broker.
> (In the meantime we might want to warn users of using 'localhost' with
> qpid-route across different hosts.)
> I will attach a diff and a new version of qpid-route for review.

--
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-3375) qpid-route does not resolve hostname and this causes problems with localhost among others

2011-08-08 Thread William Henry (JIRA) 

[ 
https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081217#comment-13081217
 ] 

William Henry edited comment on QPID-3375 at 8/8/11 9:36 PM:
-

Added svn diff output

  was (Author: whenry):
svn diff output
  
> qpid-route does not resolve hostname and this causes problems with localhost 
> among others
> -
>
> Key: QPID-3375
> URL: https://issues.apache.org/jira/browse/QPID-3375
> Project: Qpid
>  Issue Type: Bug
>  Components: python tools
>Affects Versions: 0.10
> Environment: All
>Reporter: William Henry
>Assignee: Gordon Sim
>  Labels: qpid-route
> Attachments: qpid-route, qpid-route, qpid-route-diff.txt, 
> qpid-route.diff
>
>
> All the examples for Federation and qpid-route use localhost. For a multihost 
> environment this is not a good idea.
> 1. 'localhost': can end up in the routing table of remote host 
> erroneously.
> 2. Resolving localhost doesn't help as you'd end up with 127.0.0.1 in the 
> route erroneously
> 3. Even non localhost names don't get resolved and checked.
> Here is the test I was performing. 
> I was doing some playing/testing with federation and I used two machines: my
> laptop (sligo) and a remote machine (buzz).  I ran three brokers: 2 on sligo 
> on
> ports 5672 and 5682 and one on remote on port 5682.
> From sligo I set up some links between all the brokers.
> (The problem has already occurred on the links above. Listing the routes will 
> show the problem. But we'll go on)
> From sligo I set up a topic exchange on each broker:
> $ qpid-config -a localhost:5672 add exchange topic T.Prod
> $ qpid-config -a localhost:5682 add exchange topic T.Prod
> $ qpid-config -a buzz.somedomain.com:5682 add exchange topic T.Prod
> On sligo I set up dynamic routes from source localhost:5672 to localhost:5682
> and buzz.somedomain.com:5682.
> When I list the routes from sligo I see:
> $ qpid-route route list localhost:5682
> localhost:5682 localhost:5672 T.Prod 
> $ qpid-route route list buzz.somedomain.com:5682
> buzz.somedomain.com:5682 localhost:5672 T.Prod 
> When I run example program drain on localhost:5682 on sligo I get the 
> messages sent using the spout example program to default broker on sligo (on 
> 5672).
> When I run drain on buzz I don't see anything.
> I see references to "localhost:5672" in the trace output of buzz's broker.  
> This is BAD!
> We need qpid-route to resolve hostname before passing the arg to the remote
> broker.
> (In the meantime we might want to warn users of using 'localhost' with
> qpid-route across different hosts.)
> I will attach a diff and a new version of qpid-route for review.

--
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-3375) qpid-route does not resolve hostname and this causes problems with localhost among others

2011-08-08 Thread William Henry (JIRA) 

 [ 
https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

William Henry updated QPID-3375:


Attachment: qpid-route-diff.txt

svn diff output

> qpid-route does not resolve hostname and this causes problems with localhost 
> among others
> -
>
> Key: QPID-3375
> URL: https://issues.apache.org/jira/browse/QPID-3375
> Project: Qpid
>  Issue Type: Bug
>  Components: python tools
>Affects Versions: 0.10
> Environment: All
>Reporter: William Henry
>Assignee: Gordon Sim
>  Labels: qpid-route
> Attachments: qpid-route, qpid-route, qpid-route-diff.txt, 
> qpid-route.diff
>
>
> All the examples for Federation and qpid-route use localhost. For a multihost 
> environment this is not a good idea.
> 1. 'localhost': can end up in the routing table of remote host 
> erroneously.
> 2. Resolving localhost doesn't help as you'd end up with 127.0.0.1 in the 
> route erroneously
> 3. Even non localhost names don't get resolved and checked.
> Here is the test I was performing. 
> I was doing some playing/testing with federation and I used two machines: my
> laptop (sligo) and a remote machine (buzz).  I ran three brokers: 2 on sligo 
> on
> ports 5672 and 5682 and one on remote on port 5682.
> From sligo I set up some links between all the brokers.
> (The problem has already occurred on the links above. Listing the routes will 
> show the problem. But we'll go on)
> From sligo I set up a topic exchange on each broker:
> $ qpid-config -a localhost:5672 add exchange topic T.Prod
> $ qpid-config -a localhost:5682 add exchange topic T.Prod
> $ qpid-config -a buzz.somedomain.com:5682 add exchange topic T.Prod
> On sligo I set up dynamic routes from source localhost:5672 to localhost:5682
> and buzz.somedomain.com:5682.
> When I list the routes from sligo I see:
> $ qpid-route route list localhost:5682
> localhost:5682 localhost:5672 T.Prod 
> $ qpid-route route list buzz.somedomain.com:5682
> buzz.somedomain.com:5682 localhost:5672 T.Prod 
> When I run example program drain on localhost:5682 on sligo I get the 
> messages sent using the spout example program to default broker on sligo (on 
> 5672).
> When I run drain on buzz I don't see anything.
> I see references to "localhost:5672" in the trace output of buzz's broker.  
> This is BAD!
> We need qpid-route to resolve hostname before passing the arg to the remote
> broker.
> (In the meantime we might want to warn users of using 'localhost' with
> qpid-route across different hosts.)
> I will attach a diff and a new version of qpid-route for review.

--
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-3375) qpid-route does not resolve hostname and this causes problems with localhost among others

2011-08-08 Thread William Henry (JIRA) 

 [ 
https://issues.apache.org/jira/browse/QPID-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

William Henry updated QPID-3375:


Attachment: qpid-route

Added the new qpid-route

> qpid-route does not resolve hostname and this causes problems with localhost 
> among others
> -
>
> Key: QPID-3375
> URL: https://issues.apache.org/jira/browse/QPID-3375
> Project: Qpid
>  Issue Type: Bug
>  Components: python tools
>Affects Versions: 0.10
> Environment: All
>Reporter: William Henry
>Assignee: Gordon Sim
>  Labels: qpid-route
> Attachments: qpid-route, qpid-route, qpid-route-diff.txt, 
> qpid-route.diff
>
>
> All the examples for Federation and qpid-route use localhost. For a multihost 
> environment this is not a good idea.
> 1. 'localhost': can end up in the routing table of remote host 
> erroneously.
> 2. Resolving localhost doesn't help as you'd end up with 127.0.0.1 in the 
> route erroneously
> 3. Even non localhost names don't get resolved and checked.
> Here is the test I was performing. 
> I was doing some playing/testing with federation and I used two machines: my
> laptop (sligo) and a remote machine (buzz).  I ran three brokers: 2 on sligo 
> on
> ports 5672 and 5682 and one on remote on port 5682.
> From sligo I set up some links between all the brokers.
> (The problem has already occurred on the links above. Listing the routes will 
> show the problem. But we'll go on)
> From sligo I set up a topic exchange on each broker:
> $ qpid-config -a localhost:5672 add exchange topic T.Prod
> $ qpid-config -a localhost:5682 add exchange topic T.Prod
> $ qpid-config -a buzz.somedomain.com:5682 add exchange topic T.Prod
> On sligo I set up dynamic routes from source localhost:5672 to localhost:5682
> and buzz.somedomain.com:5682.
> When I list the routes from sligo I see:
> $ qpid-route route list localhost:5682
> localhost:5682 localhost:5672 T.Prod 
> $ qpid-route route list buzz.somedomain.com:5682
> buzz.somedomain.com:5682 localhost:5672 T.Prod 
> When I run example program drain on localhost:5682 on sligo I get the 
> messages sent using the spout example program to default broker on sligo (on 
> 5672).
> When I run drain on buzz I don't see anything.
> I see references to "localhost:5672" in the trace output of buzz's broker.  
> This is BAD!
> We need qpid-route to resolve hostname before passing the arg to the remote
> broker.
> (In the meantime we might want to warn users of using 'localhost' with
> qpid-route across different hosts.)
> I will attach a diff and a new version of qpid-route for review.

--
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-3346) Support message grouping with stricted sequence consumption across multiple consumers.

2011-08-08 Thread jirapos...@reviews.apache.org (JIRA) 

[ 
https://issues.apache.org/jira/browse/QPID-3346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081204#comment-13081204
 ] 

jirapos...@reviews.apache.org commented on QPID-3346:
-



bq.  On 2011-08-08 10:11:17, Gordon Sim wrote:
bq.  > /branches/qpid-3346/qpid/cpp/src/qpid/broker/Queue.h, line 132
bq.  > 
bq.  >
bq.  > I'm not keen on the terminology here. For me selector implies 
something subtly different from the role this object is serving (at least from 
the role I *think* it is serving).
bq.  > 
bq.  > I'd prefer something like 'allocator'.

Me too - renamed to allocator.


bq.  On 2011-08-08 10:11:17, Gordon Sim wrote:
bq.  > /branches/qpid-3346/qpid/cpp/src/qpid/broker/Queue.h, line 148
bq.  > 
bq.  >
bq.  > Again, I'm not too keen on the term 'consumed' in this context. 
Though I can see how it is justified, it is potentially confusing in my view 
(could imply the actual dequeue of a message).
bq.  > 
bq.  > I'd prefer 'acquired', 'allocated' or even just 'locked' as they are 
all less ambiguous on the state in question.

Agreed - renamed to acquired.


bq.  On 2011-08-08 10:11:17, Gordon Sim wrote:
bq.  > /branches/qpid-3346/qpid/cpp/src/qpid/broker/DeliveryRecord.cpp, line 158
bq.  > 
bq.  >
bq.  > Not too keen on this lookup. Can it be avoided?
bq.  > 
bq.  > E.g. can we modify the Queue::acquire() to simply take the consumer 
name as the second parameter? (That is for the present at least all that is 
required)
bq.  > 
bq.  > Alternatively the DeliveryRecord could be modified to hold a pointer 
to the Consumer rather than simply the tag.

Modified Queue::acquire() to take the name instead - should be ok.   I 
originally had added a pointer to the Consumer into the DeliveryRecord, but 
that raised issues with cluster replication (Consumer not present when 
replicating DeliveryRecord).  May have to revisit this if it turns out we need 
the pointer.


bq.  On 2011-08-08 10:11:17, Gordon Sim wrote:
bq.  > /branches/qpid-3346/qpid/cpp/src/qpid/broker/LegacyLVQ.cpp, line 39
bq.  > 
bq.  >
bq.  > The purpose of the check is to ensure that an acquire attempt for a 
message that has since been replaced, does not acquire the message that has 
replaced it instead.
bq.  > 
bq.  > I believe it is still necessary, though I concede the form is ugly 
and unintuitive.

Agreed that it is necessary for LVQ, but the abstract api for 
'Messages::remove' can't explicitly enforce that the caller supply the actual 
target msg, just the position.  Given that, it's pretty easy for the caller to 
get this wrong without discovering it (which actually happened to me - thank 
goodness for unit tests :).

And the "move message/purge message" management operations probably could use a 
remove method that doesn't necessitate a preceding message find().  

I'm thinking of two different message-removal use-cases:

bool Messages::remove( position, QueuedMessage *result) - remove msg at 
position, return true and set result if found
bool Messages::remove( const QueuedMessage& target ) - remove target msg, 
return true if msg was found.   This variant could be used by 'acquire' or 
other paths that have already retrieved the QueuedMessage.

Although, defining a iterator for the Messages class probably renders this 
whole issue moot.


- Kenneth


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1312/#review1317
---


On 2011-08-05 20:46:15, Kenneth Giusti wrote:
bq.  
bq.  ---
bq.  This is an automatically generated e-mail. To reply, visit:
bq.  https://reviews.apache.org/r/1312/
bq.  ---
bq.  
bq.  (Updated 2011-08-05 20:46:15)
bq.  
bq.  
bq.  Review request for qpid.
bq.  
bq.  
bq.  Summary
bq.  ---
bq.  
bq.  Some initial refactoring of Queue/Consumer interface to allow for message 
grouping support.  Very preliminary.
bq.  
bq.  
bq.  This addresses bug qpid-3346.
bq.  https://issues.apache.org/jira/browse/qpid-3346
bq.  
bq.  
bq.  Diffs
bq.  -
bq.  
bq./branches/qpid-3346/qpid/cpp/src/qpid/broker/Consumer.h 1144324 
bq./branches/qpid-3346/qpid/cpp/src/qpid/broker/DeliveryRecord.h 1144324 
bq./branches/qpid-3346/qpid/cpp/src/qpid/broker/DeliveryRecord.cpp 1144324 
bq./branches/qpid-3346/qpid/cpp/src/qpid/broker/LegacyLVQ.cpp 1144324 
bq./branches/qpid-3346/qpid/cpp/src/qpid/broker/Queue.h 1144324

Re: Review Request: Prototype of infrastructure changes needed to support message groups [PRELIMINARY]

2011-08-08 Thread Kenneth Giusti 


> On 2011-08-08 10:11:17, Gordon Sim wrote:
> > /branches/qpid-3346/qpid/cpp/src/qpid/broker/Queue.h, line 132
> > 
> >
> > I'm not keen on the terminology here. For me selector implies something 
> > subtly different from the role this object is serving (at least from the 
> > role I *think* it is serving).
> > 
> > I'd prefer something like 'allocator'.

Me too - renamed to allocator.


> On 2011-08-08 10:11:17, Gordon Sim wrote:
> > /branches/qpid-3346/qpid/cpp/src/qpid/broker/Queue.h, line 148
> > 
> >
> > Again, I'm not too keen on the term 'consumed' in this context. Though 
> > I can see how it is justified, it is potentially confusing in my view 
> > (could imply the actual dequeue of a message).
> > 
> > I'd prefer 'acquired', 'allocated' or even just 'locked' as they are 
> > all less ambiguous on the state in question.

Agreed - renamed to acquired.


> On 2011-08-08 10:11:17, Gordon Sim wrote:
> > /branches/qpid-3346/qpid/cpp/src/qpid/broker/DeliveryRecord.cpp, line 158
> > 
> >
> > Not too keen on this lookup. Can it be avoided?
> > 
> > E.g. can we modify the Queue::acquire() to simply take the consumer 
> > name as the second parameter? (That is for the present at least all that is 
> > required)
> > 
> > Alternatively the DeliveryRecord could be modified to hold a pointer to 
> > the Consumer rather than simply the tag.

Modified Queue::acquire() to take the name instead - should be ok.   I 
originally had added a pointer to the Consumer into the DeliveryRecord, but 
that raised issues with cluster replication (Consumer not present when 
replicating DeliveryRecord).  May have to revisit this if it turns out we need 
the pointer.


> On 2011-08-08 10:11:17, Gordon Sim wrote:
> > /branches/qpid-3346/qpid/cpp/src/qpid/broker/LegacyLVQ.cpp, line 39
> > 
> >
> > The purpose of the check is to ensure that an acquire attempt for a 
> > message that has since been replaced, does not acquire the message that has 
> > replaced it instead.
> > 
> > I believe it is still necessary, though I concede the form is ugly and 
> > unintuitive.

Agreed that it is necessary for LVQ, but the abstract api for 
'Messages::remove' can't explicitly enforce that the caller supply the actual 
target msg, just the position.  Given that, it's pretty easy for the caller to 
get this wrong without discovering it (which actually happened to me - thank 
goodness for unit tests :).

And the "move message/purge message" management operations probably could use a 
remove method that doesn't necessitate a preceding message find().  

I'm thinking of two different message-removal use-cases:

bool Messages::remove( position, QueuedMessage *result) - remove msg at 
position, return true and set result if found
bool Messages::remove( const QueuedMessage& target ) - remove target msg, 
return true if msg was found.   This variant could be used by 'acquire' or 
other paths that have already retrieved the QueuedMessage.

Although, defining a iterator for the Messages class probably renders this 
whole issue moot.


- Kenneth


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1312/#review1317
---


On 2011-08-05 20:46:15, Kenneth Giusti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/1312/
> ---
> 
> (Updated 2011-08-05 20:46:15)
> 
> 
> Review request for qpid.
> 
> 
> Summary
> ---
> 
> Some initial refactoring of Queue/Consumer interface to allow for message 
> grouping support.  Very preliminary.
> 
> 
> This addresses bug qpid-3346.
> https://issues.apache.org/jira/browse/qpid-3346
> 
> 
> Diffs
> -
> 
>   /branches/qpid-3346/qpid/cpp/src/qpid/broker/Consumer.h 1144324 
>   /branches/qpid-3346/qpid/cpp/src/qpid/broker/DeliveryRecord.h 1144324 
>   /branches/qpid-3346/qpid/cpp/src/qpid/broker/DeliveryRecord.cpp 1144324 
>   /branches/qpid-3346/qpid/cpp/src/qpid/broker/LegacyLVQ.cpp 1144324 
>   /branches/qpid-3346/qpid/cpp/src/qpid/broker/Queue.h 1144324 
>   /branches/qpid-3346/qpid/cpp/src/qpid/broker/Queue.cpp 1144324 
>   /branches/qpid-3346/qpid/cpp/src/qpid/broker/QueueEvents.cpp 1144324 
>   /branches/qpid-3346/qpid/cpp/src/qpid/broker/QueueFlowLimit.h 1144324 
>   /branches/qpid-3346/qpid/cpp/src/qpid/broker/QueueFlowLimit.cpp 1144324 
>   /branches/qpid-3346/qpid/cpp/src/qpid/broker/QueueObserver.h 1144324 
>   /branches/qpid-3346/qpid/cpp/src/qpid/broke

[jira] [Updated] (QPID-3395) Parsing exception of JNDI file should not be swallowed in Java library

2011-08-08 Thread Pavel Moravec (JIRA) 

 [ 
https://issues.apache.org/jira/browse/QPID-3395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Moravec updated QPID-3395:


Attachment: parseexception.patch

Patch proposal - an internal parsing exception caught in createDestination and 
createFactory method is re-thrown as NamingException (the only exception type 
that can be thrown by getInitialContext method).

> Parsing exception of JNDI file should not be swallowed in Java library
> --
>
> Key: QPID-3395
> URL: https://issues.apache.org/jira/browse/QPID-3395
> Project: Qpid
>  Issue Type: Improvement
>  Components: Java Client
>Affects Versions: 0.10
>Reporter: Pavel Moravec
>Priority: Minor
> Fix For: 0.12
>
> Attachments: JIRA3395_reproduction.tar.gz, parseexception.patch
>
>
> Description of problem:
> When JNDI file has a typo, InitialContext(properties) method should raise some
> parsing exception to let client program know about the parsing problem.
> Currently the exception is swallowed in
> PropertiesFileInitialContextFactory.createDestination method, writing to 
> stdout
> the exception stack trace only.
> How reproducible:
> 100%
> Steps to Reproduce:
> 1. Run the attached program with the attached MRG.jms.properties
> 2. In the output, distinguish between stdout and stderr
> Actual results:
> (*) stdout contains:
>  WARN [main] (PropertiesFileInitialContextFactory.java:244) - Unable to create
> destination:org.apache.qpid.messaging.util.ParseError: expecting LBRACE, got
> EOF line:1,7:queue2;
> org.apache.qpid.messaging.util.ParseError: expecting LBRACE, got EOF
> line:1,7:queue2;
>  at org.apache.qpid.messaging.util.Parser.eat(Parser.java:65)
>  at org.apache.qpid.messaging.util.AddressParser.map(AddressParser.java:282)
>  at
> org.apache.qpid.messaging.util.AddressParser.address(AddressParser.java:270)
>  at org.apache.qpid.messaging.util.AddressParser.parse(AddressParser.java:241)
>  at org.apache.qpid.messaging.Address.parse(Address.java:40)
>  at
> org.apache.qpid.client.AMQDestination.createAddressFromString(AMQDestination.java:855)
>  at
> org.apache.qpid.client.AMQDestination.createDestination(AMQDestination.java:696)
>  at
> org.apache.qpid.jndi.PropertiesFileInitialContextFactory.createDestination(PropertiesFileInitialContextFactory.java:240)
>  at
> org.apache.qpid.jndi.PropertiesFileInitialContextFactory.createDestinations(PropertiesFileInitialContextFactory.java:160)
>  at
> org.apache.qpid.jndi.PropertiesFileInitialContextFactory.getInitialContext(PropertiesFileInitialContextFactory.java:117)
>  at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:667)
>  at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:288)
>  at javax.naming.InitialContext.init(InitialContext.java:223)
>  at javax.naming.InitialContext.(InitialContext.java:197)
>  at JNDIError.runTest(JNDIError.java:19)
>  at JNDIError.main(JNDIError.java:12)
> (*) stderr contains:
> javax.naming.NameNotFoundException: my-queue
>  at org.apache.qpid.jndi.ReadOnlyContext.lookup(ReadOnlyContext.java:271)
>  at javax.naming.InitialContext.lookup(InitialContext.java:392)
>  at JNDIError.runTest(JNDIError.java:20)
>  at JNDIError.main(JNDIError.java:12)
> Expected results:
> (*) program execution is interrupted by (laterly caught exception) even on
> line:
> Context context = new InitialContext(properties);
> due to parsing error
> (*) stderr contains the org.apache.qpid.messaging.util.ParseError exception,
> not javax.naming.NameNotFoundException
> Additional info:
> The requirement makes sense as now only some error log is printed to stdout
> (not catch-able by the Java client program). While the API should warn the
> application directly using catch-able exception that the parsing went wrong
> (and some destination / topic / whatever can't be used in the program later
> on).

--
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-3394) Broker "leaks" messages that require async completion.

2011-08-08 Thread Justin Ross (JIRA) 

 [ 
https://issues.apache.org/jira/browse/QPID-3394?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Justin Ross updated QPID-3394:
--

Fix Version/s: 0.12

Reviewed by Gordon Sim.  Approved for inclusion in 0.12.

> Broker "leaks" messages that require async completion.
> --
>
> Key: QPID-3394
> URL: https://issues.apache.org/jira/browse/QPID-3394
> Project: Qpid
>  Issue Type: Bug
>  Components: C++ Broker
>Affects Versions: 0.12, 0.13
>Reporter: Ken Giusti
>Assignee: Ken Giusti
>Priority: Blocker
> Fix For: 0.12, 0.13
>
> Attachments: membloat.patch
>
>
> The fix for QPID-3252 introduced a bug where messages that require async 
> completion (ie. durable, or flow controlled) are incorrectly stored by the 
> broker until the sender sends an explicit flush.  This can cause a excessive 
> amount of memory to be consumed by the broker.

--
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-3390) the Java broker does not validate the exchange-declare arguments are supported

2011-08-08 Thread Robbie Gemmell (JIRA) 

[ 
https://issues.apache.org/jira/browse/QPID-3390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079360#comment-13079360
 ] 

Robbie Gemmell edited comment on QPID-3390 at 8/8/11 1:11 PM:
--

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-3392 is 
completed.

  was (Author: gemmellr):
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 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] [Commented] (QPID-3346) Support message grouping with stricted sequence consumption across multiple consumers.

2011-08-08 Thread jirapos...@reviews.apache.org (JIRA) 

[ 
https://issues.apache.org/jira/browse/QPID-3346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13080882#comment-13080882
 ] 

jirapos...@reviews.apache.org commented on QPID-3346:
-


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1312/#review1317
---



/branches/qpid-3346/qpid/cpp/src/qpid/broker/DeliveryRecord.cpp


Not too keen on this lookup. Can it be avoided?

E.g. can we modify the Queue::acquire() to simply take the consumer name as 
the second parameter? (That is for the present at least all that is required)

Alternatively the DeliveryRecord could be modified to hold a pointer to the 
Consumer rather than simply the tag.



/branches/qpid-3346/qpid/cpp/src/qpid/broker/LegacyLVQ.cpp


The purpose of the check is to ensure that an acquire attempt for a message 
that has since been replaced, does not acquire the message that has replaced it 
instead.

I believe it is still necessary, though I concede the form is ugly and 
unintuitive.



/branches/qpid-3346/qpid/cpp/src/qpid/broker/Queue.h


I'm not keen on the terminology here. For me selector implies something 
subtly different from the role this object is serving (at least from the role I 
*think* it is serving).

I'd prefer something like 'allocator'.



/branches/qpid-3346/qpid/cpp/src/qpid/broker/Queue.h


Again, I'm not too keen on the term 'consumed' in this context. Though I 
can see how it is justified, it is potentially confusing in my view (could 
imply the actual dequeue of a message).

I'd prefer 'acquired', 'allocated' or even just 'locked' as they are all 
less ambiguous on the state in question.


- Gordon


On 2011-08-05 20:46:15, Kenneth Giusti wrote:
bq.  
bq.  ---
bq.  This is an automatically generated e-mail. To reply, visit:
bq.  https://reviews.apache.org/r/1312/
bq.  ---
bq.  
bq.  (Updated 2011-08-05 20:46:15)
bq.  
bq.  
bq.  Review request for qpid.
bq.  
bq.  
bq.  Summary
bq.  ---
bq.  
bq.  Some initial refactoring of Queue/Consumer interface to allow for message 
grouping support.  Very preliminary.
bq.  
bq.  
bq.  This addresses bug qpid-3346.
bq.  https://issues.apache.org/jira/browse/qpid-3346
bq.  
bq.  
bq.  Diffs
bq.  -
bq.  
bq./branches/qpid-3346/qpid/cpp/src/qpid/broker/Consumer.h 1144324 
bq./branches/qpid-3346/qpid/cpp/src/qpid/broker/DeliveryRecord.h 1144324 
bq./branches/qpid-3346/qpid/cpp/src/qpid/broker/DeliveryRecord.cpp 1144324 
bq./branches/qpid-3346/qpid/cpp/src/qpid/broker/LegacyLVQ.cpp 1144324 
bq./branches/qpid-3346/qpid/cpp/src/qpid/broker/Queue.h 1144324 
bq./branches/qpid-3346/qpid/cpp/src/qpid/broker/Queue.cpp 1144324 
bq./branches/qpid-3346/qpid/cpp/src/qpid/broker/QueueEvents.cpp 1144324 
bq./branches/qpid-3346/qpid/cpp/src/qpid/broker/QueueFlowLimit.h 1144324 
bq./branches/qpid-3346/qpid/cpp/src/qpid/broker/QueueFlowLimit.cpp 1144324 
bq./branches/qpid-3346/qpid/cpp/src/qpid/broker/QueueObserver.h 1144324 
bq./branches/qpid-3346/qpid/cpp/src/qpid/broker/QueuePolicy.cpp 1144324 
bq./branches/qpid-3346/qpid/cpp/src/qpid/broker/SemanticState.h 1144324 
bq./branches/qpid-3346/qpid/cpp/src/qpid/broker/SemanticState.cpp 1144324 
bq./branches/qpid-3346/qpid/cpp/src/qpid/broker/ThresholdAlerts.h 1144324 
bq./branches/qpid-3346/qpid/cpp/src/qpid/cluster/Connection.cpp 1144324 
bq./branches/qpid-3346/qpid/cpp/src/tests/QueueTest.cpp 1144324 
bq.  
bq.  Diff: https://reviews.apache.org/r/1312/diff
bq.  
bq.  
bq.  Testing
bq.  ---
bq.  
bq.  minimal - passes unit tests on linux.
bq.  
bq.  
bq.  Thanks,
bq.  
bq.  Kenneth
bq.  
bq.



> Support message grouping with stricted sequence consumption across multiple 
> consumers.
> --
>
> Key: QPID-3346
> URL: https://issues.apache.org/jira/browse/QPID-3346
> Project: Qpid
>  Issue Type: New Feature
>  Components: C++ Broker
>Affects Versions: 0.12
>Reporter: Ken Giusti
>Assignee: Ken Giusti
> Fix For: 0.14
>
> Attachments: msg_groups_0.2.txt
>
>
> This feature is described in the attached QIP as Policy #2: Sequenced 
> Consumers.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira



-

Re: Review Request: Prototype of infrastructure changes needed to support message groups [PRELIMINARY]

2011-08-08 Thread Gordon Sim 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/1312/#review1317
---



/branches/qpid-3346/qpid/cpp/src/qpid/broker/DeliveryRecord.cpp


Not too keen on this lookup. Can it be avoided?

E.g. can we modify the Queue::acquire() to simply take the consumer name as 
the second parameter? (That is for the present at least all that is required)

Alternatively the DeliveryRecord could be modified to hold a pointer to the 
Consumer rather than simply the tag.



/branches/qpid-3346/qpid/cpp/src/qpid/broker/LegacyLVQ.cpp


The purpose of the check is to ensure that an acquire attempt for a message 
that has since been replaced, does not acquire the message that has replaced it 
instead.

I believe it is still necessary, though I concede the form is ugly and 
unintuitive.



/branches/qpid-3346/qpid/cpp/src/qpid/broker/Queue.h


I'm not keen on the terminology here. For me selector implies something 
subtly different from the role this object is serving (at least from the role I 
*think* it is serving).

I'd prefer something like 'allocator'.



/branches/qpid-3346/qpid/cpp/src/qpid/broker/Queue.h


Again, I'm not too keen on the term 'consumed' in this context. Though I 
can see how it is justified, it is potentially confusing in my view (could 
imply the actual dequeue of a message).

I'd prefer 'acquired', 'allocated' or even just 'locked' as they are all 
less ambiguous on the state in question.


- Gordon


On 2011-08-05 20:46:15, Kenneth Giusti wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/1312/
> ---
> 
> (Updated 2011-08-05 20:46:15)
> 
> 
> Review request for qpid.
> 
> 
> Summary
> ---
> 
> Some initial refactoring of Queue/Consumer interface to allow for message 
> grouping support.  Very preliminary.
> 
> 
> This addresses bug qpid-3346.
> https://issues.apache.org/jira/browse/qpid-3346
> 
> 
> Diffs
> -
> 
>   /branches/qpid-3346/qpid/cpp/src/qpid/broker/Consumer.h 1144324 
>   /branches/qpid-3346/qpid/cpp/src/qpid/broker/DeliveryRecord.h 1144324 
>   /branches/qpid-3346/qpid/cpp/src/qpid/broker/DeliveryRecord.cpp 1144324 
>   /branches/qpid-3346/qpid/cpp/src/qpid/broker/LegacyLVQ.cpp 1144324 
>   /branches/qpid-3346/qpid/cpp/src/qpid/broker/Queue.h 1144324 
>   /branches/qpid-3346/qpid/cpp/src/qpid/broker/Queue.cpp 1144324 
>   /branches/qpid-3346/qpid/cpp/src/qpid/broker/QueueEvents.cpp 1144324 
>   /branches/qpid-3346/qpid/cpp/src/qpid/broker/QueueFlowLimit.h 1144324 
>   /branches/qpid-3346/qpid/cpp/src/qpid/broker/QueueFlowLimit.cpp 1144324 
>   /branches/qpid-3346/qpid/cpp/src/qpid/broker/QueueObserver.h 1144324 
>   /branches/qpid-3346/qpid/cpp/src/qpid/broker/QueuePolicy.cpp 1144324 
>   /branches/qpid-3346/qpid/cpp/src/qpid/broker/SemanticState.h 1144324 
>   /branches/qpid-3346/qpid/cpp/src/qpid/broker/SemanticState.cpp 1144324 
>   /branches/qpid-3346/qpid/cpp/src/qpid/broker/ThresholdAlerts.h 1144324 
>   /branches/qpid-3346/qpid/cpp/src/qpid/cluster/Connection.cpp 1144324 
>   /branches/qpid-3346/qpid/cpp/src/tests/QueueTest.cpp 1144324 
> 
> Diff: https://reviews.apache.org/r/1312/diff
> 
> 
> Testing
> ---
> 
> minimal - passes unit tests on linux.
> 
> 
> Thanks,
> 
> Kenneth
> 
>