qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Ross <tr...@redhat.com>
Subject Re: [Dispatch router 0.6.1] Configuration bugs
Date Fri, 30 Sep 2016 13:18:21 GMT


On 09/30/2016 08:56 AM, Adel Boutros wrote:
> Hello Ted,
>
>
> You say "They delete themselves when the address is no longer in use". In my reduced
test case, the dispatch router is alone and there are no consumers/producers attached to it.
Shouldn't it be deleted then?

Yes.  If there are no attached links for the address, the entry will be 
removed from the address list (qdstat -a).  Are you certain that all the 
links are detached?

>
>
> As for the "why you want to delete the operational addresses", we wanted a way to monitor
the traffic on the dispatch router and debug how messages are traversing across the router
every time we send messages.
>
> In the Java Broker, when you delete a queue, its statistics are gone and reset when you
recreate it. We were expecting the same thing here.

They really are different things.  A queue on a broker is a first-class 
entity that must be explicitly provisioned.  An address in a router is a 
side effect of other things like attached links, consumers on remote 
routers, etc.

>
> In my tests, at the start of each run, we delete/re-create all queues on the brokers
and we do the same on the dispatch router(We delete/re-create using qdmanage all needed connectors,
listeners, addresses and autoLinks).
> Then we send messages to the dispatch router twice (Once using JMS producers and once
using Proton-c producers). If I sent 3 messages in each run, I want to verify that the router
received 3 messages on the "In" and redirected them to the "out".
> At the start of each run and because we delete the addresses on the dispatch router,
we would except the stats to be reset. However for the second run (Proton-c), I end up with
6 messages (3 old ones + 3 new ones) and I cannot assert the dispatch router has just received
3 messages.
> As a workaround, I am calculating the difference in the number of messages between the
end and the start of each test run.
>
> However, as stated before, the behavior is not similar to the Qpid Java Broker and at
the start I was convinced my producers were really sending 6 messages and not 3.

Based on your description, I expect the router to behave the way you 
want it to.  If your JMS endpoints are fully detached before your C 
endpoints attach, then you should have fresh stats each time.

>
> In my opinion, in a multi-component system, it would make it easier if every component
behaved the same way. So if a queue deletion on the Broker would delete its statistics, I
would expect the same behavior on the router.

In general, I would agree with you on this.  But queues and addresses 
are not equivalent concepts and will not behave in the same way.

>
> What do you think?
> Is there really any usefulness to keep stats of a deleted addresses?

Actually, I think we need to introduce a log entry that is emitted each 
time an address is removed from the table so we can archive its 
statistics rather than just lose them.

>
> Regards,
> Adel
>
> ________________________________
> From: Ted Ross <tross@redhat.com>
> Sent: Friday, September 30, 2016 2:38 PM
> To: users@qpid.apache.org
> Subject: Re: [Dispatch router 0.6.1] Configuration bugs
>
> Adel,
>
> There are actually two separate entity types for addresses:  The
> 'router.config.address' and the 'router.address'.  The config address is
> the one that is driven by the config file and the one that you create
> and delete using qdmanage.  router.config.address is a lookup for how
> addresses are supposed to be treated when they appear on the network.
>
> The other type: router.address, is the one that is shown with qdstat -a.
>   This is a table of addresses seen on the network.  Entries in this
> table can't be deleted manually.  They delete themselves when the
> address is no longer in use (i.e. no producers or consumers on the local
> router and no consumers on reachable remote routers).
>
> I think we should step back and talk about why you want to delete the
> operational addresses.  Do you have requirements around the gathering of
> statistics?
>
> -Ted
>
> On 09/30/2016 05:57 AM, Adel Boutros wrote:
>> Hello again,
>>
>>
>> Now to the next issue: I can see the "name attribute in the query but I cannot delete
the address (It still appears in "qdstat -a")
>>
>>
>> Steps to reproduce using the same router configuration below:
>>
>>
>> qdstat -b amqp://localhost:10801 -a
>>
>>
>> Router Addresses
>>   class   addr                   phs  distrib    in-proc  local  remote  cntnr  in
 out  thru  to-proc  from-proc
>>   ==============================================================================
>>   mobile  testQueue              1    balanced   0        0      0       0      0
  0    0     0        0
>>   mobile  testQueue              0    balanced   0        1      0       0      0
  0    0     0        0
>> -------------------------------------------------------------
>>
>> qdmanage -b amqp://localhost:10801 query --type=address
>> [
>>   {
>>     "name": "testQueue.addr",
>>     "ingressPhase": 0,
>>     "prefix": "testQueue",
>>     "waypoint": true,
>>     "distribution": "balanced",
>>     "type": "org.apache.qpid.dispatch.router.config.address",
>>     "identity": "1",
>>     "egressPhase": 1
>>   }
>> ]
>> --------------------------------
>>
>> qdmanage -b amqp://localhost:10801 delete --type=address --name testQueue.addr
>> ---------------------------------
>>
>> qdmanage -b amqp://localhost:10801 query --type=address
>> []
>> -------------------------------
>>
>> qdstat -b amqp://localhost:10801 -a
>>
>>
>> Router Addresses
>>   class   addr                   phs  distrib    in-proc  local  remote  cntnr  in
 out  thru  to-proc  from-proc
>>   ==============================================================================
>>   mobile  testQueue              1    balanced   0        0      0       0      0
  0    0     0        0
>>   mobile  testQueue              0    balanced   0        1      0       0      0
  0    0     0        0
>>
>>
>> Regards,
>>
>> Adel
>>
>>
>> ________________________________
>> From: Adel Boutros <Adelboutros@live.com>
>> Sent: Friday, September 30, 2016 11:30 AM
>> To: users@qpid.apache.org
>> Subject: Re: [Dispatch router 0.6.1] Configuration bugs
>>
>> Thank you Gordon!!
>>
>>
>> I manually applied the commit of DISPATCH-500 and tested it on top of 0.6.1 version
and it solved my issue.
>>
>>
>> Regards,
>>
>> Adel
>>
>> ________________________________
>> From: Gordon Sim <gsim@redhat.com>
>> Sent: Friday, September 30, 2016 10:12:23 AM
>> To: users@qpid.apache.org
>> Subject: Re: [Dispatch router 0.6.1] Configuration bugs
>>
>> On 30/09/16 08:59, Adel Boutros wrote:
>>> Hello,
>>>
>>>
>>> As a follow up to my previous thread, I am having some issues with the dispatch
router.
>>>
>>> I will start with the first one here:
>>>
>>> It seems the "name" attribute doesn't work for all types of entities. So, I cannot
delete them using the "name" attribute.
>>
>> I think this may be https://issues.apache.org/jira/browse/DISPATCH-500,
>> which is now fixed on master.
>>
>>> I have tested it on 4 types of entities and here are my findings:
>>>
>>> * Connector --> It works
>>>
>>> * Listener --> It works
>>>
>>> * Address --> It fails
>>>
>>> * AutoLink --> It fails
>>>
>>>
>>> With the below config, when I query the dispatch router, it doesn't show the
"name" attribute for my "address":
>>>
>>>
>>> qdmanage -b amqp://localhost:10801 query --type=address
>>> [
>>>   {
>>>     "egressPhase": 1,
>>>     "ingressPhase": 0,
>>>     "prefix": "testQueue",
>>>     "waypoint": true,
>>>     "distribution": "balanced",
>>>     "type": "org.apache.qpid.dispatch.router.config.address",
>>>     "identity": "1"
>>>   }
>>> ]
>>>
>>> qdmanage -b amqp://localhost:10801 query --type=listener
>>> [
>>>   {
>>>     "stripAnnotations": "both",
>>>     "addr": "0.0.0.0",
>>>     "requireSsl": false,
>>>     "idleTimeoutSeconds": 16,
>>>     "saslMechanisms": "ANONYMOUS",
>>>     "maxFrameSize": 16384,
>>>     "requireEncryption": false,
>>>     "host": "127.0.0.1",
>>>     "cost": 1,
>>>     "role": "normal",
>>>     "authenticatePeer": false,
>>>     "type": "org.apache.qpid.dispatch.listener",
>>>     "port": "10801",
>>>     "identity": "listener/127.0.0.1:10801:mainListener",
>>>     "name": "mainListener"
>>>   }
>>> ]
>>>
>>>
>>> -----------------------------------------------------------
>>> Router config:
>>> router {
>>>     mode: interior
>>>     routerId: router.10801
>>> }
>>>
>>> listener {
>>>     name: mainListener
>>>     addr: 0.0.0.0
>>>     port: 10801
>>>     role: normal
>>>     saslMechanisms: ANONYMOUS
>>>     requireSsl: no
>>>     authenticatePeer: no
>>> }
>>>
>>> address {
>>>     name: testQueue.addr
>>>     prefix: testQueue
>>>     waypoint: yes
>>> }
>>>
>>>
>>> Regards,
>>>
>>> Adel
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
>> For additional commands, e-mail: users-help@qpid.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>

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


Mime
View raw message