On Thu, 2018-10-18 at 21:56 +0100, Gordon Sim wrote:
> On 18/10/18 15:07, Hudalla Kai (INST/ECS4) wrote:
> > I am supplying them from the auth service in the same format that worked in
> > 1.1.0.
>
> This is not a result of any change in the auth plugin itself. Since
>
On Thu, 2018-10-18 at 13:35 +0100, Gordon Sim wrote:
> On 18/10/18 09:23, Hudalla Kai (INST/ECS4) wrote:
> >
> > On Tue, 2018-10-16 at 09:40 -0400, Ganesh Murthy wrote:
> > > The Apache Qpid (http://qpid.apache.org) community is pleased to
> > > announce the imme
Hi,
I have been successfully using the (experimental) SASL auth plugin feature with
Dispatch Router 1.1.0. I had implemented an auth service and configured the
router to use it for authenticating clients and authorizing requests to
establish
links.
I have now tried to use the same auth server
On Tue, 2018-10-16 at 09:40 -0400, Ganesh Murthy wrote:
> The Apache Qpid (http://qpid.apache.org) community is pleased to
> announce the immediate availability of Apache Qpid Dispatch 1.4.0
>
> Qpid Dispatch is a router for the Advanced Message Queuing Protocol 1.0
> (AMQP 1.0, ISO/IEC 19464,
nation. This leaves the "retry or not" decision
> up to the producer.
>
> Thoughts?
>
> -Ted
>
> On Thu, May 24, 2018 at 4:53 AM, Hudalla Kai (INST/ECS4)
> <kai.huda...@bosch-si.com> wrote:
>> Hi,
>>
>>
>> we are experiencing some unw
Hi,
we are experiencing some unwanted/unexpected behavior when using message
routing in Dispatch Router 1.0.1.
1. Receiver opens a receiver link on control/my-tenant/my-device
2. Sender opens a sender link on control/my-tenant/my-device
3. Sender gets credit from the router
4.
Hi,
I have implemented an auth service based on the "spec" given in [1].
When I configure our dispatch router 1.0.1 to use the service, I can see in the
log file of the auth service that the router indeed delegates authentication to
the auth service but doesn't seem to include the "ADDRESS_AUTHZ"
On 30.01.2018 13:48, Gordon Sim wrote:
On 30/01/18 12:03, Hudalla Kai (INST/ECS4) wrote:
Is it also ok for the receiver to send an attach with close=true in response to
the reouter's detach (close=false), effectively closing the link for good?
No, that would not work. The close actually needs
On 30.01.2018 11:28, Gordon Sim wrote:
On 30/01/18 06:15, Kai wrote:
Gordon,
by "it" you are referring to the consumer/receiver, correct?
Yes, the application receiving messages.
Is it also ok for the receiver to send an attach with close=true in response to
the reouter's detach (close=false),
dit flow control. linkCapacity is
therefore not related to maxFrameSize/maxSessionFrames.
-Ted
On Fri, Jul 21, 2017 at 10:27 AM, Hudalla Kai (INST/ECS4) <
kai.huda...@bosch-si.com> wrote:
> Hi,
>
> I am wondering what the (practical) meaning of the "linkCapacity&qu
Hi,
I am wondering what the (practical) meaning of the "linkCapacity" configuration
property on listeners is and in particular, how it is related to the
"maxFrameSize" and "maxSessionFrames" properties. Do the latter ones pose a
limit on the former one? My experience is that if I do not
ck
- Original Message -----
> From: "Hudalla Kai (INST/ECS4)" <kai.huda...@bosch-si.com>
> To: users@qpid.apache.org
> Sent: Wednesday, July 19, 2017 2:47:25 AM
> Subject: Re: Dispatch Router throughput
>
> Hi Chuck,
>
> thanks for the advice. Sadly, though, this d
r-id field of the message properties. Then
verify that the user has no name in the message user-id or the
same name that was used when the connection was created.
Allowing the user id proxy bypasses the per-message parsing and checking.
The down side of setting the user id proxy to true is it allo
.bosch-si.com
Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB
148411 B;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
From: Gordon Sim <g...@redhat.com>
Sent: Tuesday, July 18, 2017 14:05
To: users@qpid.apache.org
Subject:
hat we have done that
unsettled deliveries perform as well or better than pre-settled deliveries.
-Ted
On Mon, Jul 17, 2017 at 3:23 AM, Hudalla Kai (INST/ECS4) <
kai.huda...@bosch-si.com> wrote:
> Thanks everybody for your help with this problem. I think that we will
> first need to i
Router throughput
On 14/07/17 09:47, Hudalla Kai (INST/ECS4) wrote:
> We have been experimenting with different approaches:
>
> 1) Using a prefetch of 50
> 2) Using a prefetch of 1000
> 3) Using a prefetch of 0 and doing manual flow control, issuing 1000 credits
> initially
>
;
Executives: Dr.-Ing. Rainer Kallenbach, Michael Hahn
From: Gordon Sim <g...@redhat.com>
Sent: Friday, July 14, 2017 10:14
To: users@qpid.apache.org
Subject: Re: Dispatch Router throughput
On 14/07/17 09:07, Hudalla Kai (INST/ECS4) wrote:
> Sadl
formance numbers while I fiddle with the code.
HTH,
Chuck
- Original Message -
> From: "Hudalla Kai (INST/ECS4)" <kai.huda...@bosch-si.com>
> To: users@qpid.apache.org
> Sent: Thursday, July 13, 2017 10:20:09 AM
> Subject: Dispatch Router throughput
>
Hi,
we are currently doing some baseline throughput testing with Dispatch Router
0.8.0.
In the course of doing so, we wondered what number of messages we should be
able to expect being processed by a single Dispatch Router instance in its
default configuration, i.e. link capacity 250, 4 worker
Hi list,
I was wondering about the recommended number or worker threads to configure a
Dispatch Router instance with.
Is the default value of 4 suitable for all kinds of hardware or is this to be
considered a recommendation per CPU core?
In particular, what is the recommended setting for a
20 matches
Mail list logo
