date:20110310

We had a similar discussion when 0.8 went out and the feeling was that
issues completed during the development stream should be left marked as such
because you cant have 2 fix-for versions when resolving a JIRA, and so only
issues that were fixed after branching and updating the version would get
fix-for as the release version.

Last time we released I generated some html release notes with the content
from the 0.7 and 0.8 versions in JIRA and put them on the website. This
allows organising them a little nicer in terms of what gets more prominence,
and means the release email drives traffic to the website rather than JIRA
(which also has a side effect of being faster for the users, since JIRA is
often excruciatingly slow).

Robbie

On 10 March 2011 14:14, Gordon Sim g...@redhat.com wrote:

 On 03/10/2011 01:50 PM, Marnie McCormack wrote:

 Hi Justin/All,

 I'm wondering what the approach for identifying the content of the 0-10
 release from JIRA is ?

 I've just been trying to figure out what is actually in 0-10 from JIRA and
 its not easy since we have 0-10 items complete adn I think raised during
 the
 release process and a load of open 0-9 items for which we can't tell the
 target release.

 We should be able to generate release notes from JIRA, so should we update
 all items in the 0-10 release to have a fix for version of 0-10 ?


 I marked the JIRAs I fixed for 0.10 as fix-for 0.9 (the 0.10 option was
 only recently added). So I believe anything that is resolved and has fix-for
 0.9[1] can have the fix-for updated to 0-10. Anyone know if there is a way
 to do this as a bulk update or similar?

 [1]
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310520version=12315382

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

Re: 0-10 JIRAs


On Thu, 10 Mar 2011, Gordon Sim wrote:


On 03/10/2011 01:50 PM, Marnie McCormack wrote:

Hi Justin/All,

I'm wondering what the approach for identifying the content of the 0-10
release from JIRA is ?

I've just been trying to figure out what is actually in 0-10 from JIRA and
its not easy since we have 0-10 items complete adn I think raised during 
the

release process and a load of open 0-9 items for which we can't tell the
target release.

We should be able to generate release notes from JIRA, so should we update
all items in the 0-10 release to have a fix for version of 0-10 ?


I marked the JIRAs I fixed for 0.10 as fix-for 0.9 (the 0.10 option was only 
recently added). So I believe anything that is resolved and has fix-for 
0.9[1] can have the fix-for updated to 0-10. Anyone know if there is a way to 
do this as a bulk update or similar?


[1] 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310520version=12315382


I spoke to Andrew Stitcher about the versions in jira.  We think it would 
be simpler overall if jira contained only even-numbered (released) 
versions.  Right now the extra fidelity of having odd- and even-numbered 
versions mostly causes confusion and adds complexity to our queries.


There is a link at the release page[1] that I am using as the canonical 
bugs targeted for 0.10 query.  I still need to update it for the recent 
introduction of 0.10.  I'll let you know when I have; it shouldn't be 
long.


Justin



---
[1] https://cwiki.apache.org/confluence/display/qpid/0.10+release




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




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

Re: 0.10 release update - beta distribution available


On 03/08/2011 09:22 PM, Justin Ross wrote:

Hi.  I've updated the release page[1] with a link to our beta
distribution, taken at revision 107887 from the 0.10 branch:

http://people.apache.org/~gsim/qpid-0.10-beta/

This one also includes the qmf and tools source tarballs, which were
missing from the alpha.

The current patch for the release script is in
https://issues.apache.org/jira/browse/QPID-3124 .


I've tested qpid-cpp-0.10-beta.tar.gz, qpid-python-0.10-beta.tar.gz, 
qpid-java-0.10-beta.tar.gz, qpid-qmf-0.10-beta.tar.gz and 
qpid-tools-0.10-beta.tar.gz so far...


Everything builds/installs/runs ok, with the minor exception of the c++ 
examples. I botched the move for this a little and they still install 
into their original locations. I'll be proposing a patch for review to 
fix this.


The qmf and tools tarballs still have 0.9 in the base directory and 
version field in PKG_INFO.


The examples (python and c++), qpid-perftest, qpid-latencytest, 
qpid-bench (from java) and python utils all run against the c++ broker 
without problems, as do the python tests.


Likewise against the java broker the examples run ok, as do the various 
perf test utilities. The python tests show one or two errors[1] and hang 
on one test[2] (will dig a bit further into those issues). The qmf based 
command line utilities (as expected) work only patchily; qpid-config 
will add and delete ok, but listings don't seem to work accurately (give 
duplicates and miss out available queues).


[1]
qpid.tests.messaging.endpoints.AddressTests.testDeleteSpecial
qpid.tests.messaging.endpoints.SessionTests.testCommitAck
qpid.tests.messaging.endpoints.SessionTests.testDoubleCommit

[2]
qpid.tests.messaging.endpoints.SessionTests.testReject

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

Re: 0.10 release update - beta distribution available


On 03/08/2011 09:22 PM, Justin Ross wrote:

Hi.  I've updated the release page[1] with a link to our beta
distribution, taken at revision 107887 from the 0.10 branch:

http://people.apache.org/~gsim/qpid-0.10-beta/


I'd like to suggest pruning the list of artefacts to those that will be 
tested and have updates.


Specifically I'd suggest that unless anyone has specific updates to the 
following artefacts - and volunteers to verify the artefact for the 
release - we remove them from the published list:


  qpid-dotnet-0-8-0.10-beta.zip
  qpid-dotnet-0-10-0.10-beta.zip
  qpid-ruby-0.10-beta.tar.gz

This will avoid giving false impressions about ongoing maintenance for 
these clients.


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

Re: 0-10 JIRAs

2011-03-10 Thread Emmanuel Bourg


Le 10/03/2011 15:47, Justin Ross a écrit :


I spoke to Andrew Stitcher about the versions in jira. We think it would
be simpler overall if jira contained only even-numbered (released)
versions. Right now the extra fidelity of having odd- and even-numbered
versions mostly causes confusion and adds complexity to our queries.


+1

That would be almost equivalent to dropping the odd/even numbering.

The next step would be to name the development version as next release 
number-dev or -snapshot and Qpid would be just like every other project 
out there ;)


Emmanuel Bourg



smime.p7s
Description: S/MIME Cryptographic Signature

Re: 0-10 JIRAs

I guess that makes sense yes, and should be easily achieved (change all the
0.10 JIRAs to 0.9 fix for, remove 0.10 version, rename 0.9 to 0.10, rename
0.11 to 0.12).

Does everyone agree that is the way to go?

Robbie

On 10 March 2011 14:47, Justin Ross jr...@redhat.com wrote:

 On Thu, 10 Mar 2011, Gordon Sim wrote:

  On 03/10/2011 01:50 PM, Marnie McCormack wrote:

 Hi Justin/All,

 I'm wondering what the approach for identifying the content of the 0-10
 release from JIRA is ?

 I've just been trying to figure out what is actually in 0-10 from JIRA
 and
 its not easy since we have 0-10 items complete adn I think raised during
 the
 release process and a load of open 0-9 items for which we can't tell the
 target release.

 We should be able to generate release notes from JIRA, so should we
 update
 all items in the 0-10 release to have a fix for version of 0-10 ?


 I marked the JIRAs I fixed for 0.10 as fix-for 0.9 (the 0.10 option was
 only recently added). So I believe anything that is resolved and has fix-for
 0.9[1] can have the fix-for updated to 0-10. Anyone know if there is a way
 to do this as a bulk update or similar?

 [1]
 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310520version=12315382


 I spoke to Andrew Stitcher about the versions in jira.  We think it would
 be simpler overall if jira contained only even-numbered (released) versions.
  Right now the extra fidelity of having odd- and even-numbered versions
 mostly causes confusion and adds complexity to our queries.

 There is a link at the release page[1] that I am using as the canonical
 bugs targeted for 0.10 query.  I still need to update it for the recent
 introduction of 0.10.  I'll let you know when I have; it shouldn't be long.

 Justin



 ---
 [1] https://cwiki.apache.org/confluence/display/qpid/0.10+release




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



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

Re: 0-10 JIRAs


On Thu, 10 Mar 2011, Justin Ross wrote:


On Thu, 10 Mar 2011, Gordon Sim wrote:


On 03/10/2011 01:50 PM, Marnie McCormack wrote:

Hi Justin/All,

I'm wondering what the approach for identifying the content of the 0-10
release from JIRA is ?

I've just been trying to figure out what is actually in 0-10 from JIRA and
its not easy since we have 0-10 items complete adn I think raised during 
the

release process and a load of open 0-9 items for which we can't tell the
target release.

We should be able to generate release notes from JIRA, so should we update
all items in the 0-10 release to have a fix for version of 0-10 ?


I marked the JIRAs I fixed for 0.10 as fix-for 0.9 (the 0.10 option was 
only recently added). So I believe anything that is resolved and has 
fix-for 0.9[1] can have the fix-for updated to 0-10. Anyone know if there 
is a way to do this as a bulk update or similar?


[1] 
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310520version=12315382


I spoke to Andrew Stitcher about the versions in jira.  We think it would be 
simpler overall if jira contained only even-numbered (released) versions. 
Right now the extra fidelity of having odd- and even-numbered versions mostly 
causes confusion and adds complexity to our queries.


(By the way, I meant the above to be a question about how we do this in 
the future, not something needs to change pronto.)


There is a link at the release page[1] that I am using as the canonical 
bugs targeted for 0.10 query.  I still need to update it for the 
recent introduction of 0.10.  I'll let you know when I have; it 
shouldn't be long.


I've updated the bug link on the release page:

  http://bit.ly/fkZAta

I'd be interested to get comments about the criteria I'm using at the top. 
It doesn't look strictly at fixVersion.  It also pulls in bugs with a 
null fixVersion and an affectsVersion of 0.9 or 0.10.


So far, until we decide to do some bulk updating, I've been planning to 
include both 0.9 and 0.10 bugs in the targeted for 0.10 bucket.


Justin

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

Re: 0-10 JIRAs


Yeah, if folks want to press ahead, I'm for it.

On Thu, 10 Mar 2011, Robbie Gemmell wrote:


I guess that makes sense yes, and should be easily achieved (change all the
0.10 JIRAs to 0.9 fix for, remove 0.10 version, rename 0.9 to 0.10, rename
0.11 to 0.12).

Does everyone agree that is the way to go?

Robbie

On 10 March 2011 14:47, Justin Ross jr...@redhat.com wrote:


On Thu, 10 Mar 2011, Gordon Sim wrote:

 On 03/10/2011 01:50 PM, Marnie McCormack wrote:



Hi Justin/All,

I'm wondering what the approach for identifying the content of the 0-10
release from JIRA is ?

I've just been trying to figure out what is actually in 0-10 from JIRA
and
its not easy since we have 0-10 items complete adn I think raised during
the
release process and a load of open 0-9 items for which we can't tell the
target release.

We should be able to generate release notes from JIRA, so should we
update
all items in the 0-10 release to have a fix for version of 0-10 ?



I marked the JIRAs I fixed for 0.10 as fix-for 0.9 (the 0.10 option was
only recently added). So I believe anything that is resolved and has fix-for
0.9[1] can have the fix-for updated to 0-10. Anyone know if there is a way
to do this as a bulk update or similar?

[1]
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310520version=12315382



I spoke to Andrew Stitcher about the versions in jira.  We think it would
be simpler overall if jira contained only even-numbered (released) versions.
 Right now the extra fidelity of having odd- and even-numbered versions
mostly causes confusion and adds complexity to our queries.

There is a link at the release page[1] that I am using as the canonical
bugs targeted for 0.10 query.  I still need to update it for the recent
introduction of 0.10.  I'll let you know when I have; it shouldn't be long.

Justin



---
[1] https://cwiki.apache.org/confluence/display/qpid/0.10+release





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




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






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

Re: session.createQueue does not create durable queues

Danushka,

I don't think session.createQueue should create durable queues.
At least there is no requirement like that specified in the JMS spec.

If the 0.6 release creates durable queues then I think it should be a bug,
but I haven't really noticed anything like that before.
For the upcoming 0.10 release (and of course trunk) you can create a durable
queue using session.createQueue if you specify the correct option in the
address string.

Ex. The following address string will create my-queue and mark it durable.
my-queue; {create: always , node : {durable:true}}

Refer to the programming guide on the website for a complete description of
the addressing syntax.

Regards,

Rajith

On Thu, Mar 10, 2011 at 5:38 AM, Danushka Menikkumbura 
danushka.menikkumb...@gmail.com wrote:

 Hi,

 I see that the queues created using session.createQueue are not durable in
 the trunk version that I am using as opposed to it creates durable queues
 in
 0.6 release. I think this particular JMS call should create durable queues.

 Furthermore the trunk version that I use creates durable queues when I use
 JNDI.

 Thanks,
 Danushka

 --
 Danushka Menikkumbura
 Apache Axis2 PMC Member

 Apache Qpid - World Domination through Advanced Message Queueing ;
 http://qpid.apache.org

 phone : +94 77 364 1754
 personal blog : http://danushka-menikkumbura.blogspot.com/
 http://danushka-menikkumbura.blogspot.com/technical blog :
 http://danushkastechythoughts.blogspot.com/
  http://danushkastechythoughts.blogspot.com/twitter :
 http://twitter.com/danushkamenik
 http://twitter.com/danushkameniklinkedin :
 http://lk.linkedin.com/in/danushka

Re: 0-10 JIRAs


On Thu, 10 Mar 2011, Emmanuel Bourg wrote:


Le 10/03/2011 15:47, Justin Ross a écrit :


I spoke to Andrew Stitcher about the versions in jira. We think it would
be simpler overall if jira contained only even-numbered (released)
versions. Right now the extra fidelity of having odd- and even-numbered
versions mostly causes confusion and adds complexity to our queries.


+1

That would be almost equivalent to dropping the odd/even numbering.

The next step would be to name the development version as next release 
number-dev or -snapshot and Qpid would be just like every other project out 
there ;)


Emmanuel Bourg


I'm not particularly for or against the odd/even version numbering.  But 
to be fair, it's not an uncommon scheme, and it isn't a source of any 
frustration for me.  *shrug*


Justin

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

Re: 0-10 JIRAs

No time like the present; just prior to release is probably the easiest time
to do this :)

On 10 March 2011 15:10, Justin Ross jr...@redhat.com wrote:

 snip
 (By the way, I meant the above to be a question about how we do this in the
 future, not something needs to change pronto.)
 snip

Re: session.createQueue does not create durable queues

Creating (non-temporary) durable queues has always been the default afaik,
and given that the default delivery mode for the messages themselves is
persistent that probably makes some amount of sense. Such a change wont have
been caught by the tests since the profiles all still default to the old
syntax..

The JMS API wont cover this because it doesn't really cover queue creation,
except to say that it doesn't :)

Robbie

On 10 March 2011 15:16, Rajith Attapattu rajit...@gmail.com wrote:

 Danushka,

 I don't think session.createQueue should create durable queues.
 At least there is no requirement like that specified in the JMS spec.

 If the 0.6 release creates durable queues then I think it should be a bug,
 but I haven't really noticed anything like that before.
 For the upcoming 0.10 release (and of course trunk) you can create a
 durable
 queue using session.createQueue if you specify the correct option in the
 address string.

 Ex. The following address string will create my-queue and mark it durable.
my-queue; {create: always , node : {durable:true}}

 Refer to the programming guide on the website for a complete description of
 the addressing syntax.

 Regards,

 Rajith

 On Thu, Mar 10, 2011 at 5:38 AM, Danushka Menikkumbura 
 danushka.menikkumb...@gmail.com wrote:

  Hi,
 
  I see that the queues created using session.createQueue are not durable
 in
  the trunk version that I am using as opposed to it creates durable queues
  in
  0.6 release. I think this particular JMS call should create durable
 queues.
 
  Furthermore the trunk version that I use creates durable queues when I
 use
  JNDI.
 
  Thanks,
  Danushka
 
  --
  Danushka Menikkumbura
  Apache Axis2 PMC Member
 
  Apache Qpid - World Domination through Advanced Message Queueing ;
  http://qpid.apache.org
 
  phone : +94 77 364 1754
  personal blog : http://danushka-menikkumbura.blogspot.com/
  http://danushka-menikkumbura.blogspot.com/technical blog :
  http://danushkastechythoughts.blogspot.com/
   http://danushkastechythoughts.blogspot.com/twitter :
  http://twitter.com/danushkamenik
  http://twitter.com/danushkameniklinkedin :
  http://lk.linkedin.com/in/danushka

Re: 0-10 JIRAs


On 03/10/2011 03:14 PM, Justin Ross wrote:

Yeah, if folks want to press ahead, I'm for it.


Me too.

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

Re: session.createQueue does not create durable queues

On Thu, Mar 10, 2011 at 10:31 AM, Robbie Gemmell
robbie.gemm...@gmail.comwrote:

 Creating (non-temporary) durable queues has always been the default afaik,


If Qpid created durable queues by default then I think that is something we
need to explicitly document, since it's different from what the API doc
states.

From the JMS API doc, it's quite clear that we are not exactly compliant. So
the existing behaviour (and the current behaviour) is not really correct.
Note that this method is not for creating the physical queue. The physical
creation of queues is an administrative task and is not to be initiated by
the JMS API.

It prohibits creation of the physical queue, let alone making it durable.

I was initially going to mark all queues created (with just a name) as
create: never so we are compliant with the spec.
(Anybody who wants to override this could do so with explicitly specifying
create:sender/receiver/always as appropriate.)
However existing applications would have failed since it's dependent on the
queue being created by the Qpid client, all though that is clearly the wrong
behaviour.

An unsuspecting user may be caught off guard as the JMS spec doesn't mention
anything of the sort.
Durable queues has an impact on performance and I am not sure it's a smart
idea to make that the default.

If a user wants durability then I believe it should be explicitly signalled.
So I am not happy durability being the default.


 and given that the default delivery mode for the messages themselves is
 persistent that probably makes some amount of sense.


I think that was probably done as a precaution more than anything.
So any message that ends up in a durable queue will be persisted unless the
user explicitly says not to.

Hope this helps.

Regards,

Rajith.


 Such a change wont have
 been caught by the tests since the profiles all still default to the old
 syntax..

 The JMS API wont cover this because it doesn't really cover queue creation,
 except to say that it doesn't :)


Well if it was intended that way I am sure at least there would be some
mention in the JMS specification doc.



 Robbie

 On 10 March 2011 15:16, Rajith Attapattu rajit...@gmail.com wrote:

  Danushka,
 
  I don't think session.createQueue should create durable queues.
  At least there is no requirement like that specified in the JMS spec.
 
  If the 0.6 release creates durable queues then I think it should be a
 bug,
  but I haven't really noticed anything like that before.
  For the upcoming 0.10 release (and of course trunk) you can create a
  durable
  queue using session.createQueue if you specify the correct option in the
  address string.
 
  Ex. The following address string will create my-queue and mark it
 durable.
 my-queue; {create: always , node : {durable:true}}
 
  Refer to the programming guide on the website for a complete description
 of
  the addressing syntax.
 
  Regards,
 
  Rajith
 
  On Thu, Mar 10, 2011 at 5:38 AM, Danushka Menikkumbura 
  danushka.menikkumb...@gmail.com wrote:
 
   Hi,
  
   I see that the queues created using session.createQueue are not durable
  in
   the trunk version that I am using as opposed to it creates durable
 queues
   in
   0.6 release. I think this particular JMS call should create durable
  queues.
  
   Furthermore the trunk version that I use creates durable queues when I
  use
   JNDI.
  
   Thanks,
   Danushka
  
   --
   Danushka Menikkumbura
   Apache Axis2 PMC Member
  
   Apache Qpid - World Domination through Advanced Message Queueing ;
   http://qpid.apache.org
  
   phone : +94 77 364 1754
   personal blog : http://danushka-menikkumbura.blogspot.com/
   http://danushka-menikkumbura.blogspot.com/technical blog :
   http://danushkastechythoughts.blogspot.com/
http://danushkastechythoughts.blogspot.com/twitter :
   http://twitter.com/danushkamenik
   http://twitter.com/danushkameniklinkedin :
   http://lk.linkedin.com/in/danushka

[jira] Created: (QPID-3136) Add option to disable defaults for queue threshold alerts

Add option to disable defaults for queue threshold alerts
-

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


By default any queue with a limit set will generate threshold events at 80% of 
that limit. This is designed to be simple for out-of-the-box use, but is not 
always desirable (and is a change in behaviour) and so would be nice to be able 
to turn off.

The proposal is to add a broker level option to control the ratio used for 
determining an alert threshold from a queue limit. If set to 0 this would 
disable threshold events by default.

--
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: 0-10 JIRAs

2011-03-10 Thread Marnie McCormack

I think we'd need to have a vote thread to redo the versioning approac -
which is effectively what this implies if I'v eunderstood correctly ?

I don't like the scheme we've got but iirc it was discussed at length and
voted in.

However, the harder task to do which involves (at least this is how I've
done it in the past) looking for subversion commits on all open/in-flight
0-9 items to figure out what actually made it into the 0-10 release
(regardless of status on JIRA since it's not a reliable guide for commit).

Is there a smarter way to be sure about content ?

Marnie

On Thu, Mar 10, 2011 at 4:00 PM, Rajith Attapattu rajit...@gmail.comwrote:

 +1

 On Thu, Mar 10, 2011 at 10:34 AM, Gordon Sim g...@redhat.com wrote:

  On 03/10/2011 03:14 PM, Justin Ross wrote:
 
  Yeah, if folks want to press ahead, I'm for it.
 
 
  Me too.
 
 
  -
  Apache Qpid - AMQP Messaging Implementation
  Project:  http://qpid.apache.org
  Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] Updated: (QPID-2643) trunk build failed under VS10 x64.


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

Gordon Sim updated QPID-2643:
-

Fix Version/s: (was: 0.9)
   Future

 trunk build failed  under VS10 x64.
 ---

 Key: QPID-2643
 URL: https://issues.apache.org/jira/browse/QPID-2643
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.7
 Environment: visual studio 2010 c++ express
Reporter: Jinius
Assignee: Chuck Rolke
Priority: Minor
  Labels: vs10, win64
 Fix For: Future


 nmake compile failed at 
 C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\iterator(142) 
 : error C2039: 'value_type' : is not a memb
 er of 'qpid::framing::List'
 C:\A.svn_qpid\cpp\include\qpid/framing/List.h(40) : see declaration 
 of 'qpid::framing::List'
 C:\A.svn_qpid\cpp\src\qpid\amqp_0_10\Codecs.cpp(51) : see reference 
 to class template instantiation 'std::insert
 _iterator_Container' being compiled
 with
 [
 _Container=qpid::framing::List
 ]
 C:\svn_qpid\cpp\src\qpid\amqp_0_10\Codecs.cpp(83) : see reference to 
 function template instantiation 'void qpi
 d::amqp_0_10::convertqpid::types::Variant::List,qpid::framing::List,boost::shared_ptrT(__cdecl
  *)(const qpid::types::
 Variant )(const std::list_Ty ,U ,F)' being compiled
 with
 [
 T=qpid::framing::FieldValue,
 _Ty=qpid::types::Variant,
 U=qpid::framing::List,
 F=boost::shared_ptrqpid::framing::FieldValue (__cdecl *)(const 
 qpid::types::Variant )
 ]
 C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\iterator(149) 
 : error C2182: '_Val' : illegal use of type
  'void'
 C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE\iterator(156) 
 : error C2182: '_Val' : illegal use of type
  'void'
 NMAKE : fatal error U1077: 'C:\PROGRA~2\MICROS~1.0\VC\bin\cl.exe' : return 
 code '0x2'
 Stop.
 NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio 
 10.0\VC\BIN\nmake.exe' : return code '0x2'
 Stop.
 NMAKE : fatal error U1077: 'C:\Program Files (x86)\Microsoft Visual Studio 
 10.0\VC\BIN\nmake.exe' : return code '0x2'

--
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-2955) Use QPID_TSS consistently


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

Gordon Sim updated QPID-2955:
-

Fix Version/s: (was: 0.9)
   0.10

 Use QPID_TSS consistently
 -

 Key: QPID-2955
 URL: https://issues.apache.org/jira/browse/QPID-2955
 Project: Qpid
  Issue Type: Improvement
  Components: C++ Broker
Affects Versions: 0.7, 0.8
Reporter: Sorin Suciu
Assignee: Sorin Suciu
Priority: Minor
 Fix For: 0.10

 Attachments: qpid_2955.patch


  QPID_TSS define is not currently used consistently across the broker code, 
 sometimes the __thread is used directly.

--
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-1860) Python verify file cannot contain comments


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

Gordon Sim resolved QPID-1860.
--

Resolution: Won't Fix

 Python verify file cannot contain comments
 --

 Key: QPID-1860
 URL: https://issues.apache.org/jira/browse/QPID-1860
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker, Python Test Suite
Affects Versions: M4
Reporter: Martin Ritchie
Assignee: Martin Ritchie
 Fix For: 0.5


 Summary:
 The cpp 'make check' target runs the python examples and verifies that the 
 'verify.in' file contains the same output from the run of the example.
 However, these files are not automatically generated and so need ASL license 
 headers.
 Approach:
 Simplest thing to do seems to be to add a comment format to the file. The cpp 
 verify script just needs to be updated to remove the comment before 
 performing the diff.
 From what I can see this cpp verify script is the only script that uses this 
 file so changing the format should not be a problem.

--
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] Closed: (QPID-1198) Changes for the solaris port


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

Gordon Sim closed QPID-1198.


Resolution: Incomplete

Partially addressed by series of patches. Raise new Jiras for anything still an 
issue.

 Changes for the solaris port
 

 Key: QPID-1198
 URL: https://issues.apache.org/jira/browse/QPID-1198
 Project: Qpid
  Issue Type: New Feature
  Components: C++ Broker
Affects Versions: M4
Reporter: Manuel Teira
Assignee: Andrew Stitcher
 Fix For: 0.5

 Attachments: acl.patch, ecfpoller-refactoring.patch, 
 localaddrs.patch, solaris-port.patch, syslog-feature-test.patch


 Patch with changes needed to have the project compiling under Sun Studio 12, 
 on a Solaris Sparc machine. Tests are also passing.
 This patch summarizes all the changes in my local copy, including those from 
 the non-resolved jira issues: QPID-1132 and QPID-1133. 
 Other changes are:
 1.- Missing include files
 2.- Some GNUishms in system calls. I think there're two cases for this:
2.1.- POSIX strerror_r doesn't return the buffer.
2.2. - pthread_yield is not POSIX compliant. Using sched_yield instead.
 3.- No FTP and LOG_FTP syslog categories on Solaris.
 4.- The private inheritance bug in the solaris compiler
 5.- The Uuid.h solaris non-const members. 
 6.- Some explicit namespacing. In some parts of the code.
 7.- Replace all the u_intN_t typenames with  uintN_t typenames.
 8.- The queue issue. Name already used in solaris system headers.
 9.-Some minor bashisms in scripts, complaining under pure sh shells.

--
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-2955) Use QPID_TSS consistently


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

Gordon Sim updated QPID-2955:
-

Fix Version/s: (was: 0.10)
   Future

 Use QPID_TSS consistently
 -

 Key: QPID-2955
 URL: https://issues.apache.org/jira/browse/QPID-2955
 Project: Qpid
  Issue Type: Improvement
  Components: C++ Broker
Affects Versions: 0.7, 0.8
Reporter: Sorin Suciu
Assignee: Sorin Suciu
Priority: Minor
 Fix For: Future

 Attachments: qpid_2955.patch


  QPID_TSS define is not currently used consistently across the broker code, 
 sometimes the __thread is used directly.

--
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-3009) Perl binding to Qpid messaging

2011-03-10 Thread Ted Ross (JIRA)


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

Ted Ross resolved QPID-3009.


   Resolution: Fixed
Fix Version/s: (was: 0.9)
   0.10

 Perl binding to Qpid messaging
 --

 Key: QPID-3009
 URL: https://issues.apache.org/jira/browse/QPID-3009
 Project: Qpid
  Issue Type: New Feature
  Components: C++ Client
Affects Versions: 0.8
 Environment: -
Reporter: Hao Chang Yu
Assignee: Ted Ross
 Fix For: 0.10

 Attachments: QPID-3009.diff, qpid_perl.patch


 As we need to use perl programs to send amqp messages but there is no perl 
 version of qpid messaging.
 Therefore, I had written a perl api to bind with c++ qpid messaging library.  
 This perl api for qpid messaging is developed using swig and is base on qpid 
 0.8.
 Please see the attached patch file.

--
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: 0-10 JIRAs


On 03/10/2011 04:56 PM, Marnie McCormack wrote:

I think we'd need to have a vote thread to redo the versioning approac -
which is effectively what this implies if I'v eunderstood correctly ?

I don't like the scheme we've got but iirc it was discussed at length and
voted in.

However, the harder task to do which involves (at least this is how I've
done it in the past) looking for subversion commits on all open/in-flight
0-9 items to figure out what actually made it into the 0-10 release
(regardless of status on JIRA since it's not a reliable guide for commit).


On the c++ side I believe the status is now a reasonable guide.


Is there a smarter way to be sure about content ?

Marnie

On Thu, Mar 10, 2011 at 4:00 PM, Rajith Attapatturajit...@gmail.comwrote:


+1

On Thu, Mar 10, 2011 at 10:34 AM, Gordon Simg...@redhat.com  wrote:


On 03/10/2011 03:14 PM, Justin Ross wrote:


Yeah, if folks want to press ahead, I'm for it.



Me too.


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









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

[jira] Updated: (QPID-2396) Add assignment operator methods for objects with impl pointers

2011-03-10 Thread Ken Giusti (JIRA)


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

Ken Giusti updated QPID-2396:
-

Fix Version/s: (was: 0.9)
   Future

 Add assignment operator methods for objects with impl pointers
 

 Key: QPID-2396
 URL: https://issues.apache.org/jira/browse/QPID-2396
 Project: Qpid
  Issue Type: Bug
  Components: Qpid Managment Framework
Affects Versions: 0.7
Reporter: Ken Giusti
Assignee: Ken Giusti
 Fix For: Future


 class ObjectId has an private impl pointer.  When used as an argument to an 
 assignment, the impl pointer is incorrectly set by the default memberwise 
 assignment method.  This causes two ObjectIds to incorrectly share the same 
 impl instance.   This may be the case for other objects that use this impl 
 pattern - the code should be audited.

--
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-3137) old examples are installed incorrectly

old examples are installed incorrectly
--

 Key: QPID-3137
 URL: https://issues.apache.org/jira/browse/QPID-3137
 Project: Qpid
  Issue Type: Bug
Affects Versions: 0.9
Reporter: Gordon Sim
Assignee: Gordon Sim
 Fix For: 0.10


Should be installed into an old_api directory, but are installed into the top 
level examples directory (and the top level makefile therefore does not work 
correctly).

--
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-2057) qpidd --require-encryption forces SASL security layer to be used even if SSL is in use

2011-03-10 Thread michael j. goulish (JIRA)


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

michael j. goulish updated QPID-2057:
-

Fix Version/s: 0.11

 qpidd --require-encryption forces SASL security layer to be used even if SSL 
 is in use
 --

 Key: QPID-2057
 URL: https://issues.apache.org/jira/browse/QPID-2057
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.5
Reporter: Ted Ross
Assignee: michael j. goulish
Priority: Minor
 Fix For: 0.11


 If running SSL and using GSSAPI authentication with the --require-encryption 
 option turned on, the SASL layer will force minSsf to be greater than zero, 
 thus causing the SASL security layer to encrypt.
 This is unnecessary double-encryption since SSL is already providing a cipher 
 channel at a lower layer.

--
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-2993) Federated source-local links crash remotely federated cluster member on local cluster startup

2011-03-10 Thread michael j. goulish (JIRA)

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

michael j. goulish updated QPID-2993:
-

Fix Version/s: 0.11

Federated source-local links crash remotely federated cluster member on local
cluster startup
-

Key: QPID-2993
URL: https://issues.apache.org/jira/browse/QPID-2993
Project: Qpid
Issue Type: Bug
Components: C++ Broker, C++ Clustering
Affects Versions: 0.8
Environment: Debian Linux Squeeze, 32-bit, kernel 2.6.36.2, Dell
Poweredge 1950s. Corosync==1.3.0, Openais==1.1.4
Reporter: Mark Moseley
Assignee: michael j. goulish
Fix For: 0.11

Attachments: 2993_bug.sh, cluster-fed-src.sh

This is related to JIRA 2992 that I opened, but this is for source-local
routes. Given the same setup as in JIRA 2992 but using source-local routes
(and obviously with the exchanges switched accordingly in the qpid-route
statements), i.e. cluster A and cluster B with the routes between A1-B1,
when cluster B shuts down in the order B2-B1 and starts back up, the static
routes are not correctly re-bound on cluster A's side. However if cluster B
is shut down in the order B1-B2 and started back up, the route is correctly
created and works. However in the non-functioning case (B2-B1, or A2-A1),
there is an additional side-effect: on node A2, qpidd crashes with the
following error (cluster A is called 'walclust', B is bosclust):
2011-01-07 18:57:35 error Channel exception: not-attached: Channel 1 is not
attached (qpid/amqp_0_10/SessionHandler.cpp:39)
2011-01-07 18:57:35 critical cluster(102.0.0.0:13650 READY/error) local error
2030 did not occur on member 101.0.0.0:9920: not-attached: Channel 1 is not
attached (qpid/amqp_0_10/SessionHandler.cpp:39)
2011-01-07 18:57:35 critical Error delivering frames: local error did not
occur on all cluster members : not-attached: Channel 1 is not attached
(qpid/amqp_0_10/SessionHandler.cpp:39) (qpid/cluster/ErrorCheck.cpp:89)
2011-01-07 18:57:35 notice cluster(102.0.0.0:13650 LEFT/error) leaving
cluster walclust
2011-01-07 18:57:35 notice Shut down
This happens on both sides of the cluster, so it's not limited to one or the
other. This crash does *not* occur in the A1-A2/B1-B2 test (i.e. the test
where the route is re-bound correctly). I can cause this to reoccur pretty
much every time. I've been resetting the cluster completely to a new state
between each test. Occasionally in the B2-B1 test, A1 will also crash with
the same error (and vice versa for A2-A1 for node B1), though most of the
time, it's A2/B2 that crashes.
I was getting this same behaviour prior to upgrading corosync/openais as
well. Previously I was using the stock Squeeze versions of corosync==1.2.1
and openais==1.1.2. The results are the same with corosync=1.3.0 and
openais==1.1.4.

--
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-3135) cpp/bld-winsdk.ps1 tries to install non-existant files

2011-03-10 Thread Chuck Rolke (JIRA)


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

Chuck Rolke commented on QPID-3135:
---

Ignore the patch of 10/Mar/11 04:30 - it is misguided. See r1080329 for actual 
solution.

 cpp/bld-winsdk.ps1 tries to install non-existant files
 --

 Key: QPID-3135
 URL: https://issues.apache.org/jira/browse/QPID-3135
 Project: Qpid
  Issue Type: Bug
  Components: Packaging
Affects Versions: 0.9
 Environment: bld-winsdk builds
Reporter: Chuck Rolke
Assignee: Chuck Rolke
 Attachments: QPID-3118_AdjustWinSdkInstallation.patch


 The examples revision in QPID-3067 moved some files and bld-winsdk.ps1 still 
 refers to them in their old directories. This prevents bld-winsdk from 
 building a package correctly. This same problem is in QPID-3118 as it applies 
 to CMakeLists.

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

Request for QPID-3135 in 0.10

2011-03-10 Thread Chuck Rolke

This fix prevents bld-winsdk.ps1 from crashing when it tries to delete
files that not longer exist.

I've tested it against trunk and against the current 0.10 branch.

On approval I will merge it into the 0.10 branch.

Jira: https://issues.apache.org/jira/browse/QPID-3135
Commit: http://svn.apache.org/viewvc?rev=1080329view=rev

-Chuck

If I can't see your mirrors then you can't see me.

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

[jira] Commented: (QPID-3135) cpp/bld-winsdk.ps1 tries to install non-existant files

2011-03-10 Thread Justin Ross (JIRA)


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

Justin Ross commented on QPID-3135:
---

Approved for 0.10.

 cpp/bld-winsdk.ps1 tries to install non-existant files
 --

 Key: QPID-3135
 URL: https://issues.apache.org/jira/browse/QPID-3135
 Project: Qpid
  Issue Type: Bug
  Components: Packaging
Affects Versions: 0.9
 Environment: bld-winsdk builds
Reporter: Chuck Rolke
Assignee: Chuck Rolke
 Attachments: QPID-3118_AdjustWinSdkInstallation.patch


 The examples revision in QPID-3067 moved some files and bld-winsdk.ps1 still 
 refers to them in their old directories. This prevents bld-winsdk from 
 building a package correctly. This same problem is in QPID-3118 as it applies 
 to CMakeLists.

--
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: 0-10 JIRAs


On Thu, 10 Mar 2011, Marnie McCormack wrote:


I think we'd need to have a vote thread to redo the versioning approac -
which is effectively what this implies if I'v eunderstood correctly ?


I don't think they're really coupled.  The model of using only release 
versions (even-numbered versions) in jira is still consistent with the 
odd/even version scheme, imo.



I don't like the scheme we've got but iirc it was discussed at length and
voted in.

However, the harder task to do which involves (at least this is how I've
done it in the past) looking for subversion commits on all open/in-flight
0-9 items to figure out what actually made it into the 0-10 release
(regardless of status on JIRA since it's not a reliable guide for commit).

Is there a smarter way to be sure about content ?


So far, I don't see a smarter way.  I think we'll need to focus our 
attention on making the status reflect reality.


I may, however, be able to work up some queries that make it easier to 
find the gaps.  Perhaps: bugs against 0.10, with associated commits, but 
not yet marked resolved.


Justin


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

Re: session.createQueue does not create durable queues

Forwarding, since Gmail decided I didnt really want to reply to the list :)

-- Forwarded message --
From: Robbie Gemmell
Date: 10 March 2011 21:02

On 10 March 2011 16:00, Rajith Attapattu rajit...@gmail.com wrote:

 On Thu, Mar 10, 2011 at 10:31 AM, Robbie Gemmell robbie.gemm...@gmail.com
  wrote:

 Creating (non-temporary) durable queues has always been the default afaik,

 If Qpid created durable queues by default then I think that is something we
 need to explicitly document, since it's different from what the API doc
 states.

 From the JMS API doc, it's quite clear that we are not exactly compliant.
 So the existing behaviour (and the current behaviour) is not really correct.
 Note that this method is not for creating the physical queue. The physical
 creation of queues is an administrative task and is not to be initiated by
 the JMS API.

 It prohibits creation of the physical queue, let alone making it durable.

I wasn’t suggesting that the session.createQueue call itself created the
queue on the broker, it doesn’t and never has.  It does however create a
Queue object that was previously configured to be durable by default,
resulting in eventual durable queue creation on the broker when the queue
declare gets issued during Consumer creation.

 I was initially going to mark all queues created (with just a name) as
 create: never so we are compliant with the spec.
 (Anybody who wants to override this could do so with explicitly specifying
 create:sender/receiver/always as appropriate.)
 However existing applications would have failed since it's dependent on the
 queue being created by the Qpid client, all though that is clearly the wrong
 behaviour.

 An unsuspecting user may be caught off guard as the JMS spec doesn't
 mention anything of the sort.
 Durable queues has an impact on performance and I am not sure it's a smart
 idea to make that the default.

You reference deciding to continue creating queues by default during
consumer creation in to preserve the existing behaviour for application
compatibility, but in that case I would expect **all** of the existing
default behaviour to be preserved and not just some of it since thats
arguably worse: now applications will continue creating queues as before,
but might lose messages at some point because the queues are not actually
durable like they might previously have been expected to be (see: this email
thread).

 If a user wants durability then I believe it should be explicitly
 signalled. So I am not happy durability being the default.

 and given that the default delivery mode for the messages themselves is
 persistent that probably makes some amount of sense.

 I think that was probably done as a precaution more than anything.
 So any message that ends up in a durable queue will be persisted unless the
 user explicitly says not to.

Exactly, because JMS doesnt really deal with queue durability (other than as
an interpretation of Durable Subscriptions) as a concept at all, it deals
with message persistence and queues just kind of exist or not. As such users
who send persistent messages using a JMS client might reasonably just expect
them to be persisted.

 Hope this helps.

 Regards,

 Rajith.

 Such a change wont have
 been caught by the tests since the profiles all still default to the old
 syntax..

 The JMS API wont cover this because it doesn't really cover queue
 creation,
 except to say that it doesn't :)

 Well if it was intended that way I am sure at least there would be some
 mention in the JMS specification doc.

The section you quoted above is the exact one I was thinking of at the time,
im not sure there is any other way to interpret that really; it isnt going
to say whether they should be durable or not because it explicitly says it
doesnt cover those operations in the first place.

Robbie

 Robbie

 On 10 March 2011 15:16, Rajith Attapattu rajit...@gmail.com wrote:

  Danushka,

  I don't think session.createQueue should create durable queues.
  At least there is no requirement like that specified in the JMS spec.

  If the 0.6 release creates durable queues then I think it should be a
 bug,
  but I haven't really noticed anything like that before.
  For the upcoming 0.10 release (and of course trunk) you can create a
  durable
  queue using session.createQueue if you specify the correct option in the
  address string.

  Ex. The following address string will create my-queue and mark it
 durable.
 my-queue; {create: always , node : {durable:true}}

  Refer to the programming guide on the website for a complete description
 of
  the addressing syntax.

  Regards,

  Rajith

  On Thu, Mar 10, 2011 at 5:38 AM, Danushka Menikkumbura 
  danushka.menikkumb...@gmail.com wrote:

   Hi,

   I see that the queues created using session.createQueue are not
 durable
  in
   the trunk version that I am using as opposed to it creates durable
 queues
   in
   0.6 release. I think this particular

[jira] Resolved: (QPID-3135) cpp/bld-winsdk.ps1 tries to install non-existant files

2011-03-10 Thread Chuck Rolke (JIRA)


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

Chuck Rolke resolved QPID-3135.
---

   Resolution: Fixed
Fix Version/s: 0.10

 cpp/bld-winsdk.ps1 tries to install non-existant files
 --

 Key: QPID-3135
 URL: https://issues.apache.org/jira/browse/QPID-3135
 Project: Qpid
  Issue Type: Bug
  Components: Packaging
Affects Versions: 0.9
 Environment: bld-winsdk builds
Reporter: Chuck Rolke
Assignee: Chuck Rolke
 Fix For: 0.10

 Attachments: QPID-3118_AdjustWinSdkInstallation.patch


 The examples revision in QPID-3067 moved some files and bld-winsdk.ps1 still 
 refers to them in their old directories. This prevents bld-winsdk from 
 building a package correctly. This same problem is in QPID-3118 as it applies 
 to CMakeLists.

--
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: 0-10 JIRAs

2011-03-10 Thread Marnie McCormack

I can't see what the release numbers mean if they don't line up with the
JIRAs - surely it'd be completely impossible to have a release (or
dev) version that didn't appear in JIRA ?

How would that work ?

Thanks,
Marnie

On Thu, Mar 10, 2011 at 9:02 PM, Justin Ross jr...@redhat.com wrote:

 On Thu, 10 Mar 2011, Marnie McCormack wrote:

 I think we'd need to have a vote thread to redo the versioning approac -
 which is effectively what this implies if I'v eunderstood correctly ?


 I don't think they're really coupled.  The model of using only release
 versions (even-numbered versions) in jira is still consistent with the
 odd/even version scheme, imo.


 I don't like the scheme we've got but iirc it was discussed at length and
 voted in.

 However, the harder task to do which involves (at least this is how I've
 done it in the past) looking for subversion commits on all open/in-flight
 0-9 items to figure out what actually made it into the 0-10 release
 (regardless of status on JIRA since it's not a reliable guide for commit).

 Is there a smarter way to be sure about content ?


 So far, I don't see a smarter way.  I think we'll need to focus our
 attention on making the status reflect reality.

 I may, however, be able to work up some queries that make it easier to find
 the gaps.  Perhaps: bugs against 0.10, with associated commits, but not yet
 marked resolved.

 Justin



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

Re: session.createQueue does not create durable queues

On Thu, Mar 10, 2011 at 4:05 PM, Robbie Gemmell robbie.gemm...@gmail.comwrote:

 Forwarding, since Gmail decided I didnt really want to reply to the list :)

 -- Forwarded message --
 From: Robbie Gemmell
 Date: 10 March 2011 21:02

 On 10 March 2011 16:00, Rajith Attapattu rajit...@gmail.com wrote:

  On Thu, Mar 10, 2011 at 10:31 AM, Robbie Gemmell 
 robbie.gemm...@gmail.com
   wrote:

  Creating (non-temporary) durable queues has always been the default
 afaik,

  If Qpid created durable queues by default then I think that is something
 we
  need to explicitly document, since it's different from what the API doc
  states.

  From the JMS API doc, it's quite clear that we are not exactly compliant.
  So the existing behaviour (and the current behaviour) is not really
 correct.
  Note that this method is not for creating the physical queue. The
 physical
  creation of queues is an administrative task and is not to be initiated
 by
  the JMS API.

  It prohibits creation of the physical queue, let alone making it durable.

 I wasn’t suggesting that the session.createQueue call itself created the
 queue on the broker, it doesn’t and never has.

I didn't imply that, as I am well aware that isn't the case.
I was referring to the queue being created when a consumer is created off
that destination (again wrong behaviour).
The only thing that I wasn't aware was that it was durable by default, which
I clearly think is not a smart idea.

 It does however create a
 Queue object that was previously configured to be durable by default,
 resulting in eventual durable queue creation on the broker when the queue
 declare gets issued during Consumer creation.

Exactly and that is clearly the wrong behaviour as per what is described in
the API !
The queue being created as a side affect of creating a consumer is actually
worse.

  I was initially going to mark all queues created (with just a name) as
  create: never so we are compliant with the spec.
  (Anybody who wants to override this could do so with explicitly
 specifying
  create:sender/receiver/always as appropriate.)
  However existing applications would have failed since it's dependent on
 the
  queue being created by the Qpid client, all though that is clearly the
 wrong
  behaviour.

  An unsuspecting user may be caught off guard as the JMS spec doesn't
  mention anything of the sort.
  Durable queues has an impact on performance and I am not sure it's a
 smart
  idea to make that the default.

 You reference deciding to continue creating queues by default during
 consumer creation in to preserve the existing behaviour for application
 compatibility, but in that case I would expect **all** of the existing
 default behaviour to be preserved and not just some of it since thats
 arguably worse: now applications will continue creating queues as before,
 but might lose messages at some point because the queues are not actually
 durable like they might previously have been expected to be (see: this
 email
 thread).

 Again, I wasn't aware that the queues were durable by default.
There was no documentation in the code or otherwise indicating that (if
there is then I apologize for not doing enough research).
I certainly believe durability should be an explicit choice.
I would not want to impose a performance penalty on an unsuspecting user
simply bcos of the way we interpret the JMS spec.

  If a user wants durability then I believe it should be explicitly
  signalled. So I am not happy durability being the default.

  and given that the default delivery mode for the messages themselves is
  persistent that probably makes some amount of sense.

  I think that was probably done as a precaution more than anything.
  So any message that ends up in a durable queue will be persisted unless
 the
  user explicitly says not to.

 Exactly, because JMS doesnt really deal with queue durability (other than
 as
 an interpretation of Durable Subscriptions) as a concept at all, it deals
 with message persistence and queues just kind of exist or not. As such
 users
 who send persistent messages using a JMS client might reasonably just
 expect
 them to be persisted.

I disagree with your interpretation of the JMS spec.
I really don't think many users out there really think that way either.
Most folks are well aware that writing to the disk is expensive, and would
not expect that to be the default behaviour.

  Hope this helps.

  Regards,

  Rajith.

  Such a change wont have
  been caught by the tests since the profiles all still default to the old
  syntax..

  The JMS API wont cover this because it doesn't really cover queue
  creation,
  except to say that it doesn't :)

  Well if it was intended that way I am sure at least there would be some
  mention in the JMS specification doc.

 The section you quoted above is the exact one I was thinking of at the
 time,
 im not sure there is any other way to interpret that really;

Re: Testing

Andrew,

I am quite happy for you to setup a CI build for Qpid on the ASF Hudson
service.
I think  the default profile, java.0.10 and cpp profiles will be an
excellent start and would probably be good enough.

Regards,

Rajith

On Tue, Mar 8, 2011 at 8:44 PM, Andrew Kennedy 
andrewinternatio...@gmail.com wrote:

 Guys,

 I appreciate we are in a rush to get 0.10 ready to ship, however this is no
 excuse for letting testing slide.

 I have seen several instances of changes that have caused multiple
 regressions under various test profiles, and this sort of thing will only
 increase as the number of combinations of profiles increases. Additionally,
 some commits have even prevented the project from compiling. I have done
 both of these things in the past myself, particularly with regards to the
 C++ test profiles, and this is one reason I spent so much time validating
 and testing my network code.

 Can we all please make an effort to run at least the Java 0-8 and 0-10 and
 the C++ profiles before committing changes, to give other developers
 confidence that any new test failures are caused by *their* code, not
 somebody else's?


 One of my colleagues is working on increased unit test coverage via the
 introduction of mock objects, which will reduce our dependency on system
 tests and allow regressions to be found when testing individual components.
 I agree that this is the way forward, as our test coverage is far too low
 currently. However, I could not find out any solid metrics on coverage to
 provide as an example. I notice that although there is a Qpid instance on
 the Nemo server at Sonar (see link below) it does not give coverage metrics,
 although there is a *lot* of useful information there. Does anyone know how
 this could be fixed, or who in the project has access to configure this?

http://nemo.sonarsource.org/dashboard/index/274568

 Additionally, I would be happy to set up and manage a CI build for Qpid on
 the ASF Hudson service. I believe the PMC chair just needs to grant access
 (see first link below) to the correct group. This would allow us to have a
 shared view of build and test statuses (see second link below) and more. I
 know many of us run our own private CI instances, but I think having a
 shared resource everyone in the project can refer to would be very useful.

http://wiki.apache.org/general/Hudson
https://builds.apache.org/hudson/

 I can raise a Qpid JIRA for this to track progress, if people approve of
 the idea?

 Cheers,
 Andrew.
 --
 -- andrew d kennedy ? do not fold, bend, spindle, or mutilate ;
 -- http://grkvlt.blogspot.com/ ? edinburgh : +44 7582 293 255 ;


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

[jira] Created: (QPID-3138) Perf improvement for topic exchange

2011-03-10 Thread Carl Trieloff (JIRA)

Perf improvement for topic exchange
---

 Key: QPID-3138
 URL: https://issues.apache.org/jira/browse/QPID-3138
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.9
Reporter: Carl Trieloff
Priority: Minor



The follow patch introduces a cache for route matches allow the producer to 
return to IO faster allowing for 50% perf gain for the topic exchange.

The cache is cleared on the addition or removal of a binding forcing cache 
re-population.

--
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-3138) Perf improvement for topic exchange

2011-03-10 Thread Carl Trieloff (JIRA)


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

Carl Trieloff resolved QPID-3138.
-

Resolution: Fixed
  Assignee: Carl Trieloff

Committed revision 1080411.

 Perf improvement for topic exchange
 ---

 Key: QPID-3138
 URL: https://issues.apache.org/jira/browse/QPID-3138
 Project: Qpid
  Issue Type: Bug
  Components: C++ Broker
Affects Versions: 0.9
Reporter: Carl Trieloff
Assignee: Carl Trieloff
Priority: Minor

 The follow patch introduces a cache for route matches allow the producer to 
 return to IO faster allowing for 50% perf gain for the topic exchange.
 The cache is cleared on the addition or removal of a binding forcing cache 
 re-population.

--
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: [jira] Created: (QPID-3138) Perf improvement for topic exchange

2011-03-10 Thread Carl Trieloff



Is there interest in having this committed to 0-10, it is low risk, 
large perf gain for topic exchange.



On 03/10/2011 05:53 PM, Carl Trieloff (JIRA) wrote:

Perf improvement for topic exchange
---

  Key: QPID-3138
  URL: https://issues.apache.org/jira/browse/QPID-3138
  Project: Qpid
   Issue Type: Bug
   Components: C++ Broker
 Affects Versions: 0.9
 Reporter: Carl Trieloff
 Priority: Minor



The follow patch introduces a cache for route matches allow the producer to return 
to IO faster allowing for50% perf gain for the topic exchange.

The cache is cleared on the addition or removal of a binding forcing cache 
re-population.

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




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

Re: session.createQueue does not create durable queues

On 10 March 2011 22:15, Rajith Attapattu rajit...@gmail.com wrote:



 On Thu, Mar 10, 2011 at 4:05 PM, Robbie Gemmell 
 robbie.gemm...@gmail.comwrote:

 Forwarding, since Gmail decided I didnt really want to reply to the list
 :)

 -- Forwarded message --
 From: Robbie Gemmell
 Date: 10 March 2011 21:02

 On 10 March 2011 16:00, Rajith Attapattu rajit...@gmail.com wrote:

 
  On Thu, Mar 10, 2011 at 10:31 AM, Robbie Gemmell 
 robbie.gemm...@gmail.com
   wrote:
 
  Creating (non-temporary) durable queues has always been the default
 afaik,
 
 
  If Qpid created durable queues by default then I think that is something
 we
  need to explicitly document, since it's different from what the API doc
  states.
 
  From the JMS API doc, it's quite clear that we are not exactly
 compliant.
  So the existing behaviour (and the current behaviour) is not really
 correct.
  Note that this method is not for creating the physical queue. The
 physical
  creation of queues is an administrative task and is not to be initiated
 by
  the JMS API.
 
  It prohibits creation of the physical queue, let alone making it
 durable.
 
 
 I wasn’t suggesting that the session.createQueue call itself created the
 queue on the broker, it doesn’t and never has.


 I didn't imply that, as I am well aware that isn't the case.



Ok, I took your quoting of the session.createQueue javadoc as a basis of
argument to suggest that you were, my mistake.



 I was referring to the queue being created when a consumer is created off
 that destination (again wrong behaviour).
 The only thing that I wasn't aware was that it was durable by default,
 which I clearly think is not a smart idea.

  It does however create a
 Queue object that was previously configured to be durable by default,
 resulting in eventual durable queue creation on the broker when the queue
 declare gets issued during Consumer creation.


 Exactly and that is clearly the wrong behaviour as per what is described in
 the API !
 The queue being created as a side affect of creating a consumer is actually
 worse.



I am not suggesting that it creating queues duing Consumer construction is
what the API says it should do, as it is pretty clear that it only covers
creation creation of temporary queues, and (in our implementation of topic
subscriptions) creation and removal of the backing queues used for
DurableSubscriptions.

The durability of the queues it is already creating by default is the point
of interest here though, not whether it should actually be creating them.
The JMS API says nothing in this regard as it has no concept of queue
durability (only topic subscription durability, which is not the same thing
although a durable queue is how we implement that), and as we have both
pointed out JMS doesnt cover general queue creation.




  I was initially going to mark all queues created (with just a name) as
  create: never so we are compliant with the spec.
  (Anybody who wants to override this could do so with explicitly
 specifying
  create:sender/receiver/always as appropriate.)
  However existing applications would have failed since it's dependent on
 the
  queue being created by the Qpid client, all though that is clearly the
 wrong
  behaviour.
 
  An unsuspecting user may be caught off guard as the JMS spec doesn't
  mention anything of the sort.
  Durable queues has an impact on performance and I am not sure it's a
 smart
  idea to make that the default.
 

 You reference deciding to continue creating queues by default during
 consumer creation in to preserve the existing behaviour for application
 compatibility, but in that case I would expect **all** of the existing
 default behaviour to be preserved and not just some of it since thats
 arguably worse: now applications will continue creating queues as before,
 but might lose messages at some point because the queues are not actually
 durable like they might previously have been expected to be (see: this
 email
 thread).

 Again, I wasn't aware that the queues were durable by default.
 There was no documentation in the code or otherwise indicating that (if
 there is then I apologize for not doing enough research).
 I certainly believe durability should be an explicit choice.
 I would not want to impose a performance penalty on an unsuspecting user
 simply bcos of the way we interpret the JMS spec.


Message persistence is the only option given to users of the JMS API and is
persistent by default, so I dont see that as being open to interpretation.
The default client behaviour should allow for the delivery mode setting to
actually have an effect. The explicit choice is there to use non persistent.

That the client creates a queue, rightly or wrongly, is somewhat irrelevant
from the users perspective if they ask for persistent delivery and dont get
it because the queue we create isnt durable. That is something I feel could
catch out users who have actually read the JMS API that they are using.
Being able to

Re: Testing