I was able to delete the address after deleting all autoLinks referring that address.
Adel ________________________________ From: Ted Ross <[email protected]> Sent: Friday, September 30, 2016 3:18:21 PM To: [email protected] Subject: Re: [Dispatch router 0.6.1] Configuration bugs 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 <[email protected]> > Sent: Friday, September 30, 2016 2:38 PM > To: [email protected] > 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 <[email protected]> >> Sent: Friday, September 30, 2016 11:30 AM >> To: [email protected] >> 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 <[email protected]> >> Sent: Friday, September 30, 2016 10:12:23 AM >> To: [email protected] >> 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: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
