Iplanet

[Anon]

Iplanet aborts and restarts whenever I try to use any xml function

errors are

[06/Feb/2001:11:56:12] info (24982): Aborting JVM
[06/Feb/2001:11:56:12] info (24982): Exiting JVM due to: jvm_abort () and jvm.exitOnAbort > 0
[06/Feb/2001:11:56:12] info (24982): JVM exit statistics: AttachedThreads/Max=0/1, ActiveThreads/Max=0/1
[06/Feb/2001:11:56:13] info (25953): php4_init reports: Initialized PHP Module

Any ideas????

[Anon]

I get the a similar problem when I have more than 50 users on the system.
[24/Apr/2001:20:32:48] info ( 463): Exiting JVM due to: jvm_abort () and jvm.exitOnAbort > 0
[24/Apr/2001:20:32:48] info ( 463): JVM exit statistics: AttachedThreads/Max=1/1, ActiveThreads/Max=1/1

let me know if you figure it out.

[Anon]

Have you found any solution to iplanet JVM problem? I ran into the same one

[Anon]

No, I'm having to throw more hardware at the problem. Something to do with Java-script and threading but nobody has a real answer. Well, I paid i-planet $175/hr to help and they said that 50 users in a java-script environment is good. :<

[Anon]

Our Log is getting a fair share of these as well.

This is on Tru64 Unix. On this server we do not run any server side JavaScript nor JSPs, No server-side includes of any kind are enabled. Mostly C based cgi and a few servlets. Iplanet4.1 is patched to sp7.

This usually happens late at night or first thing in the morning and it is not just one event, it tends to log several abort messages at the time. Below is a small example.

They're Baaack!

[28/Jun/2001:22:24:13] info (32669): Aborting JVM
[28/Jun/2001:22:24:13] info (32669): Exiting JVM due to: jvm_abort () and
jvm.exitOnAbort > 0
[28/Jun/2001:22:24:23] info (26099): Aborting JVM
[28/Jun/2001:22:24:23] info (26099): Exiting JVM due to: jvm_abort () and
jvm.exitOnAbort > 0
[28/Jun/2001:22:24:33] info (28013): Aborting JVM
[28/Jun/2001:22:24:33] info (28013): Exiting JVM due to: jvm_abort () and
jvm.exitOnAbort > 0
[28/Jun/2001:22:24:35] info (27161): Aborting JVM
[28/Jun/2001:22:24:35] info (27161): Exiting JVM due to: jvm_abort () and
jvm.exitOnAbort > 0
[28/Jun/2001:22:24:38] info (29235): Aborting JVM
[28/Jun/2001:22:24:38] info (29235): Exiting JVM due to: jvm_abort () and
jvm.exitOnAbort > 0
[28/Jun/2001:22:24:40] info (22727): Aborting JVM
[28/Jun/2001:22:24:40] info (22727): Exiting JVM due to: jvm_abort () and
jvm.exitOnAbort > 0

[Anon]

i suspect this is due to the jdk version problem.

i'm installing iPlanet4.1 + php4.0.6. i ran into same situation when i add gd1.8.3 + libpng + zlib library.

i remember i've seen this error message before when dealing with PowerDynamo with iPlanet. The result is due to iPlanet only support jdk1.2, whereas the application plug-in is compile in jdk1.1 env.

i think similar case here. zlib is in jdk1.1. But i don't know how to get gd1.8.3 + zlib in jdk1.2 env. Any help ?

[Anon]

When it happenned to me, I didn't have permision to write to a folder. Check to see who you are running iplanet as (see Preferences, Network Settings in iplanet admin console), and if you are doing any reading or writting of files, make sure you have permission to do so.
Hope this helps.

[Anon]

Troy,
We're experiencing these problems too with iWS and use XML. Although, could you tell me what specific XML jar's your using in your project? Have you determined what method calls are causing this?
Thanks

[Anon]

Actually none, no XML was involved and no XML related jars in any classpath. I believe the problem has been reduced significantly due to some configuration changes on the server invloving the min and maxHeapSize values in jvm12.conf.

BEFORE
#jvm.minHeapSize=1048576
#jvm.maxHeapSize=16777216

On our system these were initially commented out, so I do not know what the default guess is going to be.

AFTER
jvm.minHeapSize=33554432
jvm.maxHeapSize=134217728

iPlanet makes no effort to give us any idea of appropriate values for this. Nor do they explain what the server does in the case that no values are specified (or when commented out which for some reason ours were).

After racking our brains over outOfMemoryError s and searching our servlets for \"leaks\" we determined that the
default behavior of memory allocation seemed to be sufficient for testing one or two servlets in a dev environment. Way too low for heavy production. Just raising the max did not solve very much either. The servlets would still periodicaly crash with ome s. Finally we raised the min as well and no more out of memory errors. The rate at wich we got jvm Aborts dropped significantly as well. However they still happen here and there.

We will be switching all remaining servers to Apache / tomcat so we have not taken the time to dig for the offending methods.

[Anon]

Thanks for the info. Did you happen to install SP7 or SP8 since then? There was a JVM memory leak bug fixed in one of those revisions that greatly helped fix a major memory issue consuming memory from the OS. Although, they of course blamed our code before this and said it was coicidental that this SP fixed the main problem. We're still getting JVM aborts though, so I'll look into again increasing the heap sizes. Sounds like a leak to me in their product that a large heap is covering up.

[Anon]

We've been running SP7 since shortly after it was released. But the admin has not had time to up to SP8. I don't think we'll get there before everything is migrated to Apache anyways.

Another source of our problems could be that on Tru64 (DEC Alpha) we are supposed to turn on "serializeFirstRequest" so that init is only called once and only one request actually loads the servlet. The serializeFirstRequest setting is bugged until SP8 so we cannot turn it on without causing other problems.

[Anon]

Any one know whats causes this problem.
Iplanet 4.19
JRE1.3

Exiting JVM due to: jvm_abort () and jvm.exitOnAbort > 0
JVM exit statistics: AttachedThreads/Max=0/0, ActiveThreads/Max=0/0

[Anon]

Have you had any luck researching this? We are periodically getting a similar message:

Exiting JVM due to: jvm_abort () and jvm.exitOnAbort > 0
JVM exit statistics: AttachedThreads/Max=2/4, ActiveThreads/Max=2/4