qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adel Boutros <Adelbout...@live.com>
Subject Re: Dispatch router 2-phase start
Date Mon, 15 May 2017 10:00:51 GMT
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 <gsim@redhat.com>
Sent: Monday, May 15, 2017 9:58:50 AM
To: users@qpid.apache.org
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: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message