This problem is introduced with INSPECTIT-1919.
If the class loading is initialized from the update thread of the KryoNet client then we will fail during sending this class to the CMR. Problem is that the update thread can not be one sending this to the CMR and waiting for the response. Thus, KryoNet throws exception immediately and does not sent this class type to the CMR.
I see two possible solutions:
Pre-load all needed classes for the KryoNet in another thread
Add check for the thread loading the class and have the thread back-list. For now just ignore those classes, but in future use re-transform in this cases to fire class loading with VM thread.