Re: [VOTE] Release Qpid Dispatch Router 0.6.1

[Chuck Rolke]

+1

- Original Message -
> From: "Ted Ross" 
> To: users@qpid.apache.org
> Sent: Tuesday, August 2, 2016 9:17:20 AM
> Subject: [VOTE] Release Qpid Dispatch Router 0.6.1
> 
> This is the vote thread for Qpid Dispatch Router 0.6.1 (RC1).  Please
> test and vote:
> 
>  https://dist.apache.org/repos/dist/dev/qpid/dispatch/0.6.1-rc1/
> 
> Changes since 0.6.0:
> 
> DISPATCH-341 - router did not respond to request to drain a message-
> routed consumers link credit
> DISPATCH-364 - Inter-router listeners should not permit normal endpoint
> traffic
> DISPATCH-365 - Standalone router crashes if an interior router attempts
> to connect to it
> DISPATCH-366 - When delivery fails the router sends the RELEASED
> disposition, not MODIFIED
> DISPATCH-367 - balanced distribution needs to be more... balanced.
> DISPATCH-387 - Router core dumps with misbehaving client
> DISPATCH-410 - console build fixups
> DISPATCH-443 - Reverse name lookup on listener connections can hang the
> entire router
> DISPATCH-460 - Regression: Link-routed dynamic sources don't work
> 
> Thanks,
> 
> -Ted
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
> 
> 

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Dispatch: Default value of authenticatePeer

[Gordon Sim]

On 03/08/16 18:23, Robbie Gemmell wrote:

On 3 August 2016 at 18:08, Gordon Sim  wrote:

I think this is different from proton's behaviour (and from qpidd's) where
the similar flags are false by default. (This is a distinct concern from the
default sasl mechanisms enabled).




Without looking at any code to actually know for sure, my thinking
from previous discussion was that it stems from the proton-c transport
'requireAuthentication' style config, which defaults false as you say
thus allowing either SASL or non-SASL connections by default, and so
by not setting the authenticatePeer setting in Dispatch config
proton's related transport config also remains false and continues to
allow the non-SASL connections, with the saslMechanisms config only
controlling which mechs any SASL connections can use.


You could be right, I was actually thinking of the client side in proton 
(proton is a lot of different things!). The python reactor client has a 
sasl_enabled option which controls whether or not a sasl layer is used 
and that is on by default. However that is only for establishing 
connections, and doesn't cover accepting them.


I would agree that the routers authenticatePeer option should be true by 
default.



-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Dispatch: Default value of authenticatePeer

[Robbie Gemmell]

On 3 August 2016 at 18:08, Gordon Sim  wrote:
> On 03/08/16 17:54, Robbie Gemmell wrote:
>>
>> On 3 August 2016 at 17:37, Jakub Scholz  wrote:
>>>
>>> Hi,
>>>
>>> When I have listener configured like this:
>>>
>>> listener {
>>> role: normal
>>> host: 0.0.0.0
>>> port: amqp
>>> saslMechanisms: PLAIN DIGEST-MD5 CRAM-MD5
>>> linkCapacity: 1000
>>> }
>>>
>>> Is it really expected that it allows anonymous access? It seems that
>>> unless
>>> I add to the listener configuration also "authenticatePeer: yes", it will
>>> always allow anonymous access to clients which don't trigger the SASL
>>> layer.
>>>
>>> This seems to me as something quite counter-intuitive and dangerous,
>>> because on a first look someone (like me for example :-o) might expect
>>> that
>>> this configuration allows only username/password authenticated access.
>>>
>>> Wouldn't it make more sense to have anonymous access disabled by default?
>>> At least when SASL layer is configured for given listener? Or is it just
>>> me
>>> who finds this confusing?
>>>
>>> Regards
>>> Jakub
>>
>>
>> From previous discussion (mainly around Proton where some of the
>> underlying behaviour originates) I believe it is actually expected
>> behaviour, but like you I don't think it is very intuitive, and would
>> again suggest we change it.
>
>
> I think this is different from proton's behaviour (and from qpidd's) where
> the similar flags are false by default. (This is a distinct concern from the
> default sasl mechanisms enabled).
>
>

Without looking at any code to actually know for sure, my thinking
from previous discussion was that it stems from the proton-c transport
'requireAuthentication' style config, which defaults false as you say
thus allowing either SASL or non-SASL connections by default, and so
by not setting the authenticatePeer setting in Dispatch config
proton's related transport config also remains false and continues to
allow the non-SASL connections, with the saslMechanisms config only
controlling which mechs any SASL connections can use.

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Dispatch: Default value of authenticatePeer

[Gordon Sim]

On 03/08/16 17:54, Robbie Gemmell wrote:

On 3 August 2016 at 17:37, Jakub Scholz  wrote:

Hi,

When I have listener configured like this:

listener {
role: normal
host: 0.0.0.0
port: amqp
saslMechanisms: PLAIN DIGEST-MD5 CRAM-MD5
linkCapacity: 1000
}

Is it really expected that it allows anonymous access? It seems that unless
I add to the listener configuration also "authenticatePeer: yes", it will
always allow anonymous access to clients which don't trigger the SASL
layer.

This seems to me as something quite counter-intuitive and dangerous,
because on a first look someone (like me for example :-o) might expect that
this configuration allows only username/password authenticated access.

Wouldn't it make more sense to have anonymous access disabled by default?
At least when SASL layer is configured for given listener? Or is it just me
who finds this confusing?

Regards
Jakub


From previous discussion (mainly around Proton where some of the
underlying behaviour originates) I believe it is actually expected
behaviour, but like you I don't think it is very intuitive, and would
again suggest we change it.


I think this is different from proton's behaviour (and from qpidd's) 
where the similar flags are false by default. (This is a distinct 
concern from the default sasl mechanisms enabled).



-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Dispatch: Default value of authenticatePeer

[Robbie Gemmell]

On 3 August 2016 at 17:37, Jakub Scholz  wrote:
> Hi,
>
> When I have listener configured like this:
>
> listener {
> role: normal
> host: 0.0.0.0
> port: amqp
> saslMechanisms: PLAIN DIGEST-MD5 CRAM-MD5
> linkCapacity: 1000
> }
>
> Is it really expected that it allows anonymous access? It seems that unless
> I add to the listener configuration also "authenticatePeer: yes", it will
> always allow anonymous access to clients which don't trigger the SASL
> layer.
>
> This seems to me as something quite counter-intuitive and dangerous,
> because on a first look someone (like me for example :-o) might expect that
> this configuration allows only username/password authenticated access.
>
> Wouldn't it make more sense to have anonymous access disabled by default?
> At least when SASL layer is configured for given listener? Or is it just me
> who finds this confusing?
>
> Regards
> Jakub

>From previous discussion (mainly around Proton where some of the
underlying behaviour originates) I believe it is actually expected
behaviour, but like you I don't think it is very intuitive, and would
again suggest we change it.

Robbie

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: [VOTE] Release Qpid Dispatch Router 0.6.1

[Jakub Scholz]

+1

I built it from source code and run some of my tests including connections
to Qpid C++ broker and various clients.

On Tue, Aug 2, 2016 at 3:17 PM, Ted Ross  wrote:

> This is the vote thread for Qpid Dispatch Router 0.6.1 (RC1).  Please test
> and vote:
>
> https://dist.apache.org/repos/dist/dev/qpid/dispatch/0.6.1-rc1/
>
> Changes since 0.6.0:
>
> DISPATCH-341 - router did not respond to request to drain a message-
>routed consumers link credit
> DISPATCH-364 - Inter-router listeners should not permit normal endpoint
>traffic
> DISPATCH-365 - Standalone router crashes if an interior router attempts
>to connect to it
> DISPATCH-366 - When delivery fails the router sends the RELEASED
>disposition, not MODIFIED
> DISPATCH-367 - balanced distribution needs to be more... balanced.
> DISPATCH-387 - Router core dumps with misbehaving client
> DISPATCH-410 - console build fixups
> DISPATCH-443 - Reverse name lookup on listener connections can hang the
>entire router
> DISPATCH-460 - Regression: Link-routed dynamic sources don't work
>
> Thanks,
>
> -Ted
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

RE: [Performance] Benchmarking Qpid dispatch router 0.6.0 with Qpid Java Broker 6.0.0

[Adel Boutros]

And how do you measure your throughput?

> From: adelbout...@live.com
> To: users@qpid.apache.org
> Subject: RE: [Performance] Benchmarking Qpid dispatch router 0.6.0 with Qpid 
> Java Broker 6.0.0
> Date: Wed, 3 Aug 2016 18:38:12 +0200
> 
> Hello Ulf,
> 
> I am sending messages with a byte array of 100 bytes and I am using Berkley 
> DB as a message store (which should be slower than having memory only message 
> store, no?)
> 
> With 1 consumer, 1 producer and no broker, I am at 33k msgs/sec if they are 
> all on the same machine and I have set "jms.forceAsyncSend=true" on the 
> producer and "jms.sendAcksAsync=true" for the consumer.
> 
> Are you using other options to get 190k? Do you think JMS might be a 
> bottleneck? Or something else in my config/test?
> 
> JMS client 0.9.0
> Qpid Java Broker 6.0.1
> Dispatcher 0.6.0
> 
> Adel
> 
> > Subject: Re: [Performance] Benchmarking Qpid dispatch router 0.6.0 with 
> > Qpid Java Broker 6.0.0
> > To: users@qpid.apache.org
> > From: l...@redhat.com
> > Date: Wed, 3 Aug 2016 16:23:06 +0200
> > 
> > Hi,
> > 
> > Excuse me if this was already mentioned somewhere, but what is the size 
> > of the messages you are sending ?
> > 
> > FWIW, I'm able to get around 30-40k msgs/sec sustained with 1 producer, 
> > 1 consumer, 1 dispatch (4 worker threads) and 1 broker (activemq-5). The 
> > sender sends unsettled messages as fast as it can using qpid-proton 
> > reactor API which is sending async up to the window limit.
> > 
> > With no broker involved, I'm getting ~190k msgs/sec.
> > 
> > All of these numbers are from my 8 core laptop. Message size is 128 bytes.
> > 
> > I don't know the dispatcher that well, but I think it should be able to 
> > handle data from each connector just fine given the numbers I have seen.
> > 
> > On 08/03/2016 02:41 PM, Adel Boutros wrote:
> > >
> > >
> > >
> > > Hello again,
> > >
> > 
> > 
> > 
> > > As requested, I added a 2nd connector and the appropriate autoLinks on 
> > > the same host/port but with a different name. It seems to have resolved 
> > > the issue.
> > >
> > > 1 Broker, 1 Dispatcher, 3 producers, 0 consumers, 1 connectors --> 5000 
> > > msg/s.
> > > 1 Broker, 1 Dispatcher, 3 producers, 0 consumers, 2 connectors --> 6600 
> > > msg/s.
> > > 1 Broker, 1 Dispatcher, 4 producers, 0 consumers, 2 connectors --> 7700 
> > > msg/s.
> > >
> > > I think this confirms the problem is due to the fact a single connection 
> > > is being shared by all clients (consumers/producers) and that having a 
> > > sort of pool of connections or a connection per workerThread is a 
> > > solution to consider.
> > >
> > > What do you think?
> > >
> > > I added a 3rd connector to see if it changes anything but it
> > > didn't.  Do you think this is maybe because the dispatcher is not able
> > > to process fast enough and saturate the 2 connectors?
> > > 1 Broker, 1 Dispatcher, 4 producers, 0 consumers, 3 connectors --> 7700 
> > > msg/s.
> > >
> > 
> > 
> > 
> > > Adel
> > >
> > >> From: adelbout...@live.com
> > >> To: users@qpid.apache.org
> > >> Subject: RE: [Performance] Benchmarking Qpid dispatch router 0.6.0 with 
> > >> Qpid Java Broker 6.0.0
> > >> Date: Tue, 2 Aug 2016 22:21:54 +0200
> > >>
> > >> Sorry for the typo. Indeed, it was with 3 producers. I used 4 and 8 
> > >> workerThread but there wasn't a difference.
> > >> We want to benchmark in the worst case scenarios actually to see what is 
> > >> the minimum we can guarantee. This is why we are using synchronous 
> > >> sending. In the future, we will also benchmark with full SSL/SASL to see 
> > >> what impact it has on the performance.
> > >>> Subject: Re: [Performance] Benchmarking Qpid dispatch router 0.6.0 with 
> > >>> Qpid Java Broker 6.0.0
> > >>> To: users@qpid.apache.org
> > >>> From: g...@redhat.com
> > >>> Date: Tue, 2 Aug 2016 20:41:54 +0100
> > >>>
> > >>> On 02/08/16 20:25, Adel Boutros wrote:
> >  How about the tests we did with consumer/producers connected directly 
> >  to the dispatcher without any broker where we had 16 000 msg/s with 4 
> >  producers. Is it also a very low value given that there is no 
> >  persistence or storing here? It was also synchronous sending.
> > >>>
> > >>> The rate is low because it is synchronous. One messages is sent to the
> > >>> consumer who acknowledges it, the acknowledgement is then conveyed back
> > >>> to the sender who then can send the next message.
> > >>>
> > >>> The rate for a single producer through the router was 6,000 per second.
> > >>> That works out as a roundtrip time of 167 microsecs or so. In your
> > >>> table, the 16,000 rate was listed as being for 3 producers. Based on the
> > >>> rate of a single producer, the best you could hope for there is 3 *
> > >>> 6,000 i.e 18,000. (How many worker threads did you have on the router
> > >>> for that case?)
> > >>>
> > >>> -
> > >>> To unsubscribe, e-mail: 

RE: [Performance] Benchmarking Qpid dispatch router 0.6.0 with Qpid Java Broker 6.0.0

[Adel Boutros]

Hello Ulf,

I am sending messages with a byte array of 100 bytes and I am using Berkley DB 
as a message store (which should be slower than having memory only message 
store, no?)

With 1 consumer, 1 producer and no broker, I am at 33k msgs/sec if they are all 
on the same machine and I have set "jms.forceAsyncSend=true" on the producer 
and "jms.sendAcksAsync=true" for the consumer.

Are you using other options to get 190k? Do you think JMS might be a 
bottleneck? Or something else in my config/test?

JMS client 0.9.0
Qpid Java Broker 6.0.1
Dispatcher 0.6.0

Adel

> Subject: Re: [Performance] Benchmarking Qpid dispatch router 0.6.0 with Qpid 
> Java Broker 6.0.0
> To: users@qpid.apache.org
> From: l...@redhat.com
> Date: Wed, 3 Aug 2016 16:23:06 +0200
> 
> Hi,
> 
> Excuse me if this was already mentioned somewhere, but what is the size 
> of the messages you are sending   ?
> 
> FWIW, I'm able to get around 30-40k msgs/sec sustained with 1 producer, 
> 1 consumer, 1 dispatch (4 worker threads) and 1 broker (activemq-5). The 
> sender sends unsettled messages as fast as it can using qpid-proton 
> reactor API which is sending async up to the window limit.
> 
> With no broker involved, I'm getting ~190k msgs/sec.
> 
> All of these numbers are from my 8 core laptop. Message size is 128 bytes.
> 
> I don't know the dispatcher that well, but I think it should be able to 
> handle data from each connector just fine given the numbers I have seen.
> 
> On 08/03/2016 02:41 PM, Adel Boutros wrote:
> >
> >
> >
> > Hello again,
> >
> 
> 
> 
> > As requested, I added a 2nd connector and the appropriate autoLinks on the 
> > same host/port but with a different name. It seems to have resolved the 
> > issue.
> >
> > 1 Broker, 1 Dispatcher, 3 producers, 0 consumers, 1 connectors --> 5000 
> > msg/s.
> > 1 Broker, 1 Dispatcher, 3 producers, 0 consumers, 2 connectors --> 6600 
> > msg/s.
> > 1 Broker, 1 Dispatcher, 4 producers, 0 consumers, 2 connectors --> 7700 
> > msg/s.
> >
> > I think this confirms the problem is due to the fact a single connection is 
> > being shared by all clients (consumers/producers) and that having a sort of 
> > pool of connections or a connection per workerThread is a solution to 
> > consider.
> >
> > What do you think?
> >
> > I added a 3rd connector to see if it changes anything but it
> > didn't.  Do you think this is maybe because the dispatcher is not able
> > to process fast enough and saturate the 2 connectors?
> > 1 Broker, 1 Dispatcher, 4 producers, 0 consumers, 3 connectors --> 7700 
> > msg/s.
> >
> 
> 
> 
> > Adel
> >
> >> From: adelbout...@live.com
> >> To: users@qpid.apache.org
> >> Subject: RE: [Performance] Benchmarking Qpid dispatch router 0.6.0 with 
> >> Qpid Java Broker 6.0.0
> >> Date: Tue, 2 Aug 2016 22:21:54 +0200
> >>
> >> Sorry for the typo. Indeed, it was with 3 producers. I used 4 and 8 
> >> workerThread but there wasn't a difference.
> >> We want to benchmark in the worst case scenarios actually to see what is 
> >> the minimum we can guarantee. This is why we are using synchronous 
> >> sending. In the future, we will also benchmark with full SSL/SASL to see 
> >> what impact it has on the performance.
> >>> Subject: Re: [Performance] Benchmarking Qpid dispatch router 0.6.0 with 
> >>> Qpid Java Broker 6.0.0
> >>> To: users@qpid.apache.org
> >>> From: g...@redhat.com
> >>> Date: Tue, 2 Aug 2016 20:41:54 +0100
> >>>
> >>> On 02/08/16 20:25, Adel Boutros wrote:
>  How about the tests we did with consumer/producers connected directly to 
>  the dispatcher without any broker where we had 16 000 msg/s with 4 
>  producers. Is it also a very low value given that there is no 
>  persistence or storing here? It was also synchronous sending.
> >>>
> >>> The rate is low because it is synchronous. One messages is sent to the
> >>> consumer who acknowledges it, the acknowledgement is then conveyed back
> >>> to the sender who then can send the next message.
> >>>
> >>> The rate for a single producer through the router was 6,000 per second.
> >>> That works out as a roundtrip time of 167 microsecs or so. In your
> >>> table, the 16,000 rate was listed as being for 3 producers. Based on the
> >>> rate of a single producer, the best you could hope for there is 3 *
> >>> 6,000 i.e 18,000. (How many worker threads did you have on the router
> >>> for that case?)
> >>>
> >>> -
> >>> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> >>> For additional commands, e-mail: users-h...@qpid.apache.org
> >>>
> >>
> >
> > 
> >
> 
> -- 
> Ulf
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
> 
  

Dispatch: Default value of authenticatePeer

[Jakub Scholz]

Hi,

When I have listener configured like this:

listener {
role: normal
host: 0.0.0.0
port: amqp
saslMechanisms: PLAIN DIGEST-MD5 CRAM-MD5
linkCapacity: 1000
}

Is it really expected that it allows anonymous access? It seems that unless
I add to the listener configuration also "authenticatePeer: yes", it will
always allow anonymous access to clients which don't trigger the SASL
layer.

This seems to me as something quite counter-intuitive and dangerous,
because on a first look someone (like me for example :-o) might expect that
this configuration allows only username/password authenticated access.

Wouldn't it make more sense to have anonymous access disabled by default?
At least when SASL layer is configured for given listener? Or is it just me
who finds this confusing?

Regards
Jakub

RFI: PROTON-1272 & PROTON-1243

[Andrew Stitcher]

These fixes missed the beta cut-off by a few hours!

PROTON-1272: This is a trivial fix that allows build tests to run
correctly on more systems (RHEL 6 in particular)

PROTON-1243: This is a serious bug in a basic functionality of proton-c 
reactor and its bindings (and maybe in the proton-j reactor too) - it's
ameliorated because it can be worked around. The fix is some what wide
(but not very deep).

Andrew

Refs:

PROTON-1272:
https://issues.apache.org/jira/browse/PROTON-1272
https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=9d513c9

PROTON-1243:
https://issues.apache.org/jira/browse/PROTON-1243
https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=92b822c


-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: [VOTE] Release Qpid Dispatch Router 0.6.1

[Ganesh Murthy]

+1 

* Downloaded distribution
* Verified checksums 
* Verified that patch to DISPATCH-367 and relevant units tests are present.
* Ran all unit tests successfully

Thanks.

- Original Message -
> From: "Ken Giusti" 
> To: users@qpid.apache.org
> Sent: Wednesday, August 3, 2016 11:00:15 AM
> Subject: Re: [VOTE] Release Qpid Dispatch Router 0.6.1
> 
> +1
> 
>  - passes oslo functional tests, simulator, and test clients
> 
> 
> - Original Message -
> > From: "Ted Ross" 
> > To: users@qpid.apache.org
> > Sent: Tuesday, August 2, 2016 9:17:20 AM
> > Subject: [VOTE] Release Qpid Dispatch Router 0.6.1
> > 
> > This is the vote thread for Qpid Dispatch Router 0.6.1 (RC1).  Please
> > test and vote:
> > 
> >  https://dist.apache.org/repos/dist/dev/qpid/dispatch/0.6.1-rc1/
> > 
> > Changes since 0.6.0:
> > 
> > DISPATCH-341 - router did not respond to request to drain a message-
> > routed consumers link credit
> > DISPATCH-364 - Inter-router listeners should not permit normal endpoint
> > traffic
> > DISPATCH-365 - Standalone router crashes if an interior router attempts
> > to connect to it
> > DISPATCH-366 - When delivery fails the router sends the RELEASED
> > disposition, not MODIFIED
> > DISPATCH-367 - balanced distribution needs to be more... balanced.
> > DISPATCH-387 - Router core dumps with misbehaving client
> > DISPATCH-410 - console build fixups
> > DISPATCH-443 - Reverse name lookup on listener connections can hang the
> > entire router
> > DISPATCH-460 - Regression: Link-routed dynamic sources don't work
> > 
> > Thanks,
> > 
> > -Ted
> > 
> > 
> > -
> > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> > For additional commands, e-mail: users-h...@qpid.apache.org
> > 
> > 
> 
> --
> -K
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
> 
> 

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Qpid dispatch router issue

[Robbie Gemmell]

On 3 August 2016 at 15:52, Gordon Sim  wrote:
> On 03/08/16 15:13, Robbie Gemmell wrote:
>>
>> ActiveMQ 5.9.0 is rather old and its AMQP 1.0 support was fairly
>> recent at the time, its changed a lot since then. You'll want to try a
>> newer version. 5.13.4 is the current, with 5.14.0 currently under vote
>> for release.
>
>
> Yes, if I recall correctly 5.9 did not implement heartbeats which is why the
> router is terminating the connection.

Correct. I hadn't read the earlier message yet or I'd probably have
pointed that out too. It wasnt supported for a while after that, I
think 5.12.0 perhaps.

> You may be able to workaround that be
> setting the idleTimeoutSeconds for the connector to 0. However as Robbie
> says, it would be better to update the broker as there will be many other
> potential issues fixed by that.
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Queries - Qpid Proton AMQP

[Gordon Sim]

On 03/08/16 12:40, Sasikumar Ramasamy wrote:

Hi Folks,

I am a new bee for messaging service. My need is to parse reactive messages
through network using core java. I tried to implement Active-MQ and  kafka,
but i got messed up. I can't find semantic Tutorials/Demo  regarding this.
And now i just figured out Qpid AMQP, which could be a visionary for my
purpose.

But still i'm lost and can't find good tutorials. Kindly provide me with
some teaches to implement remote messaging service through Qpid (with
sample source codes) along with java implementation.


There are a couple of tutorials for Qpid but at present they only cover 
python[1] and c++[2]. For java, perhaps the best thing would be to start 
with a tutorial on JMS, e.g.



http://docs.oracle.com/javaee/1.3/jms/tutorial/1_3_1-fcs/doc/jms_tutorialTOC.html

or perhaps

  http://www.onjava.com/pub/a/onjava/excerpt/jms_ch2/

Then you can use the qpid JMS client.

--

[1] 
https://qpid.apache.org/releases/qpid-proton-0.10/proton/python/tutorial/tutorial.html
[2] 
https://qpid.apache.org/releases/qpid-proton-master/proton/cpp/api/tutorial.html


-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: [VOTE] Release Qpid Dispatch Router 0.6.1

[Ken Giusti]

+1

 - passes oslo functional tests, simulator, and test clients


- Original Message -
> From: "Ted Ross" 
> To: users@qpid.apache.org
> Sent: Tuesday, August 2, 2016 9:17:20 AM
> Subject: [VOTE] Release Qpid Dispatch Router 0.6.1
> 
> This is the vote thread for Qpid Dispatch Router 0.6.1 (RC1).  Please
> test and vote:
> 
>  https://dist.apache.org/repos/dist/dev/qpid/dispatch/0.6.1-rc1/
> 
> Changes since 0.6.0:
> 
> DISPATCH-341 - router did not respond to request to drain a message-
> routed consumers link credit
> DISPATCH-364 - Inter-router listeners should not permit normal endpoint
> traffic
> DISPATCH-365 - Standalone router crashes if an interior router attempts
> to connect to it
> DISPATCH-366 - When delivery fails the router sends the RELEASED
> disposition, not MODIFIED
> DISPATCH-367 - balanced distribution needs to be more... balanced.
> DISPATCH-387 - Router core dumps with misbehaving client
> DISPATCH-410 - console build fixups
> DISPATCH-443 - Reverse name lookup on listener connections can hang the
> entire router
> DISPATCH-460 - Regression: Link-routed dynamic sources don't work
> 
> Thanks,
> 
> -Ted
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
> 
> 

-- 
-K

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Qpid dispatch router issue

[Gordon Sim]

On 03/08/16 15:13, Robbie Gemmell wrote:

ActiveMQ 5.9.0 is rather old and its AMQP 1.0 support was fairly
recent at the time, its changed a lot since then. You'll want to try a
newer version. 5.13.4 is the current, with 5.14.0 currently under vote
for release.


Yes, if I recall correctly 5.9 did not implement heartbeats which is why 
the router is terminating the connection. You may be able to workaround 
that be setting the idleTimeoutSeconds for the connector to 0. However 
as Robbie says, it would be better to update the broker as there will be 
many other potential issues fixed by that.



-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: [Performance] Benchmarking Qpid dispatch router 0.6.0 with Qpid Java Broker 6.0.0

[Ulf Lilleengen]

Hi,

Excuse me if this was already mentioned somewhere, but what is the size 
of the messages you are sending 	?


FWIW, I'm able to get around 30-40k msgs/sec sustained with 1 producer, 
1 consumer, 1 dispatch (4 worker threads) and 1 broker (activemq-5). The 
sender sends unsettled messages as fast as it can using qpid-proton 
reactor API which is sending async up to the window limit.


With no broker involved, I'm getting ~190k msgs/sec.

All of these numbers are from my 8 core laptop. Message size is 128 bytes.

I don't know the dispatcher that well, but I think it should be able to 
handle data from each connector just fine given the numbers I have seen.


On 08/03/2016 02:41 PM, Adel Boutros wrote:




Hello again,






As requested, I added a 2nd connector and the appropriate autoLinks on the same 
host/port but with a different name. It seems to have resolved the issue.

1 Broker, 1 Dispatcher, 3 producers, 0 consumers, 1 connectors --> 5000 msg/s.
1 Broker, 1 Dispatcher, 3 producers, 0 consumers, 2 connectors --> 6600 msg/s.
1 Broker, 1 Dispatcher, 4 producers, 0 consumers, 2 connectors --> 7700 msg/s.

I think this confirms the problem is due to the fact a single connection is 
being shared by all clients (consumers/producers) and that having a sort of 
pool of connections or a connection per workerThread is a solution to consider.

What do you think?

I added a 3rd connector to see if it changes anything but it
didn't.  Do you think this is maybe because the dispatcher is not able
to process fast enough and saturate the 2 connectors?
1 Broker, 1 Dispatcher, 4 producers, 0 consumers, 3 connectors --> 7700 msg/s.






Adel


From: adelbout...@live.com
To: users@qpid.apache.org
Subject: RE: [Performance] Benchmarking Qpid dispatch router 0.6.0 with Qpid 
Java Broker 6.0.0
Date: Tue, 2 Aug 2016 22:21:54 +0200

Sorry for the typo. Indeed, it was with 3 producers. I used 4 and 8 
workerThread but there wasn't a difference.
We want to benchmark in the worst case scenarios actually to see what is the 
minimum we can guarantee. This is why we are using synchronous sending. In the 
future, we will also benchmark with full SSL/SASL to see what impact it has on 
the performance.

Subject: Re: [Performance] Benchmarking Qpid dispatch router 0.6.0 with Qpid 
Java Broker 6.0.0
To: users@qpid.apache.org
From: g...@redhat.com
Date: Tue, 2 Aug 2016 20:41:54 +0100

On 02/08/16 20:25, Adel Boutros wrote:

How about the tests we did with consumer/producers connected directly to the 
dispatcher without any broker where we had 16 000 msg/s with 4 producers. Is it 
also a very low value given that there is no persistence or storing here? It 
was also synchronous sending.


The rate is low because it is synchronous. One messages is sent to the
consumer who acknowledges it, the acknowledgement is then conveyed back
to the sender who then can send the next message.

The rate for a single producer through the router was 6,000 per second.
That works out as a roundtrip time of 167 microsecs or so. In your
table, the 16,000 rate was listed as being for 3 producers. Based on the
rate of a single producer, the best you could hope for there is 3 *
6,000 i.e 18,000. (How many worker threads did you have on the router
for that case?)

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org









--
Ulf

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Qpid dispatch router issue

[Robbie Gemmell]

ActiveMQ 5.9.0 is rather old and its AMQP 1.0 support was fairly
recent at the time, its changed a lot since then. You'll want to try a
newer version. 5.13.4 is the current, with 5.14.0 currently under vote
for release.

On 3 August 2016 at 14:37, eric73  wrote:
> Hello Sim,
> I use Apache ActiveMQ broker 5.9.0 with AMQP1.0 on Windows 7 Entreprise.
> The clients run on Linux mint 17.3.
>
>
>
>
>
> --
> View this message in context: 
> http://qpid.2158936.n2.nabble.com/Qpid-dispatch-router-issue-tp7648428p7648644.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

RE: Qpid dispatch router issue

[eric73]

Hi Paolo,
I try "route-container" instead of "on-demand" and it is the same problem of
timeout.
Thanks for the reply.
Regards
Eric



--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Qpid-dispatch-router-issue-tp7648428p7648648.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Qpid dispatch router issue

[eric73]

Hello Sim, 
I use Apache ActiveMQ broker 5.9.0 with AMQP1.0 on Windows 7 Entreprise.
The clients run on Linux mint 17.3.





--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Qpid-dispatch-router-issue-tp7648428p7648644.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: Qpid dispatch router issue

[Gordon Sim]

On 03/08/16 13:45, eric73 wrote:

Thank Ted.
I set "standalone" mode for the router configuration.
But now the dispatch router seems have problem when it try to connect to the
broker.
Indefinitely, there is a timeout error after connection: "local-idle-timeout
expired".


What broker are you using, and what version?


-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

RE: Qpid dispatch router issue

[Paolo Patierno]

Hi,

the role for the connector should be "route-container" not "on-demand".

Regards,
Paolo.

Paolo PatiernoSenior Software Engineer (IoT) @ Red Hat
Microsoft MVP on Windows Embedded & IoTMicrosoft Azure Advisor 
Twitter : @ppatierno
Linkedin : paolopatierno
Blog : DevExperience

> Date: Wed, 3 Aug 2016 05:45:30 -0700
> From: ericclapp...@eaton.com
> To: users@qpid.apache.org
> Subject: Re: Qpid dispatch router issue
> 
> Thank Ted.
> I set "standalone" mode for the router configuration.
> But now the dispatch router seems have problem when it try to connect to the
> broker.
> Indefinitely, there is a timeout error after connection: "local-idle-timeout
> expired".
> Here is the dispatch router log:
> ...
> 
> ...
> 
> Regards
> 
> 
> 
> --
> View this message in context: 
> http://qpid.2158936.n2.nabble.com/Qpid-dispatch-router-issue-tp7648428p7648633.html
> Sent from the Apache Qpid users mailing list archive at Nabble.com.
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
> 
  

Re: Qpid dispatch router issue

[eric73]

Thank Ted.
I set "standalone" mode for the router configuration.
But now the dispatch router seems have problem when it try to connect to the
broker.
Indefinitely, there is a timeout error after connection: "local-idle-timeout
expired".
Here is the dispatch router log:
...

...

Regards



--
View this message in context: 
http://qpid.2158936.n2.nabble.com/Qpid-dispatch-router-issue-tp7648428p7648633.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

RE: [Performance] Benchmarking Qpid dispatch router 0.6.0 with Qpid Java Broker 6.0.0

[Adel Boutros]

Hello again,

As requested, I added a 2nd connector and the appropriate autoLinks on the same 
host/port but with a different name. It seems to have resolved the issue.

1 Broker, 1 Dispatcher, 3 producers, 0 consumers, 1 connectors --> 5000 msg/s.
1 Broker, 1 Dispatcher, 3 producers, 0 consumers, 2 connectors --> 6600 msg/s.
1 Broker, 1 Dispatcher, 4 producers, 0 consumers, 2 connectors --> 7700 msg/s.

I think this confirms the problem is due to the fact a single connection is 
being shared by all clients (consumers/producers) and that having a sort of 
pool of connections or a connection per workerThread is a solution to consider.

What do you think?

I added a 3rd connector to see if it changes anything but it 
didn't.  Do you think this is maybe because the dispatcher is not able 
to process fast enough and saturate the 2 connectors?
1 Broker, 1 Dispatcher, 4 producers, 0 consumers, 3 connectors --> 7700 msg/s.

Adel

> From: adelbout...@live.com
> To: users@qpid.apache.org
> Subject: RE: [Performance] Benchmarking Qpid dispatch router 0.6.0 with Qpid 
> Java Broker 6.0.0
> Date: Tue, 2 Aug 2016 22:21:54 +0200
> 
> Sorry for the typo. Indeed, it was with 3 producers. I used 4 and 8 
> workerThread but there wasn't a difference.
> We want to benchmark in the worst case scenarios actually to see what is the 
> minimum we can guarantee. This is why we are using synchronous sending. In 
> the future, we will also benchmark with full SSL/SASL to see what impact it 
> has on the performance.
> > Subject: Re: [Performance] Benchmarking Qpid dispatch router 0.6.0 with 
> > Qpid Java Broker 6.0.0
> > To: users@qpid.apache.org
> > From: g...@redhat.com
> > Date: Tue, 2 Aug 2016 20:41:54 +0100
> > 
> > On 02/08/16 20:25, Adel Boutros wrote:
> > > How about the tests we did with consumer/producers connected directly to 
> > > the dispatcher without any broker where we had 16 000 msg/s with 4 
> > > producers. Is it also a very low value given that there is no persistence 
> > > or storing here? It was also synchronous sending.
> > 
> > The rate is low because it is synchronous. One messages is sent to the 
> > consumer who acknowledges it, the acknowledgement is then conveyed back 
> > to the sender who then can send the next message.
> > 
> > The rate for a single producer through the router was 6,000 per second. 
> > That works out as a roundtrip time of 167 microsecs or so. In your 
> > table, the 16,000 rate was listed as being for 3 producers. Based on the 
> > rate of a single producer, the best you could hope for there is 3 * 
> > 6,000 i.e 18,000. (How many worker threads did you have on the router 
> > for that case?)
> > 
> > -
> > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> > For additional commands, e-mail: users-h...@qpid.apache.org
> > 
> 

  

Queries - Qpid Proton AMQP

[Sasikumar Ramasamy]

Hi Folks,

I am a new bee for messaging service. My need is to parse reactive messages
through network using core java. I tried to implement Active-MQ and  kafka,
but i got messed up. I can't find semantic Tutorials/Demo  regarding this.
And now i just figured out Qpid AMQP, which could be a visionary for my
purpose.

But still i'm lost and can't find good tutorials. Kindly provide me with
some teaches to implement remote messaging service through Qpid (with
sample source codes) along with java implementation.

Thanks in advance. Hope will get a new year.

-- 
*With Warm Wishes & Regards,*
*RSK(**R.Sasikumar**)*

Re: Seeing a Qpid C++ master build failure in AppVeyor

[Gordon Sim]

On 03/08/16 00:26, Justin Ross wrote:

This problem remains for me.  Unless this is shown to be my error, it
blocks the C++ release.

The problem appears related to code that was recently changed.

https://gist.github.com/ssorj/44fcffd57075ad230ec8d221bca8e92a

https://ci.appveyor.com/project/ssorj/qpid-cpp/build/hammerandtong.4


I've checked in something that should resolve the error. (Though I don't 
understand why that fails when there are many other places where a 
shared_ptr is converted to a bool, though not perhaps in a return 
statement).



-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org