<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jul 6, 2017 at 5:47 PM, Gordon Sim <span dir="ltr"><<a href="mailto:gsim@redhat.com" target="_blank">gsim@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 06/07/17 16:35, Lohmann Carsten (INST/ECS4) wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
How many routers do you have? Is it just one? Did you change the type of the address (i.e. delete and recreate with a different type) while there were links still attached?<br>
</blockquote>
Yes, just one router. We apply the standard "kubernetes/enmasse.yaml" from EnMasse 0.11.2 and then register the addresses. There were no changes to the addresses afterwards.<br>
<br>
I think I found the problem here:<br>
Our deployment pipeline applies the "enmasse.yaml" and then waits until the "messaging" service exists<br>
(we added this so that resolution of ${MESSAGING_SERVICE_HOST} in our hono deployment yaml works).<br>
Directly afterwards the addresses get registered.<br>
<br>
And it seems that is too early - in the sense that the necessary EnMasse initialization is not ready at that point yet.<br>
When I put a delay before the address registration, everything works later on.<br>
<br>
Two question from this:<br>
- Do you have a hint on what the condition should be on which to wait before registering the addresses?<br>
Checking that "readyReplicas" of the "qdrouterd" deployment is greater zero?<br>
<br>
- Could it be considered a bug that the address registration request got on OK response at that point?<br>
Maybe there should have been a 503 response instead?<br>
</blockquote>
<br></span>
Could it be that the receivers are connecting before the addresses have fully propagated? (And therefore are subject to the default semantics?)<br>
<br>
The actual configuration of the routers is an async process, so the fact that the definition of the addresses is accepted ok does not mean they are immediately propagated.<br>
<br>
I think the bug therefore may be that the readiness indicated in the address status does not (yet) cover propagation to the router(s).<br></blockquote><div><br></div><div><br></div><div>Yes, the 'status': { isReady: true/false } in 0.11.2 does not cover router address propagation. This is fixed on master, where the router address configuration is checked as part of setting the isReady field as well.</div><div><br></div><div>Ulf</div><div><br></div></div></div></div>