Vertx zookeeper error #63
Comments
|
Hi Thanks. |
|
Yes,i upgrade vext.x from 3.4.2 to 3.5.0. Now i'm running version 3.5.0 |
|
We using Java serialization to save object into the zk, this issue would be happen if there are multi version vertx-zookeeper in one cluster, you have to restart all the verticle with latest version of vertx-zookeeper. |
|
I also encountered this problem. And I also used a different version of vertx-zookeeper. Now I try to upgrade to the latest version of vertx-zookeeper, and I will give feedback after the results. |
|
In all the years we've been running vertx, first with Hazelcast and now with Zookeeper, this failure to connect to a running cluster unless you have the exact same minor version of vertx-hazelcast or vertx-zookeeper as every other verticle in the entire distributed system has been the major pain in the ass and IMHO an odd design choice. We heavily use eventbus message passing between verticles but don't attempt to share state - it might be more effective to use an external messaging service and not cluster the verticles. Of course this is totally doable but seems to defeat what I took as a core capability of Vertx. |
|
I have the same version across the entire cluster, but this issue occurs when I redeploy one of the members. So far the only way to resolve it is to redeploy every node in the cluster. I am currently on version 3.9.1. Is there anyone looking into this issue. I agree with ijl20. this is a severe problem, and like his system, we are only using clustering for event bus message passing. This is my exception that i am seeing: |
This exception should have been swallow and make a WARNING to log. |
|
The problem is not just the exception, in my case I have a JVM instance that calls eventBus.request to an address being consumed by a set of JVMs, when I restart the consumers, the requests to that address fail with timeout exceptions. It appears that the only way to resolve it is by also restarting the requester JVMs on other instances. In my case, it is a normal course of business to update the consumers in the cluster. I imagine this is a common thing. All of this runs on AWS Fargate, so its important to note that IP addresses change when i restart the service. |
|
the sending Vertx instances continue to attempt to send the request to the old IP address that went away. This is permanent, there is no recovery unless I restart the sender. |
|
can you provide a reproducer ?
…On Sun, Jun 21, 2020 at 5:17 AM Manuel Elaraj ***@***.***> wrote:
The problem is not just the exception, in my case I have a JVM instance
that calls eventBus.request to an address being consumed by a set of JVMs,
when I restart the consumers, the requests to that address fail with
timeout exceptions. It appears that the only way to resolve it is by also
restarting the requester JVMs. In my case, it is a normal course of
business to update the consumers in the cluster. I imagine this is a common
thing.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#63 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABXDCSZSZJHP356KB3YSC3RXV3WHANCNFSM4ECXDK7A>
.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I am using vertx with zookeeper as my cluster manager. Suddenly I started getting this excpetion in my logs:
ERROR io.vertx.spi.cluster.zookeeper.ZookeeperClusterManager - Failed to handle memberRemoved
io.vertx.core.VertxException: java.io.InvalidClassException: io.vertx.spi.cluster.zookeeper.impl.ZKSyncMap$KeyValue; local class incompatible: stream classdesc serialVersionUID = -472487054773491211, local class serialVersionUID = -6066652933022630380
at io.vertx.spi.cluster.zookeeper.impl.ZKSyncMap.get(ZKSyncMap.java:95)
How can I fix it?
Regards, Ido
The text was updated successfully, but these errors were encountered: