Hello Gordon,
With what you are proposing, the order of the configuration becomes critical because if the public listener is configured before the connectors and autolinks, I would have the same issue with the producer/consumer. So my management process would have to send the management commands in a predefined order. In the case of the 2-phase start, the order of configuration is irrelevant and the management is thus easier. Regards, Adel ________________________________ From: Gordon Sim <[email protected]> Sent: Monday, May 15, 2017 9:58:50 AM To: [email protected] Subject: Re: Dispatch router 2-phase start On 13/05/17 10:29, Adel Boutros wrote: > Hello, > > We have noticed a race conditon with the dispatch router's behavior. > If you have a producer and a consumer exchanging messages on a queue > configured on a broker and accessible via the router. The consumer and > producers are JMS clients configured with Failover options for retry. > If the router goes down, the retry mechanism will kick in until it is up > again. > > As we are configuring th addresses and connectors on the router dynamically, > the producer and consumer might connect to the router before the waypointed > address is created on it. In this case, a local address will be created on > the router. The clients would exchange the messages directly from the router > and the messages on the broker would never be consumed. > > I discussed this issue with Justin and Ulf during the RivieraDev conference > and we were wondering if it was possible to implement a 2-phase startup on > the router to avoid this issue. > In that case, the router would start but not accept any connetion except for > management. Once all dynamic configuration is done, we send a management > message to allow the router to start accepting connections. > > Any thoughts on this? You could do something similar already by defining a specific listener for management only in the static config, and then only define the 'public' listener for real clients once any other configuration has been done. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
