Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
"PortableFactory[-22] is already registered" error w/ Spring Boot 1.4.2 & Hazelcast 3.7.x #10438
This issue is almost identical to #1826 except that I might have a bit more information:
The stacktrace is very similar:
Caused by: java.lang.IllegalArgumentException: PortableFactory[-22] is already registered! com.hazelcast.concurrent.countdownlatch.CountDownLatchPortableHook$1@1ed6352 -> com.hazelcast.concurrent.countdownlatch.client.CountDownLatchPortableHook$1@13dc0e at com.hazelcast.nio.serialization.PortableHookLoader.register(PortableHookLoader.java:84) at com.hazelcast.nio.serialization.PortableHookLoader.load(PortableHookLoader.java:51) at com.hazelcast.nio.serialization.PortableHookLoader.(PortableHookLoader.java:41) at com.hazelcast.nio.serialization.SerializationServiceImpl.(SerializationServiceImpl.java:85) at com.hazelcast.nio.serialization.SerializationServiceBuilder.build(SerializationServiceBuilder.java:174) at com.hazelcast.instance.Node.(Node.java:130) at com.hazelcast.instance.HazelcastInstanceImpl.(HazelcastInstanceImpl.java:92) at com.hazelcast.instance.HazelcastInstanceFactory.newHazelcastInstance(HazelcastInstanceFactory.java:92) at com.hazelcast.instance.HazelcastInstanceFactory.newHazelcastInstance(HazelcastInstanceFactory.java:72) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:166)
The issue was originally reported here:
A sample project that demonstrates the issue is also available here:
To duplicate, you want to
The main difference between this issue and #1826 besides version numbers is that this time the application at fault is an executable war. The issue does not present itself with using
Tracking this down, I realized that Hazelcast's
As you can see, there are two classloaders here: one that is used to launch the WAR, and another that deals with the embedded tomcat web application. They both attempt to load the same sort of resource/service and as a result, run into conflicts. The URIs used seem identical except that protocol perhaps.
This is way too deep for me to go any further, but perhaps, could hazelcast ignore duplicate resources/services such as
Your analysis was spot-on.
I think I understand what is going - Hazelcast loads resources embedded in the JAR.
Then it will use both classloaders to find resources. The problem is the
Hence the same physical resources from the same JAR appears as 2 distinct resources to Hazelcast.
Ideally Spring Boot should not present the same resources under 2 unique URLs.
You are right on all counts. That's exactly what I witnessed as well.
Some additional points:
One thing that is also peculiar about the sample project above is that it's not exactly itself an executable war. It wraps itself around an already executable war, using a Maven overlay. The overlay project as you may have also noticed does the following more or less:
All standard Maven stuff. Now, I am not 100% sure if that whole process messes up classloaders in some way, but given (2) absolutely does nothing with (1) in this case, the final result should be identical either way. To further confirm this theory, I abandoned the sample project above to remove all weirdness caused potentially by the Maven overlay process and the war plugin and simply ran the cas web application (built from source; not downloaded from central this time) with a
We have been running CAS and Hazelcast in production for many years for many deployments. It's always been a pleasure. Thank you for your follow through!
@mmoayyed: Are you a Spring Boot expert? Could you create a simple Hello-World style project loading a resource from a JAR and demonstrating the same physical resource is available under 2 distinct URLs?
I think that would help to pin-point the real root cause and perhaps a reason to open a new issue in the Spring Boot project.
I'm playing with #10444 - it does the job, but I am not sure if that's the right way to tackle the issue.
I am also facing similar issue, I want to upgrade to hazelcast 3. 8 but getting following exception when starting app. I am using spring boot 1.4.4.
Caused by: java.lang.IllegalArgumentException: PortableFactory[-10] is already registered! com.hazelcast.map.impl.client.MapPortableHook$MapPortableFactory@671f545b -> com.hazelcast.map.impl.MapPortableHook$1@c335b9
Hi, has this been fixed in 3.8.5 or is it due out in 3.9?
I am having similar issue:
@davisd123 that would be 3.9-GA (or 3.9 as you say). Until then you can try out the SNAPSHOT release to see if your issue is fixed : https://github.com/hazelcast/hazelcast#snapshot-releases
@mmedenjak hi - quick update - can't confirm if your suggestion is working or not (Springboot 2.0.0.M3 + Hazelcast 3.9-SNAPSHOT. The version of Payara (220.127.116.11) I'm using has Hazelcast 3.8.0 built in, and that looks like it's getting picked up first by the classloader.
If I can't sort this I'll switch to Tomcat and can then probably verify your solution... :)
@mmedenjak ok, I can confirm that the issue goes away with Hazelcast 3.9-SNAPSHOT and Springboot 2.0.0.M3.
Had a classloader issue with Payara - to fix with Glassfish/Payara, refer to the following guide to set the class-loader delegate="false": https://docs.payara.fish/documentation/extended-documentation/classloading.html