oscerd commented on code in PR #27445:
URL: https://github.com/apache/camel/pull/27445#discussion_r4204213442
##########
components/camel-infinispan/camel-infinispan/src/test/java/org/apache/camel/component/infinispan/remote/InfinispanRemoteQueryTestSupport.java:
##########
@@ -78,4 +88,30 @@ public static boolean hasUser(List<User> users, String name,
String surname) {
return false;
}
+ /**
+ * Registers a protobuf schema with the Infinispan server, retrying on
transient errors. Under parallel {@code -T1C}
+ * builds the server's internal {@code ___protobuf_metadata} cache may not
be ready yet, causing connection or
Review Comment:
**The refused connects point to Podman host-network + IPv6 loopback, not
___protobuf_metadata readiness**
The failures in CAMEL-25344 (and in the re-run with this PR) look like a
different root cause from the `___protobuf_metadata` readiness one. Every
refused connect goes to `localhost/[0:0:0:0:0:0:0:1]:11222`, i.e. the IPv6
loopback on the fixed port 11222. A fixed 11222 means
`InfinispanLocalContainerInfraService` is in host-network mode, which
`isHostNetworkMode()` turns on for Linux + Podman: `port()` then returns 11222
and `host()` returns `container.getHost()` (`localhost`). The server binds IPv4
only (the image's `launch.sh` appends `--bind-address=0.0.0.0`), while the Hot
Rod client resolves `localhost` through Netty's round-robin resolver, which
picks randomly among all hosts-file addresses, and Fedora maps `localhost` to
both `127.0.0.1` and `::1`. So any connect that lands on `::1` is refused
however ready the server is. That fits what we see: it hits other IT classes
too (ConfigurationIT, KeyValueRepositoryIT, the Spring ITs), none of the
refused connects goes to `127.0.0
.1` (a server that was not up would refuse both), and CI on Docker (no host
mode) never sees it. A `___protobuf_metadata` cache that is not ready would
answer with a server-side error, not a refused TCP connect.
So the retry can only mask this for the two wrapped calls. Fixing it in the
test infra, e.g. having `host()` return `127.0.0.1` when `isNetworkHost` is
true (or making the server listen dual-stack), would cover every Infinispan IT,
and the retry is then probably unnecessary. Side note: the `Failed to register
Infinispan schema after PT1M of retries` lines do not mean a minute of retries;
`InfinispanRemoteManager.registerSchemaWithRetry` rethrows non-lifecycle
exceptions, `BackgroundTask.run()` returns false, and that message is printed
with the real cause dropped.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
