Re: Plan for Proton 0.13.1

I know the changes you're talking about, but are those jiras right? I see one about an osgi bundle (1147) and one about interop with servicebus (1148). https://issues.apache.org/jira/browse/PROTON-1147 https://issues.apache.org/jira/browse/PROTON-1148 On Tue, Jun 28, 2016 at 7:58 AM, Andrew

Re: Service Bus: unreceived messages stay locked (peek-and-lock)

On 29 June 2016 at 11:08, Dale Green wrote: > Hi Robbie, > > Thanks for the hints! I couldn't solve my problems, but let me leave some > more info, which can be useful for other people. > > Closing the consumer explicitly didn't help (it's closed on session close >

Re: Service Bus: unreceived messages stay locked (peek-and-lock)

On 29/06/16 21:50, Robbie Gemmell wrote: On 29 June 2016 at 19:43, Gordon Sim wrote: On 29/06/16 12:39, Robbie Gemmell wrote: On 29 June 2016 at 11:08, Dale Green wrote: Closing the consumer explicitly didn't help (it's closed on session close

Re: default SASL mech in JMS examples (was Re: [VOTE] Release Qpid JMS client 0.10.0)

On 29/06/16 22:19, Robbie Gemmell wrote: As a bit of a tangent, I'm not actually the biggest fan of 'authenticatePeer: no' since it doesnt actually stop the router offering mechnisms that do authentication and then fail when used. Yes, 'requireSasl' might have been a bit more precise. Even if

Re: default SASL mech in JMS examples (was Re: [VOTE] Release Qpid JMS client 0.10.0)

On 29 June 2016 at 19:38, Gordon Sim wrote: > On 29/06/16 16:52, Robbie Gemmell wrote: >> >> I think I misinterpreted your use of "predefined" earlier. I was only >> really considering whether I think it makes sense for a client example >> to use user credentials by default (I

Re: Service Bus: unreceived messages stay locked (peek-and-lock)

On 29 June 2016 at 19:43, Gordon Sim wrote: > On 29/06/16 12:39, Robbie Gemmell wrote: >> >> On 29 June 2016 at 11:08, Dale Green wrote: > >>> >>> >>> Closing the consumer explicitly didn't help (it's closed on session close >>> anyway). >> >> >> I

Re: Service Bus: unreceived messages stay locked (peek-and-lock)

On 29/06/16 12:39, Robbie Gemmell wrote: On 29 June 2016 at 11:08, Dale Green wrote: >> Closing the consumer explicitly didn't help (it's closed on session close anyway). I thought that could be the case, but just wanted you to check in case the server did

Re: default SASL mech in JMS examples (was Re: [VOTE] Release Qpid JMS client 0.10.0)

On 29/06/16 16:52, Robbie Gemmell wrote: I think I misinterpreted your use of "predefined" earlier. I was only really considering whether I think it makes sense for a client example to use user credentials by default (I do, but also like the flexibility of your patch, so will overlook that :P),

Re: default SASL mech in JMS examples (was Re: [VOTE] Release Qpid JMS client 0.10.0)

On 29 June 2016 at 16:18, Gordon Sim wrote: > On 29/06/16 14:26, Robbie Gemmell wrote: >> >> On 29 June 2016 at 14:11, Gordon Sim wrote: >>> >>> On 29/06/16 13:43, Robbie Gemmell wrote: I personally dislike examples using ANONYMOUS, though I can

Re: default SASL mech in JMS examples (was Re: [VOTE] Release Qpid JMS client 0.10.0)

On 29/06/16 14:26, Robbie Gemmell wrote: On 29 June 2016 at 14:11, Gordon Sim wrote: On 29/06/16 13:43, Robbie Gemmell wrote: I personally dislike examples using ANONYMOUS, though I can see the appeal that it avoids particular credentials, and may be easier out the box for

Re: Subject retention in reply-to

On 29/06/16 14:53, William Davidson wrote: I'm trying to use a subject as part of a replyTo but am seeing differing behavior between queues and topics. Using the command-line tools to send and receive a message to the same queue: qpid-send -a myqueue --reply-to

Subject retention in reply-to

I'm trying to use a subject as part of a replyTo but am seeing differing behavior between queues and topics. Using the command-line tools to send and receive a message to the same queue: qpid-send -a myqueue --reply-to "myqueue/mysubject;{node:{type:queue}}" qpid-receive -a myqueue

Re: default SASL mech in JMS examples (was Re: [VOTE] Release Qpid JMS client 0.10.0)

On 29 June 2016 at 14:11, Gordon Sim wrote: > On 29/06/16 13:43, Robbie Gemmell wrote: >> >> I did it that way as a way of showing folks how to do authentication >> when creating the connection from the factory. > > > Which is indeed valuable. > >> I personally dislike >>

Re: default SASL mech in JMS examples (was Re: [VOTE] Release Qpid JMS client 0.10.0)

On 29/06/16 13:43, Robbie Gemmell wrote: I did it that way as a way of showing folks how to do authentication when creating the connection from the factory. Which is indeed valuable. I personally dislike examples using ANONYMOUS, though I can see the appeal that it avoids particular

RE: [Qpid-Dispatch] Dynamic port allocation from the command line

Here it is: https://issues.apache.org/jira/browse/DISPATCH-415 Regards, Adel > Date: Wed, 29 Jun 2016 08:45:58 -0400 > From: gmur...@redhat.com > To: users@qpid.apache.org > Subject: Re: [Qpid-Dispatch] Dynamic port allocation from the command line > > Please add a JIRA for this. Thanks. > >

Re: [VOTE] Release Qpid Java 6.0.4 (RC1)

On 28/06/16 09:06, Keith W wrote: Hi all, A release candidate for the next release (6.0.4) of the Qpid Java Components has been created. The list of changes can be found in Jira: https://issues.apache.org/jira/issues/?jql=project%20%3D%20QPID%20AND%20fixVersion%20%3D%20qpid-java-6.0.4 Please

Re: [Qpid-Dispatch] Dynamic port allocation from the command line

Please add a JIRA for this. Thanks. - Original Message - > From: "Adel Boutros" > To: users@qpid.apache.org > Sent: Wednesday, June 29, 2016 6:42:02 AM > Subject: [Qpid-Dispatch] Dynamic port allocation from the command line > > Hello, > > In Qpid Java Broker, we

Re: default SASL mech in JMS examples (was Re: [VOTE] Release Qpid JMS client 0.10.0)

On 29 June 2016 at 13:36, Gordon Sim wrote: > On 29/06/16 13:30, Robbie Gemmell wrote: >> >> Its usiong guest:guest as those are >> the credentials passed to the connection factory when creating the >> connection. > > > Doh! I should have realised that. Changing the example to

default SASL mech in JMS examples (was Re: [VOTE] Release Qpid JMS client 0.10.0)

On 29/06/16 13:30, Robbie Gemmell wrote: Its usiong guest:guest as those are the credentials passed to the connection factory when creating the connection. Doh! I should have realised that. Changing the example to not specify a user and password resolves the issue. Might that be a better

Re: [VOTE] Release Qpid JMS client 0.10.0

On 29 June 2016 at 13:17, Gordon Sim wrote: > On 27/06/16 17:33, Robbie Gemmell wrote: >> >> Hi folks, >> >> I have put together a spin for a 0.10.0 Qpid JMS client release, please >> test it and vote accordingly. >> >> The source and binary archives can be grabbed from here: >>

[NOTICE] cease commits to cpp and python subdirs of svn trunk, migrating to git

Hi folks, As per previous discussion/votes, the reorganised cpp and python bits will be migrating to their own git repositories. The migration is due to begin in the next hour or two. It isn't clear that the svn subdirs will actually be locked at this time, so please take note to cease

Re: [VOTE] Release Qpid JMS client 0.10.0

On 27/06/16 17:33, Robbie Gemmell wrote: Hi folks, I have put together a spin for a 0.10.0 Qpid JMS client release, please test it and vote accordingly. The source and binary archives can be grabbed from here: https://dist.apache.org/repos/dist/dev/qpid/jms/0.10.0-rc1/ Those files and the

Re: Service Bus: unreceived messages stay locked (peek-and-lock)

On 29 June 2016 at 11:08, Dale Green wrote: > Hi Robbie, > > Thanks for the hints! I couldn't solve my problems, but let me leave some > more info, which can be useful for other people. > > Closing the consumer explicitly didn't help (it's closed on session close >

[Qpid-Dispatch] Dynamic port allocation from the command line

Hello, In Qpid Java Broker, we can set any port dynamically in the config.json file by using properties and setting them on the command line. Is there something similar for the dispatcher? config.json { "id" : "17c2023e-1a46-4791-8a2b-cdcb3aa1e23b", "name" : "AMQP", "port" :

Re: Service Bus: unreceived messages stay locked (peek-and-lock)

Hi Robbie, Thanks for the hints! I couldn't solve my problems, but let me leave some more info, which can be useful for other people. Closing the consumer explicitly didn't help (it's closed on session close anyway). However, I have the feeling that the lifetime of the consumer does not affect

Re: [VOTE] Release Qpid Java 6.0.4 (RC1)

+1 ... I focused mainly on testing the 0-10 client against Qpid C++ broker & briefly tested also the Java broker. On Tue, Jun 28, 2016 at 10:06 AM, Keith W wrote: > Hi all, > > A release candidate for the next release (6.0.4) of the Qpid Java > Components has been created.