You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 27, 2023. It is now read-only.
Looks like I might have stumbled upon an issue, possibly related to registrator, not quite sure yet. I notice Consul has 2 internal services registered consul-8301 (no tags) and consul-8301 (udp) which causes a map collision for 2 services by the same name on the same port (differing only in tags). If I use consul-client to query this service
Error getting response from consul. will retry in 10 SECONDS: java.lang.IllegalArgumentException: Multiple entries with same key: 10.0.0.154:8301=ServiceHealth{node=Node{node=i-713657a8, address=10.0.0.154}, service=Service{id=i-713657a8:consul-agent:8301:udp, service=consul-8301, tags=[udp], address=10.0.0.154, port=8301}, checks=[HealthCheck{node=i-713657a8, checkId=serfHealth, name=Serf Health Status, status=passing, notes=Optional.of(), output=Optional.of(Agent alive and reachable), serviceId=Optional.of(), serviceName=Optional.of()}]} and 10.0.0.154:8301=ServiceHealth{node=Node{node=i-713657a8, address=10.0.0.154}, service=Service{id=i-713657a8:consul-agent:8301, service=consul-8301, tags=[], address=10.0.0.154, port=8301}, checks=[HealthCheck{node=i-713657a8, checkId=serfHealth, name=Serf Health Status, status=passing, notes=Optional.of(), output=Optional.of(Agent alive and reachable), serviceId=Optional.of(), serviceName=Optional.of()}]}
at com.google.common.collect.ImmutableMap.checkNoConflict(ImmutableMap.java:150)
at com.google.common.collect.RegularImmutableMap.checkNoConflictInBucket(RegularImmutableMap.java:104)
at com.google.common.collect.RegularImmutableMap.<init>(RegularImmutableMap.java:70)
at com.google.common.collect.ImmutableMap$Builder.build(ImmutableMap.java:254)
at com.orbitz.consul.cache.ConsulCache.convertToMap(ConsulCache.java:150)
at com.orbitz.consul.cache.ConsulCache.access$200(ConsulCache.java:31)
at com.orbitz.consul.cache.ConsulCache$1.onComplete(ConsulCache.java:71)
at com.orbitz.consul.util.ClientUtil$1.completed(ClientUtil.java:134)
at com.orbitz.consul.util.ClientUtil$1.completed(ClientUtil.java:129)
at org.jboss.resteasy.client.jaxrs.internal.ClientInvocation$5.call(ClientInvocation.java:549)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
I'm tempted to change my app to avoid services related to Consul as they typically aren't of any use to the end app, but not sure if there is a cleaner way. Is this an expected use case or is my consul misconfigured? A bit scary since it would seem an accidental registration of a service could bring down the whole stack... maybe consul-client should handle this more gracefully, regardless. I could put in a fix if you want, to perhaps merge on the first occurrence of a service. What do you think?
The text was updated successfully, but these errors were encountered:
@rickfast
Looks like I might have stumbled upon an issue, possibly related to registrator, not quite sure yet. I notice Consul has 2 internal services registered consul-8301 (no tags) and consul-8301 (udp) which causes a map collision for 2 services by the same name on the same port (differing only in tags). If I use consul-client to query this service
Here is how the code is being used:
https://github.com/wildfly-swarm/wildfly-swarm/blob/master/topology-consul/runtime/src/main/java/org/wildfly/swarm/topology/consul/runtime/CatalogWatcher.java
This results in the following stack:
I'm tempted to change my app to avoid services related to Consul as they typically aren't of any use to the end app, but not sure if there is a cleaner way. Is this an expected use case or is my consul misconfigured? A bit scary since it would seem an accidental registration of a service could bring down the whole stack... maybe consul-client should handle this more gracefully, regardless. I could put in a fix if you want, to perhaps merge on the first occurrence of a service. What do you think?
The text was updated successfully, but these errors were encountered: