java.lang.StackOverflowError when using Kryo to serialize objects with references to each other

Question

I have a graph-like object that I'm sending from server to client that contains nodes that have adjacencyLists.

I have something similar to this:

Clearing c1 = new Clearing(1, 134, 151);
Clearing c6 = new Clearing(6, 250, 88);

c1.adjacentByPath.add(new Path(1, c6));
c6.adjacentByPath.add(new Path(1, c1));

Each time I send the object that contains these clearings, I receive the following error:

Exception in thread "Server" java.lang.StackOverflowError
at com.esotericsoftware.kryo.Kryo.getRegistration(Kryo.java:448)
at com.esotericsoftware.kryo.util.DefaultClassResolver.writeClass(DefaultClassResolver.java:79)
    ......

Is there a workaround for this in Kryonet? Thanks

Tamworth

In case anyone in the future is wondering, I just used the JavaSerializer instead of Kryo for the objects with this problem and it worked fine – Tamworth

its late answer but I had encountered and fixed the problem (by seeing kryo docs) in the below way. If you are okay you can consider accepting the answer. so that it will be pointer to other users who had the same issue... Thanks – Dictum

Answer 1

It was late answer, but recently I encountered this and was able to replicate as well as fix.

---

This happens whenever large object graph is used in kryo serialization...

Fix :
1) Try to fix this by tail recursion examples here
2) Increase stack size by specifying Xss in vm options

-Xss1m( or increase as per your requirements) as suggested by Esoteric software documentation which developed Kryo

Very large object graphs :

Stack size

The serializers Kryo provides use the call stack when serializing nested objects. Kryo does minimize stack calls, but for extremely deep object graphs, a stack overflow can occur. This is a common issue for most serialization libraries, including the built-in Java serialization. The stack size can be increased using -Xss, but note that this is for all threads. Large stack sizes in a JVM with many threads may use a large amount of memory.

Imp Note for apache spark + Kryo users:

In case of spark I set SparkConf object spark.executor.extraJavaOptions=... (along with -Xmx -XX options) programmatically or you can also mention that in spark-default.conf

Dictum