i'm glad the tool is working for you. There is a *lot* of information in there
and teasing all the facts from the web page can be tricky.
The names are a problem. In some cases dispatch router will create
objects with names that are two concatenated guids. The names are
so long that they take up too much screen space. Plus guids are pretty
meaningless. That's why all the 'name shorteners' are active. Then
the web page shows link_0 instead of the long name. Usually there's
a popup showing the long name if you hover over the short name.
Some of the link names are generated. For instance, from the self
tests:
<cut>
◊ 2019-04-24 10:00:26.491545 A0#340 QDR.B [A0_3] <- [] peer_2 attach [0,1]
receiver link_23 (source: none, target: none, class: client)
handle : 1
initial-delivery-count : 0
max-message-size : 0
name :
"bb078679-df5d-465e-b254-2b3cb90e358c-5f3191cf-07de-4d1c-aa82-c3d40434969d"
rcv-settle-mode : 0
role : true
snd-settle-mode : 2
source : DescribedType source( 40 ) : {'durable': '0', 'timeout': '0',
'dynamic': 'true'}
target : DescribedType target( 41 ) : {'durable': '0', 'timeout': '0',
'dynamic': 'false'}
◊ 2019-04-24 10:00:26.491963 A0#343 QDR.B [A0_3] -> [] peer_2 attach [0,1]
sender link_23 (source: "amqp:/_topo/0/QDR.B/temp.LyZ1nzIu_2OKZRd", target:
none, class: client)
handle : 1
initial-delivery-count : 0
max-message-size : 0
name :
"bb078679-df5d-465e-b254-2b3cb90e358c-5f3191cf-07de-4d1c-aa82-c3d40434969d"
rcv-settle-mode : 0
role : false
snd-settle-mode : 2
source : DescribedType source( 40 ) : {'address':
'"amqp:/_topo/0/QDR.B/temp.LyZ1nzIu_2OKZRd"', 'durable': '0', 'expiry-policy':
':"session-end"', 'timeout': '0', 'dynamic': 'true'}
target : DescribedType target( 41 ) : {'durable': '0', 'expiry-policy':
':"session-end"', 'timeout': '0', 'dynamic': 'false'}
<cut>
The first attach is peer_2 creating a dynamic receiver. The "source" field has
no address and "dynamic=true".
The second attach is the router coming back to peer_2 with the dynamically
created address.
Later a sender connects to the dynamic address.
In both of these attaches the link name is pretty cumbersome.
Regards,
Chuck
----- Original Message -----
> From: "VERMEULEN Olivier" <olivier.vermeu...@murex.com>
> To: users@qpid.apache.org
> Sent: Tuesday, April 23, 2019 9:23:37 AM
> Subject: RE: [Dispatch-router] Multicast
>
> Hello Chuck,
>
> I tried your tool and indeed it helps a lot understanding what's happening.
> For me the sections I find really useful (at least for this use case) are
> - "Connections" to identify the peers
> - "Message progress" to see the message routing
> - "Routing link state" to monitor the inter-connections between my
> dispatch-routers
>
> If I can make one comment though, it's still a bit difficult to read with all
> these IDs...
> For example in the "Log data" when a receiver attaches to a queue I get the
> real name in the source:
> attach [1,0] receiver link_24 (source: "myQueue", target: none, class:
> client)
> But when a producer attaches to a topic I only get the ID:
> attach [1,0] sender link_25 (source:
> "ID:c5eab952-81b1-4a55-ad68-8ac277249cd7:1:1:1", target: none, class:
> client)
>
> Thanks for the tool!
> Olivier
>
> -----Original Message-----
> From: VERMEULEN Olivier
> Sent: jeudi 18 avril 2019 21:58
> To: users@qpid.apache.org
> Subject: RE: [Dispatch-router] Multicast
>
> Hello Chuck,
>
> I'm very interested!
> Will give it a try next week.
>
> Thanks,
> Olivier
>
> -----Original Message-----
> From: Chuck Rolke <cro...@redhat.com>
> Sent: mercredi 17 avril 2019 22:51
> To: users@qpid.apache.org
> Subject: Re: [Dispatch-router] Multicast
>
> Hi Olivier,
>
> I've developed tooling to help find problems like the one you describe.
> Could you give it a try?
>
> To use it:
> 1. Turn on trace logging. For the most part just SERVER trace+ will do it but
> DEFAULT trace+ gets the most detail. Save each router's log to a separate
> file.
> Add something like this to your router config files:
>
> log {
> outputFile: <router-name>.log
> enable: trace+
> module: DEFAULT
> }
>
> 2. Delete existing log files for a clean analysis.
> 3. Run your test so it fails due to the race condition.
> 4. Stop the routers
> 5. Change cwd to the directory with the log files.
> 6. Scrape the logs and generate and html file with AMQP analysis:
> qpid-dispatch/tools/scraper/scraper.py -f *.log > test.html 7. Open the
> test.html file with a browser:
> firefox test.html
> 8. In the Log Data section you will find the router and client traffic.
>
> I suspect that the client connect sequence and data patterns will be visible.
>
> -Chuck
>
>
> ----- Original Message -----
> > From: "VERMEULEN Olivier" <olivier.vermeu...@murex.com>
> > To: users@qpid.apache.org
> > Sent: Wednesday, April 17, 2019 10:10:49 AM
> > Subject: RE: [Dispatch-router] Multicast
> >
> > Hello Gordon,
> >
> > Thanks for your help.
> > After struggling for a few hours I also managed to make my use case work.
> > Actually the test I was using was too fast, leading to 2 problems.
> > First, the 2 dispatch-routers didn't have time to establish the
> > inter-router route.
> > Second, randomly the consumers were not yet registered in the
> > dispatch-routers when the message was sent.
> >
> > Olivier
> >
> > -----Original Message-----
> > From: Gordon Sim <g...@redhat.com>
> > Sent: mercredi 17 avril 2019 12:39
> > To: users@qpid.apache.org
> > Subject: Re: [Dispatch-router] Multicast
> >
> > On 17/04/2019 8:50 am, VERMEULEN Olivier wrote:
> > > I have a question regarding the use of multicast with the
> > > dispatch-router.
> > > I have 2 dispatch-routers and 1 broker with a topic/queue configuration.
> > > All my addresses are configured as waypoints and the ones for the
> > > queue are also configured as multicast.
> > > When I put 2 listeners on the queue, 1 connected to each
> > > dispatch-router, only one of them is receiving the message...
> > > Is this supposed to be a supported use case? Am I missing something
> > > in the configuration?
> >
> > I tried this out with the attached config files and a broker on 7777
> > and it worked as expected. Two receivers, one on each router, both saw
> > all the sent messages.
> >
> > In this case there is only one broker and it is connected to by only
> > one of the routers. I did try with each router connecting to the
> > broker also, and that works as well. However, as expected, since the
> > address is multicast in both phases, the messages are duplicated (each
> > message is sent down both links to the broker).
> > *******************************
> > This e-mail contains information for the intended recipient only. It
> > may contain proprietary material or confidential information. If you
> > are not the intended recipient you are not authorized to distribute,
> > copy or use this e-mail or any attachment to it. Murex cannot
> > guarantee that it is virus free and accepts no responsibility for any loss
> > or damage arising from its use.
> > If you have received this e-mail in error please notify immediately
> > the sender and delete the original email received, any attachments and
> > all copies from your system.
> >
> > ---------------------------------------------------------------------
> > 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
>
> *******************************
> This e-mail contains information for the intended recipient only. It may
> contain proprietary material or confidential information. If you are not the
> intended recipient you are not authorized to distribute, copy or use this
> e-mail or any attachment to it. Murex cannot guarantee that it is virus free
> and accepts no responsibility for any loss or damage arising from its use.
> If you have received this e-mail in error please notify immediately the
> sender and delete the original email received, any attachments and all
> copies from your system.
>
> ---------------------------------------------------------------------
> 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
