The Jetty in the masquerateIT will not start with inspectIT as agent due to the strange bug during the Selector select method.
Seams that this bug is well know:
Also the only existing issue on the kryonet is exactly this one: https://github.com/svn2github/kryonet/issues/1
We should try to implement the workaround specified in above links as we control the code in our kryonet connection class. We could also then propose to solve the issue with-in the kryonet itself.
The fix proposed in https://github.com/netty/netty/commit/ff3f2b6361a48dc61956999945df0d2e9e2d4886 is not helping overcoming this problem.. I also tried updating the to Java 1.8.0_65, but this also does not work..
After all I am not even sure what's the problem in fact, we are only guessing that's this Selector thingy, but we don't know for sure..
This bug seams to be what we are hitting: http://webcache.googleusercontent.com/search?q=cache:RsivOFbLWigJ:https://bugs.eclipse.org/bugs/show_bug.cgi%3Fid%3D357318+&cd=3&hl=en&ct=clnk&gl=rs&client=ubuntu
Tried two more things today..
Ported masqueradeIT to my computer, same problem exists.. Thus, we rule out the VM/OS problems..
Tried to connect to CMR that is not located on localhost, but somewhere else on the network
Same problem appears in both cases when the agent is connected to the java process But at least now I can debug it in my environment and easily change agent, etc..
What do you think about the priority of this ticket? Should we consider it high and continue until problem is located or leave it for later?
Maximum Priority imho. Not working -> not good
At the following place the app get's stuck.. Here we are loading the org/eclipse/jetty/io/nio/SelectorManager$SelectSet$1 class and from then on we get no class loaded anymore.. We are not adding any byte-code..
As soon as the class is loaded, the following thread seams like spinning in the EpoolWait problem:
What I don't get is how this as anything to do with our agent.. As it's working obviously without it..
After investigation with we came to the conclusion that actually problem is that class loading delegation at the moment is not active for the java.lang.ClassLoader.. Because of this loading of some application classes does not work and thus the application does not start correctly -> meaning that jetty is not blocked, it's just not loading all app resources.
Easy solution for this until now was to add
however, we can have an easy fix to make it work even without the given property. This would make a huge benefit for the users as in any OSGi container it will work no matter of the property.