>If it's just the distinct classpath you are worried about, you are not >forced to use separate JVMs. You can use plain JNI to: define >classes, create custom class-loaders, attach threads, etc. This would >allow you to get your code executing on an already existing JVM >regardless of its 'java.lang.classpath' system property. However, >other JVM options like "-Xmx..." etc may present hard barriers to >sharing a JVM.
Sounds complicated. Also, I'm getting JNI_NOMEM returned from JNI_CreateJavaVM on a second server I tried moving my code to, and have no idea why (same OS, same Java), so I'm not sure how clever I want to get with the JVM. >Have you considered having just one dedicated JVM process that is >shared by all the other app processes, and stays up permanently? The >downside is that you'd have to figure out the inter-process >communication, but you'd get to avoid the logic to decide when to kill >processes in order to create new JVMs. That's a really interesting idea. My transaction processing system has an RPC concept, where one process can call out to another process to handle a particular task. So the IPC mechanism's already in place. I think I could really do that and, if nothing else, eliminate the overhead of loading the JVM and my classes (a few seconds on my test system). Thanks, Rob -- View this message in context: http://www.nabble.com/Using-POI-via-JNI-tp20774758p20817083.html Sent from the POI - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
