Figure out how to handle classes loaded from the KryoNet client's update thread

Description

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:

  1. Pre-load all needed classes for the KryoNet in another thread

  2. 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.

Environment

None

Activity

Show:
Ivan Senic
April 28, 2016, 1:28 PM

Any idea who to solve this? Problem is that the update thread of the Client is trying to load a class (most likely java.util.concurrent.LinkedBlockingQueue.Itr.Itr) this class is sent to the CMR and update thread instead of getting the result of this code waits there in the class loading.. It's a loop

What I am not getting is how is possible that this class is not loaded with our class loader? Shouldn't be the case? Or at the end it will anyway be delegated to the boot class loader for loading? Because if it would be loaded with our CL, then in the transform method we would not analyze the class.

Is maybe this pre-load classes thingy way to go?

Patrice Bouillet
April 29, 2016, 5:53 AM

Our classloader is most likely the initiator, but not the one who is really trying to load it then as the java classes have to be loaded from the bootstrap classloader (which is good, we don't want it different). Pre-load classes could be a way to go here, yes, but maybe there is a better way (as we never can be sure which classes need to be preloaded all the time). An idea could be to have some kind of "dry run" with the server where all the services are executed and while doing this, the instrumentation is deactivated for this timeframe. Thus everything needed from the Agent side could be loaded and then we can resume the instrumentation of classes afterwards.

But your mentioned retransform could be the solution anyway as this would be then active for all classes, or?

Ivan Senic
May 25, 2016, 1:04 PM

Ready after is integrated. Solved with pre-loading class. This fix makes Xentry agent to run without any errors or warnings.

Assignee

Ivan Senic

Reporter

Ivan Senic

Labels

None

Integrator

Patrice Bouillet

Components

Sprint

None

Fix versions

Affects versions

Priority

Lowest
Configure