date:20110208

I think trying to clean up how people use the codebase is a good idea,
no question about that. However, as there is already a
ConnectionFactory implementation that people simply miss/ignore
already when overlooking/ignoring JNDI I do wonder if providing a
ConnectionFactory..Factory..is actually going to change their
behaviour?

Robbie

On 7 February 2011 17:00, Rajith Attapattu rajit...@gmail.com wrote:
 So far I have only heard positive comments about this approach.
 Does anybody have any concerns about the approach in general or any comments
 about how it should be done if it's needed ?

 I am hoping  to create a JIRA on this soon abd perhaps attach a very simple
 patch.
 And if there are no objections, I will be tempted to commit it by the end of
 the week.

 I'd like to make sure we get it right as we need to provide a stable
 interface between releases going forward.
 Therefore I urge all interested folks to voice in their concerns/opinions at
 the earliest possible.

 Regards,

 Rajith.

 On Mon, Feb 7, 2011 at 10:46 AM, Andrew Stitcher astitc...@redhat.comwrote:

 On Fri, 2011-02-04 at 11:22 -0500, Rajith Attapattu wrote:
  Hi,
 
  Some Qpid users like to create connections and destinations dynamically
  instead of using the jndi.properties file.
  All though there is a reasonable way of creating Queues and Topics using
  session.createQueue and session.createTopic respectively, there is
 currently
  no proper way of creating connections.
 
  Therefore people resort to using AMQConnection class., which is less than
  ideal.
  Chances are that this class can change, get deprecated in favour of a
 better
  implementation etc.. in a future release.
 
  Perhaps we should provide a stable API for creating connections without
  having to use internal implementation specific classes for folks who want
 to
  do it dynamically.
  Maybe something along the lines of,
 
  Qpid {
 
  public javax.jms.ConnectionFactory createConnectionFactory(String user,
  String password);
 
  public javax.jms.ConnectionFactory createConnectionFactory(String url);
 
  public javax.jms.Connection createConnection(String user, String
 password);
 
  public javax.jms.Connection createConnection(String url);
 
  public javax.jms.Destination(String addr);
 
  }
 
  That way we can shield a Qpid user from changes in a reasonable way.
  However we need to impress upon our users that the preferred way is to
 use
  the JNDI mechanism.
  On the other hand users could use the above mechanism to create
 connections
  and destinations and inject them into their preferred JNDI mechanism
 rather
  than using our JNDI implementation.

 An important place where this would be used would be infrastructure
 code; a good example would be the JCA adapter.

 Andrew



 -
 Apache Qpid - AMQP Messaging Implementation
 Project:      http://qpid.apache.org
 Use/Interact: mailto:dev-subscr...@qpid.apache.org




 --
 Regards,

 Rajith Attapattu
 Red Hat
 http://rajith.2rlabs.com/


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Re: Use of JIRA

I largely agree with Rajith as shown by my commit history, there are
some changes I dont think warrant a JIRA such as random litle README
or website changes (however, larger documentation changes should
generally be associated with a JIRA because surely they are
documenting something that was implemented or fixed).

The problem defining where that line is and then not crossing it;
results suggest we have proven absolutely incapable of doing that as a
group so far. Also, as mentioned there are tools such as the JIRA
commit list that require a JIRA tag in order to work at all; it would
be good for everything to be visible there.

There should be a minimal amount of cases that would be warranted to
forego a JIRA, to the extent that id rather just enforce 100% JIRA
creation to stop there being any room for doubt or getting lazy. They
dont always have to be new JIRAs, as Andrew suggested some of them
could be short term umbrella JIRAs, eg 'Release preperation readme
cleanup' etc. It doesnt take long to create a short but descriptive
titled JIRA.

Robbie

On 7 February 2011 16:55, Rajith Attapattu rajit...@gmail.com wrote:
 On Mon, Feb 7, 2011 at 11:15 AM, Jonathan Robie
 jonathan.ro...@redhat.comwrote:

 I'm also a repeat offender. I'll create the missing JIRAs and do better
 going forward.

 Question: I have some commits that I think are quite minor, fixing a
 README, whitespace, etc. I assume I don't need a JIRA for that kind of
 thing?


 IMO I don't think you need a JIRA for trivial things like that.
 However when you commit code it's best to have a JIRA.
 95% of the commits done in actual code are either bug fixes or new features
 or things that sort of sit in btw and I thing we need a JIRA for those.
 The other 5% are probably fixing typos, documentation, cleaning up etc.. can
 probably go in without a JIRA.

 If you are fixing a bug, then even if it's just a one line commit, it's
 really important to create a JIRA.
 Also updating those JIRA's with release info is very important as well.
 If not we really don't know what we fixed in each release.




 Jonathan


 -
 Apache Qpid - AMQP Messaging Implementation
 Project:      http://qpid.apache.org
 Use/Interact: mailto:dev-subscr...@qpid.apache.org




 --
 Regards,

 Rajith Attapattu
 Red Hat
 http://rajith.2rlabs.com/


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Re: Use of JIRA

2011-02-08 Thread Rajith Attapattu

On Tue, Feb 8, 2011 at 8:14 AM, Robbie Gemmell robbie.gemm...@gmail.comwrote:

 I largely agree with Rajith as shown by my commit history, there are
 some changes I dont think warrant a JIRA such as random litle README
 or website changes (however, larger documentation changes should
 generally be associated with a JIRA because surely they are
 documenting something that was implemented or fixed).


Agreed !
Some of the documentation changes are prompted by bug fixes or new features
being added.
In such cases it's best to include the svn commit for doc changes under the
original JIRA created for the bug or new feature.
As a group we have been historically bad when it comes to keeping our docs
in sync with the code.
(All though separate discussion, I think Release managers should not allow a
JIRA to be marked resolved if they feel it needs documentation updates.)

I think we need to have a commit hook that displays a friendly message
reminding folks to include a JIRA number and update the docs if necessary.
That IMO is better than one that blocks a commit bcos there is no JIRA in
the commit log.

When people keep seeing the same message every time they commit, it will
eventually sink in :)

Rajith.


 The problem defining where that line is and then not crossing it;
 results suggest we have proven absolutely incapable of doing that as a
 group so far. Also, as mentioned there are tools such as the JIRA
 commit list that require a JIRA tag in order to work at all; it would
 be good for everything to be visible there.

 There should be a minimal amount of cases that would be warranted to
 forego a JIRA, to the extent that id rather just enforce 100% JIRA
 creation to stop there being any room for doubt or getting lazy. They
 dont always have to be new JIRAs, as Andrew suggested some of them
 could be short term umbrella JIRAs, eg 'Release preperation readme
 cleanup' etc. It doesnt take long to create a short but descriptive
 titled JIRA.

 Robbie

 On 7 February 2011 16:55, Rajith Attapattu rajit...@gmail.com wrote:
  On Mon, Feb 7, 2011 at 11:15 AM, Jonathan Robie
  jonathan.ro...@redhat.comwrote:
 
  I'm also a repeat offender. I'll create the missing JIRAs and do better
  going forward.
 
  Question: I have some commits that I think are quite minor, fixing a
  README, whitespace, etc. I assume I don't need a JIRA for that kind of
  thing?
 
 
  IMO I don't think you need a JIRA for trivial things like that.
  However when you commit code it's best to have a JIRA.
  95% of the commits done in actual code are either bug fixes or new
 features
  or things that sort of sit in btw and I thing we need a JIRA for those.
  The other 5% are probably fixing typos, documentation, cleaning up etc..
 can
  probably go in without a JIRA.
 
  If you are fixing a bug, then even if it's just a one line commit, it's
  really important to create a JIRA.
  Also updating those JIRA's with release info is very important as well.
  If not we really don't know what we fixed in each release.
 
 
 
 
  Jonathan
 
 
  -
  Apache Qpid - AMQP Messaging Implementation
  Project:  http://qpid.apache.org
  Use/Interact: mailto:dev-subscr...@qpid.apache.org
 
 
 
 
  --
  Regards,
 
  Rajith Attapattu
  Red Hat
  http://rajith.2rlabs.com/
 

 -
 Apache Qpid - AMQP Messaging Implementation
 Project:  http://qpid.apache.org
 Use/Interact: mailto:dev-subscr...@qpid.apache.org




-- 
Regards,

Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/

Re: Use of JIRA

Adding the tag after the fact does nothing to fix the commits where it
was missing at the time, because JIRA and associated tools work off
the original commit emails and so updating the log property afterwards
doesn't fix that. Always being able to 'accidentally' forget to
create/include a reference, or saying 'ill do it tomorrow' just lets
people off the hook from ever doing so (that and such thigns can/do
get forgotten easily enough.

We could allow certain things through the hook, eg putting NO-JIRA in
the commit log bypasses it. That could presumably also be stripped by
the hook on success, and be indicated in any failure message to ensure
people always know its an option. That way its still possible to
commit without a JIRA, but makes doing so a conscious decision to
subvert the JIRA process. It also takes accidental ommision out the
picture and makes it quite easy to name-and-shame people for not
making JIRAs for things they should have.

Robbie

On 8 February 2011 14:07, Rajith Attapattu rajit...@gmail.com wrote:
 On Tue, Feb 8, 2011 at 8:14 AM, Robbie Gemmell 
 robbie.gemm...@gmail.comwrote:

 I largely agree with Rajith as shown by my commit history, there are
 some changes I dont think warrant a JIRA such as random litle README
 or website changes (however, larger documentation changes should
 generally be associated with a JIRA because surely they are
 documenting something that was implemented or fixed).


 Agreed !
 Some of the documentation changes are prompted by bug fixes or new features
 being added.
 In such cases it's best to include the svn commit for doc changes under the
 original JIRA created for the bug or new feature.
 As a group we have been historically bad when it comes to keeping our docs
 in sync with the code.
 (All though separate discussion, I think Release managers should not allow a
 JIRA to be marked resolved if they feel it needs documentation updates.)

 I think we need to have a commit hook that displays a friendly message
 reminding folks to include a JIRA number and update the docs if necessary.
 That IMO is better than one that blocks a commit bcos there is no JIRA in
 the commit log.

 When people keep seeing the same message every time they commit, it will
 eventually sink in :)

 Rajith.


 The problem defining where that line is and then not crossing it;
 results suggest we have proven absolutely incapable of doing that as a
 group so far. Also, as mentioned there are tools such as the JIRA
 commit list that require a JIRA tag in order to work at all; it would
 be good for everything to be visible there.

 There should be a minimal amount of cases that would be warranted to
 forego a JIRA, to the extent that id rather just enforce 100% JIRA
 creation to stop there being any room for doubt or getting lazy. They
 dont always have to be new JIRAs, as Andrew suggested some of them
 could be short term umbrella JIRAs, eg 'Release preperation readme
 cleanup' etc. It doesnt take long to create a short but descriptive
 titled JIRA.

 Robbie

 On 7 February 2011 16:55, Rajith Attapattu rajit...@gmail.com wrote:
  On Mon, Feb 7, 2011 at 11:15 AM, Jonathan Robie
  jonathan.ro...@redhat.comwrote:
 
  I'm also a repeat offender. I'll create the missing JIRAs and do better
  going forward.
 
  Question: I have some commits that I think are quite minor, fixing a
  README, whitespace, etc. I assume I don't need a JIRA for that kind of
  thing?
 
 
  IMO I don't think you need a JIRA for trivial things like that.
  However when you commit code it's best to have a JIRA.
  95% of the commits done in actual code are either bug fixes or new
 features
  or things that sort of sit in btw and I thing we need a JIRA for those.
  The other 5% are probably fixing typos, documentation, cleaning up etc..
 can
  probably go in without a JIRA.
 
  If you are fixing a bug, then even if it's just a one line commit, it's
  really important to create a JIRA.
  Also updating those JIRA's with release info is very important as well.
  If not we really don't know what we fixed in each release.
 
 
 
 
  Jonathan
 
 
  -
  Apache Qpid - AMQP Messaging Implementation
  Project:      http://qpid.apache.org
  Use/Interact: mailto:dev-subscr...@qpid.apache.org
 
 
 
 
  --
  Regards,
 
  Rajith Attapattu
  Red Hat
  http://rajith.2rlabs.com/
 

 -
 Apache Qpid - AMQP Messaging Implementation
 Project:      http://qpid.apache.org
 Use/Interact: mailto:dev-subscr...@qpid.apache.org




 --
 Regards,

 Rajith Attapattu
 Red Hat
 http://rajith.2rlabs.com/


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Re: Use of JIRA

For example, this commit should have had a JIRA, and the commit it
reverts had a JIRA listed. However, looking at the commit tab on that
JIRA in future there will be no indication this revert occured.

URL: http://svn.apache.org/viewvc?rev=1068417view=rev
Log:
Reverts r1068042.

We will fix this bug in the C++ client messaging library rather than
the broker.

Robbie

On 8 February 2011 15:15, Robbie Gemmell robbie.gemm...@gmail.com wrote:

snip
 We could allow certain things through the hook, eg putting NO-JIRA in
 the commit log bypasses it. That could presumably also be stripped by
 the hook on success, and be indicated in any failure message to ensure
 people always know its an option. That way its still possible to
 commit without a JIRA, but makes doing so a conscious decision to
 subvert the JIRA process. It also takes accidental ommision out the
 picture
/snip


 On 8 February 2011 14:07, Rajith Attapattu rajit...@gmail.com wrote:
 On Tue, Feb 8, 2011 at 8:14 AM, Robbie Gemmell 
 robbie.gemm...@gmail.comwrote:

 I largely agree with Rajith as shown by my commit history, there are
 some changes I dont think warrant a JIRA such as random litle README
 or website changes (however, larger documentation changes should
 generally be associated with a JIRA because surely they are
 documenting something that was implemented or fixed).


 Agreed !
 Some of the documentation changes are prompted by bug fixes or new features
 being added.
 In such cases it's best to include the svn commit for doc changes under the
 original JIRA created for the bug or new feature.
 As a group we have been historically bad when it comes to keeping our docs
 in sync with the code.
 (All though separate discussion, I think Release managers should not allow a
 JIRA to be marked resolved if they feel it needs documentation updates.)

 I think we need to have a commit hook that displays a friendly message
 reminding folks to include a JIRA number and update the docs if necessary.
 That IMO is better than one that blocks a commit bcos there is no JIRA in
 the commit log.

 When people keep seeing the same message every time they commit, it will
 eventually sink in :)

 Rajith.


 The problem defining where that line is and then not crossing it;
 results suggest we have proven absolutely incapable of doing that as a
 group so far. Also, as mentioned there are tools such as the JIRA
 commit list that require a JIRA tag in order to work at all; it would
 be good for everything to be visible there.

 There should be a minimal amount of cases that would be warranted to
 forego a JIRA, to the extent that id rather just enforce 100% JIRA
 creation to stop there being any room for doubt or getting lazy. They
 dont always have to be new JIRAs, as Andrew suggested some of them
 could be short term umbrella JIRAs, eg 'Release preperation readme
 cleanup' etc. It doesnt take long to create a short but descriptive
 titled JIRA.

 Robbie

 On 7 February 2011 16:55, Rajith Attapattu rajit...@gmail.com wrote:
  On Mon, Feb 7, 2011 at 11:15 AM, Jonathan Robie
  jonathan.ro...@redhat.comwrote:
 
  I'm also a repeat offender. I'll create the missing JIRAs and do better
  going forward.
 
  Question: I have some commits that I think are quite minor, fixing a
  README, whitespace, etc. I assume I don't need a JIRA for that kind of
  thing?
 
 
  IMO I don't think you need a JIRA for trivial things like that.
  However when you commit code it's best to have a JIRA.
  95% of the commits done in actual code are either bug fixes or new
 features
  or things that sort of sit in btw and I thing we need a JIRA for those.
  The other 5% are probably fixing typos, documentation, cleaning up etc..
 can
  probably go in without a JIRA.
 
  If you are fixing a bug, then even if it's just a one line commit, it's
  really important to create a JIRA.
  Also updating those JIRA's with release info is very important as well.
  If not we really don't know what we fixed in each release.
 
 
 
 
  Jonathan
 
 
  -
  Apache Qpid - AMQP Messaging Implementation
  Project:      http://qpid.apache.org
  Use/Interact: mailto:dev-subscr...@qpid.apache.org
 
 
 
 
  --
  Regards,
 
  Rajith Attapattu
  Red Hat
  http://rajith.2rlabs.com/
 

 -
 Apache Qpid - AMQP Messaging Implementation
 Project:      http://qpid.apache.org
 Use/Interact: mailto:dev-subscr...@qpid.apache.org




 --
 Regards,

 Rajith Attapattu
 Red Hat
 http://rajith.2rlabs.com/



-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Re: Use of JIRA

2011-02-08 Thread Andrew Stitcher

On Tue, 2011-02-08 at 13:14 +, Robbie Gemmell wrote:
 I largely agree with Rajith as shown by my commit history, there are
 some changes I dont think warrant a JIRA such as random litle README
 or website changes (however, larger documentation changes should
 generally be associated with a JIRA because surely they are
 documenting something that was implemented or fixed).
 
 The problem defining where that line is and then not crossing it;
 results suggest we have proven absolutely incapable of doing that as a
 group so far. Also, as mentioned there are tools such as the JIRA
 commit list that require a JIRA tag in order to work at all; it would
 be good for everything to be visible there.

Perhaps we could resolve this by creating catchall JIRAs for the various
categories of trivial checkins.

Say:

One for License additions, one for typos in comments, one for trivial
documentation changes there are probably categories to add here. Lets
not spend too long on this though. I'm unclear whether there are any
code changes sufficiently trivial for a catchall, but there may be.

I prefer having a rough categorisation as this will stop people from
just adding QPID- to every simple checkin and require a small amount
of thought for every checkin.

Once we have these catch-alls then we could have a check in hook that
requires a valid QPID- bug number in the checkin comment, without
affecting trivial checkins.

Andrew



-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] Created: (QPID-3044) Implement JCA Adapter for Java JMS client

2011-02-08 Thread Andrew Stitcher (JIRA)

Implement JCA Adapter for Java JMS client
-

 Key: QPID-3044
 URL: https://issues.apache.org/jira/browse/QPID-3044
 Project: Qpid
  Issue Type: Improvement
  Components: Java Client
Affects Versions: 0.8
Reporter: Andrew Stitcher
Assignee: Andrew Stitcher
 Fix For: 0.9


Currently there is no way to integrate the use of Qpid messaging into a Java
Application Server.

The solution is to create a JCA (J2EE Connector Architecture) adapter to allow
the Qpid JMS client to correctly work with the J2EE container.

This is an entirely new Java component, but may require small amounts of change 
to the
JMS client code.


-- 
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-3044) Implement JCA Adapter for Java JMS client

2011-02-08 Thread Andrew Stitcher (JIRA)


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

Andrew Stitcher updated QPID-3044:
--

Issue Type: New Feature  (was: Improvement)

 Implement JCA Adapter for Java JMS client
 -

 Key: QPID-3044
 URL: https://issues.apache.org/jira/browse/QPID-3044
 Project: Qpid
  Issue Type: New Feature
  Components: Java Client
Affects Versions: 0.8
Reporter: Andrew Stitcher
Assignee: Andrew Stitcher
  Labels: JCA, JMS, Java, qpid
 Fix For: 0.9


 Currently there is no way to integrate the use of Qpid messaging into a Java
 Application Server.
 The solution is to create a JCA (J2EE Connector Architecture) adapter to allow
 the Qpid JMS client to correctly work with the J2EE container.
 This is an entirely new Java component, but may require small amounts of 
 change to the
 JMS client code.

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



-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] Created: (QPID-3045) Bug 675921 - clustered qpidd broker fails ocassionly the cluster_tests.ShortTests.test_route_update

Bug 675921 - clustered qpidd broker fails ocassionly the 
cluster_tests.ShortTests.test_route_update
---

 Key: QPID-3045
 URL: https://issues.apache.org/jira/browse/QPID-3045
 Project: Qpid
  Issue Type: Bug
  Components: C++ Clustering
Affects Versions: 0.9
Reporter: Alan Conway
Assignee: Alan Conway


See https://bugzilla.redhat.com/show_bug.cgi?id=675921

-- 
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-3045) Bug 675921 - clustered qpidd broker fails ocassionly the cluster_tests.ShortTests.test_route_update


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

Alan Conway updated QPID-3045:
--

Fix Version/s: 0.9

 Bug 675921 - clustered qpidd broker fails ocassionly the 
 cluster_tests.ShortTests.test_route_update
 ---

 Key: QPID-3045
 URL: https://issues.apache.org/jira/browse/QPID-3045
 Project: Qpid
  Issue Type: Bug
  Components: C++ Clustering
Affects Versions: 0.9
Reporter: Alan Conway
Assignee: Alan Conway
 Fix For: 0.9


 See https://bugzilla.redhat.com/show_bug.cgi?id=675921

-- 
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-2935) Support best effort producer flow control within the AMQP 0.10 implementation.

2011-02-08 Thread Ken Giusti (JIRA)

[
https://issues.apache.org/jira/browse/QPID-2935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12992025#comment-12992025
]

Ken Giusti commented on QPID-2935:
--

Status update 2/7/2011:

Resync'ed to trunk.
Fixed:
-) Cleanup synchronous completion case in SessionState ~line 267
-) Creates a request for IOProcessing on each completion - need to aggregate
these.

Additional work item: forgot to add:
o) Replication of new queue thresholds for clustering.
o) Documentation updates.

And still TBD:
o) Performance regression testing tuning.
o) Sends completion on every execution.sync, else hangs. Can this be fixed?
o) Hang in clustered + async store tests. Need debug fix.
o) Reviews pending for management changes.
o) Reviews pending for queue flow limit changes.

Support best effort producer flow control within the AMQP 0.10
implementation.

Key: QPID-2935
URL: https://issues.apache.org/jira/browse/QPID-2935
Project: Qpid
Issue Type: New Feature
Components: C++ Broker, C++ Client
Affects Versions: 0.9
Environment: any
Reporter: Ken Giusti
Assignee: Ken Giusti
Fix For: 0.9

Attachments: QPID-2935.tgz

To what extent, if any, could producer flow control be supported on the
existing (pre-1.0) protocol?
In the current C++ broker/client implementation, when a queue on the broker
fills to the point where it cannot accept any more messages
(--default-queue-limit hit), the broker will forcibly disconnect any client
that attempts to route a message to that queue. This is an abrupt failure -
the producing client is not privy to the queue's remaining capacity. The
broker provides no feedback to the producing client, which could be used to
throttle the client's message production rate.
The purpose of this JIRA is to explore the possible methods for implementing
producer throttling on the current 0.10 C++ codebase.

--
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

Re: Use of JIRA

2011-02-08 Thread Gordon Sim


On 02/08/2011 03:15 PM, Robbie Gemmell wrote:

We could allow certain things through the hook, eg putting NO-JIRA in
the commit log bypasses it. That could presumably also be stripped by
the hook on success, and be indicated in any failure message to ensure
people always know its an option. That way its still possible to
commit without a JIRA, but makes doing so a conscious decision to
subvert the JIRA process. It also takes accidental ommision out the
picture and makes it quite easy to name-and-shame people for not
making JIRAs for things they should have.


I like this. It avoids cluttering up JIRA when there is a good case for 
a commit without one.


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] Commented: (QPID-529) Support message priority


[ 
https://issues.apache.org/jira/browse/QPID-529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12992031#comment-12992031
 ] 

Gordon Sim commented on QPID-529:
-

Initial implementation available for review: https://reviews.apache.org/r/406/. 
This includes some queue refactoring to keep the various different pieces of 
logic cleanly distinct.

 Support message priority
 

 Key: QPID-529
 URL: https://issues.apache.org/jira/browse/QPID-529
 Project: Qpid
  Issue Type: New Feature
  Components: C++ Broker
Reporter: Gordon Sim
Assignee: Gordon Sim
 Fix For: 0.9




-- 
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-529) Support message priority


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

Gordon Sim updated QPID-529:


Due Date: 16/Feb/11  (was: 18/Feb/11)

 Support message priority
 

 Key: QPID-529
 URL: https://issues.apache.org/jira/browse/QPID-529
 Project: Qpid
  Issue Type: New Feature
  Components: C++ Broker
Reporter: Gordon Sim
Assignee: Gordon Sim
 Fix For: 0.9




-- 
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-2104) Improved LVQ implementation

[
https://issues.apache.org/jira/browse/QPID-2104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12992034#comment-12992034
]

Gordon Sim commented on QPID-2104:
--

Patch including this fix available for review:
https://reviews.apache.org/r/406/. (That patch includes some refactoring of the
queue implementation to make this change possible as well as to cleanup the old
LVQ implementation and keep it out of the main codepaths).

Improved LVQ implementation
---

Key: QPID-2104
URL: https://issues.apache.org/jira/browse/QPID-2104
Project: Qpid
Issue Type: Improvement
Components: C++ Broker
Affects Versions: 0.5
Reporter: Gordon Sim
Assignee: Gordon Sim
Fix For: 0.9

My view of what ideal 'LVQ' behaviour whould be like is that the 'queue'
would really be more like a 'topic' where the last message for each key was
always saved. Clients would subscribe to it and receive the last message
published for each key and subsequently any updates (i.e. any new messages).
I.e. the consumers are always non-competing.
Rob Godfrey also points out that if subscribers fall behind they need only be
sent the latest for every key (i.e. any superceded values can be skipped).

--
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-2104) Improved LVQ implementation


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

Gordon Sim updated QPID-2104:
-

Fix Version/s: 0.9

 Improved LVQ implementation
 ---

 Key: QPID-2104
 URL: https://issues.apache.org/jira/browse/QPID-2104
 Project: Qpid
  Issue Type: Improvement
  Components: C++ Broker
Affects Versions: 0.5
Reporter: Gordon Sim
Assignee: Gordon Sim
 Fix For: 0.9


 My view of what ideal 'LVQ' behaviour whould be like is that the 'queue'
 would really be more like a 'topic' where the last message for each key was
 always saved. Clients would subscribe to it and receive the last message
 published for each key and subsequently any updates (i.e. any new messages). 
 I.e. the consumers are always non-competing.
 Rob Godfrey also points out that if subscribers fall behind they need only be 
 sent the latest for every key (i.e. any superceded values  can be skipped).

-- 
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-2104) Improved LVQ implementation

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

Gordon Sim updated QPID-2104:
-

Due Date: 16/Feb/11
Description:
My view of what ideal 'LVQ' behaviour would be like is that the 'queue'
would really be more like a 'topic' where the last message for each key was
always saved. Clients would subscribe to it and receive the last message
published for each key and subsequently any updates (i.e. any new messages).
I.e. the consumers are always non-competing.

Rob Godfrey also points out that if subscribers fall behind they need only be
sent the latest for every key (i.e. any superceded values can be skipped).

was:
My view of what ideal 'LVQ' behaviour whould be like is that the 'queue'
would really be more like a 'topic' where the last message for each key was
always saved. Clients would subscribe to it and receive the last message
published for each key and subsequently any updates (i.e. any new messages).
I.e. the consumers are always non-competing.

Rob Godfrey also points out that if subscribers fall behind they need only be
sent the latest for every key (i.e. any superceded values can be skipped).

Improved LVQ implementation
---

My view of what ideal 'LVQ' behaviour would be like is that the 'queue'
would really be more like a 'topic' where the last message for each key was
always saved. Clients would subscribe to it and receive the last message
published for each key and subsequently any updates (i.e. any new messages).
I.e. the consumers are always non-competing.
Rob Godfrey also points out that if subscribers fall behind they need only be
sent the latest for every key (i.e. any superceded values can be skipped).

--
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

Are there any complete examples of durable / persistent transport on Windows?

2011-02-08 Thread Kerry Bonin

Appreciate any help...

Re: Are there any complete examples of durable / persistent transport on Windows?

2011-02-08 Thread Andrew Stitcher

On Tue, 2011-02-08 at 11:29 -0600, Kerry Bonin wrote:
 Appreciate any help...

Could you be a little clearer with what you want? In the current qpid
implementation (in C++ broker at least) durability of messages isn't
related to the transport (which is a networking concept), but to a
persistence plugin. I don't know if this is also true for the Java
broker (if you wanted that) but I'd think it's pretty likely to be true
there too.

Andrew



-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Re: Use of JIRA

2011-02-08 Thread Jonathan Robie


On 02/08/2011 10:30 AM, Robbie Gemmell wrote:

For example, this commit should have had a JIRA, and the commit it
reverts had a JIRA listed. However, looking at the commit tab on that
JIRA in future there will be no indication this revert occured.

URL: http://svn.apache.org/viewvc?rev=1068417view=rev
Log:
Reverts r1068042.


OK, lesson learned. I was thinking reverting a change didn't need this.

Jonathan

-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Re: Are there any complete examples of durable / persistent transport on Windows?

2011-02-08 Thread Kerry Bonin

I'm interested in the classic durable subscription case - two clients and a
broker, client 2 has a durable subscription to a queue, client 1 sends
something to that queue while client 2 is disconnected.  When client 2
reconnects it would like to receive the messages it missed.  Ideally this
could include a power cycle of the broker, hence my interest in the database
persistence module.

I've enabled the mssql persistence module, but the next steps are unclear -
I've found conflicting information on how to setup the subscription, and am
hoping to avoid stepping into the broker to figure out what I'm missing or
doing wrong.

We're using the C++ broker and have been building from recent sources.

I'm also curious if there is support / plans for durability on the client
side - having the client queue sent messages if the broker is temporarily
offline.

Thanks!

On Tue, Feb 8, 2011 at 11:39 AM, Andrew Stitcher astitc...@redhat.comwrote:

 On Tue, 2011-02-08 at 11:29 -0600, Kerry Bonin wrote:
  Appreciate any help...

 Could you be a little clearer with what you want? In the current qpid
 implementation (in C++ broker at least) durability of messages isn't
 related to the transport (which is a networking concept), but to a
 persistence plugin. I don't know if this is also true for the Java
 broker (if you wanted that) but I'd think it's pretty likely to be true
 there too.

 Andrew



 -
 Apache Qpid - AMQP Messaging Implementation
 Project:  http://qpid.apache.org
 Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] Commented: (QPID-2994) transactions atomicity violated by 'transparent' failover

2011-02-08 Thread Rajith Attapattu (JIRA)

[
https://issues.apache.org/jira/browse/QPID-2994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12992086#comment-12992086
]

Rajith Attapattu commented on QPID-2994:

We do throw an exception indicating that failover has happened and the session
is closed.
However I think we need to explicitly mention that the transaction is
rollbacked.

We also need to document,
1. Which exceptions will destroy a session
2. And which exceptions can be handled and continue with the session.

transactions atomicity violated by 'transparent' failover
-

Key: QPID-2994
URL: https://issues.apache.org/jira/browse/QPID-2994
Project: Qpid
Issue Type: Bug
Components: Java Client
Affects Versions: 0.6, 0.7, 0.8
Reporter: Rajith Attapattu
Assignee: Rajith Attapattu
Fix For: Future

Attachments: QPID-2994.patch

The messages published within a batch at the point the connection failsover
appear to be replayed outside of any transaction.
Steps to Reproduce:
1. start transactional session on failover enabled connection
2. send batches of messages in transactions
3. kill the cluster node the client is connected to, to trigger failover mid
transaction
This happens due to the lower layer replaying unacked messages upon resuming
the connection.
Message replay should not happen on a transacted session as there is no
benefit of doing so.

--
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-3045) Sporadic failure of cluster_tests.ShortTests.test_route_update


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

Alan Conway updated QPID-3045:
--

Description: 
See https://bugzilla.redhat.com/show_bug.cgi?id=675921


  was:See https://bugzilla.redhat.com/show_bug.cgi?id=675921

   Priority: Minor  (was: Major)
Summary: Sporadic failure of cluster_tests.ShortTests.test_route_update 
   (was: Bug 675921 - clustered qpidd broker fails ocassionly the 
cluster_tests.ShortTests.test_route_update)

 Sporadic failure of cluster_tests.ShortTests.test_route_update  
 

 Key: QPID-3045
 URL: https://issues.apache.org/jira/browse/QPID-3045
 Project: Qpid
  Issue Type: Bug
  Components: C++ Clustering
Affects Versions: 0.9
Reporter: Alan Conway
Assignee: Alan Conway
Priority: Minor
 Fix For: 0.9


 See https://bugzilla.redhat.com/show_bug.cgi?id=675921

-- 
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

Re: [JMS] Creating connections destinations dynamically

2011-02-08 Thread Gordon Sim


On 02/07/2011 11:55 PM, Andrew Kennedy wrote:

Perhaps we should designate a package (or more?) which will only contain
public interfaces.


That sounds like a good idea to me.


Probably org.apache.qpid.jms is the right place for
these?


I agree in principle, though some of the classes or interfaces already 
in org.apache.qpid.jms need some review in my opinion.


Pulling in definitions from other qpid packages should really be avoided 
for the approach you suggest (e.g. AMQShortString, ProtocolVersion, 
SSLConfiguration etc).


That package also includes JMS extensions. I'm not convinced that these 
are all features we should be encouraging people to use going forward. 
Certainly they are in a different category to APIs for creating 
implementations of standard JMS interfaces.


I am really not a fan of the connection url syntax the JMS client uses 
either.


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] Resolved: (QPID-3045) Sporadic failure of cluster_tests.ShortTests.test_route_update