>>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). I tried this, and it works great. Instead of each application having to potentially load and initialize its own JVM and POI library, the C library they call RPC's out to a single app that has (after the first call) already done it, and that app does the actual POI work. Saves time and cuts down on memory usage. Which brings me to a new point. After creating the first XLS, the memory usage of the process that does this jumps by about 20MB (this is on AIX using java5 - memory usage as reported by 'ps aux'). After subsequent calls, memory usage goes up some more each time. But not the same amount, even though I'm producing the same XLS file over and over. The jump ranges from as little as 8KB to as much as 10 MB. Is this standard for Java, or is java just that leaky - or both? I've added a feature that counts up uses of my XLS-generator and forces it to shutdown and respawn after 50. So whatever memory leaks there are won't be a serious issue for me. Just wondering, though, is this kind of sloppiness standard stuff for java? Or is it because of JNI limitations - or a bad implementation on AIX? Of course, it's possible the leaks are mine (or POI's?). -- View this message in context: http://www.nabble.com/Using-POI-via-JNI-tp20774758p20941593.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]
