Open Byte-Lab opened 8 years ago
Hey @RichardH92 , I'm working on getting the build system working in #17 so we can easily build and run JCoz. Once that's done, this might be a good starter bug for you
The basic idea here is that when the RMI service uses the VirtualMachine API to find a list of processes (see https://github.com/Decave/JCoz/blob/master/src/java/src/main/java/com/vernetperronllc/jcoz/service/JCozServiceImpl.java#L68), it should not return itself in that list. We are also going to need a way to determine which of those services is running with the JCoz native agent and only return those rather than any other JVM process.
Note that #24 is slightly different from this bug because we should not be returning the same RMI service even if for some reason it is being profiled by JCoz.
So, I have been researching. I think to accomplish this and the other related issue #24, we will need to use System.setProperty("process.unique.id", uniqueId);
to assign the processes a unique PID.
Then, when calling VirtualMachine.list()
we will know which process is which.
Nice, that should work. You'll have to figure out how to call it (or something equivalent) from the native JVMTI layer. Something along the lines of http://www.hildstrom.com/projects/jni/index.html should work. You don't have to create the JNI environment - you can just call it from here: https://github.com/Decave/JCoz/blob/master/src/native/entry.cc#L229. Hopefully the SecurityManager won't get in your way.
Also, let's name the property something unique to JCoz, like System.setProperty("process.jcoz.enabled", JNI_TRUE);
just to keep namespaces separate.
Currently when you query a service for a list of JCozVMDescriptors, it also sends itself as an available process. We should not include the service in this list.