> > >> if it is in native code, it might not be showing properly actually >
We don't have any JNI code in our code base. Is there something else native I could/should be looking at? > hmm.... I find that unlikely. Either the classes in the jars are defined > by different class loaders, then they are different classes, or they are > loaded by the same class loader, in which case the jit still sees only one > set of classes... which might be from different jars of course, but that > should not matter... In other words, the origin should not matter > OK, I will keep the theory in mind, but won't pursue it further. > you know, you can easily test your theory. Remove the non-indy jar from > the classpath and let the application run with indy. If the slow downs, > then do not appear anymore you are right. > > I thought it would be easy to test as well. On my dev machine I have run three separate combinations: 1) Indy compilation + indy jar only, 2) Indy compilation + indy jar + non-indy jar, and 3) Non indy compilation + non-indy jar. Option #2 is the configuration that was causing the problem earlier. However, I was not able to replicate the problem. However, this is not an exact comparison different OS, slightly different JVM build numbers, along with the fact that it is inherently difficult to replicate actual load from real users. Unfortunately there is no way I will be able to run the Indy compiler + Indy jar in our production environments any time soon. Until I can prove that configuration can avoid the problem under substantial load in identical configurations indy will be kept out of production. > I find it unlikely, but you never know unless you verify it ;) > > I wonder how we can get to the ground of this. > Thanks for the reply. If I think of something I will post back.
