Open vitaly-masterov opened 11 months ago
/cc @karesti (infinispan), @mkouba (scheduler), @wburns (infinispan)
I'll make a clarification. I did some more experiments. The influence of the scheduler has an indirect effect. Exactly the same effect occurs if the handler in which the cache is injected is launched in response to the arrival of a message from the message broker. Exactly such a bug appears if you make a REST call. You need to look for a problem precisely when using RemoteCache in the docker runtime environment. Everything works fine without docker.
So the root cause is Error creating synthetic bean [ddee68cd3f60c96290f55bc237588d70e5c96aab]: org.infinispan.client.hotrod.exceptions.TransportException:: io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection refused: /172.25.0.4:11222
thrown when the synthetic bean for org.infinispan.client.hotrod.RemoteCacheManager
is being created.
I don't think it's related to quarkus-scheduler
or any other extension but quarkus-infinispan-client
.
Could it just be a timing issue i.e. Infinispan not being available yet when trying to connect?
It looks like it's true. I changed docker-compose. Added to infnispan-server
healthcheck:
test: curl --fail http://172.25.0.4:11222/rest/v2/cache-managers/default/health/status || exit 1
interval: 10s
start_period: 30s
timeout: 10s
And in client-app added:
depends_on:
infinispan-server:
condition: service_healthy
And after that the error disappeared. Probably the client-app was unsuccessfully hooked to infinispan if it had not yet been fully launched.
I'm sorry I bothered you for nothing. The issue can be closed. But in any case, the message in the stack trace is not very informative, because of it it is impossible to understand what the problem is.
I tried to experiment and leave empty
quarkus.infinispan-client.hosts
the error is exactly the same.
It would be nice to check for this case, if the parameter is set incorrectly or not set at all, then issue an appropriate warning.
yes, this is true @vitaly-masterov sometimes error handling and understanding can be tricky with Infinispan. I'll try to work on this after PTO when I'm back in August, as well as other Infinispan retaled Quarkus issues. Let's keep this issue open meanwhile please @gsmet
Describe the bug
It looks like there is a bug when using quarkus-infinispan-client and quarkus-scheduler together. This bug only appears if the Infinispan client is running in a docker environment. If the Infinispan client is running outside of docker, then everything works fine. To reproduce the error, I took the infinispan-client-quickstart project as a basis.
Expected behavior
The normal behavior of a quarkus application with "quarkus-infnispan-client" and "quarkus-scheduler" running in a docker environment is expected to be the same as if it were launched without docker.
Actual behavior
This is the stack trace snippet after running docker-compose:
How to Reproduce?
Output of
uname -a
orver
Linux calculate 6.1.39-calculate #1 SMP PREEMPT_DYNAMIC Wed Jul 19 21:20:18 UTC 2023 x86_64 AMD Ryzen 5 3600 6-Core Processor AuthenticAMD GNU/Linux
Output of
java -version
11, 17
GraalVM version (if different from Java)
No response
Quarkus version or git rev
3.2.1.Final
Build tool (ie. output of
mvnw --version
orgradlew --version
)Apache Maven 3.8.6
Additional information
If I comment out this piece of code, then docker-compose starts without errors
and