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]
