----------------------------------------------------------------
BEFORE YOU POST, search the faq at <http://java.apache.org/faq/>
WHEN YOU POST, include all relevant version numbers, log files,
and configuration files. Don't make us guess your problem!!!
----------------------------------------------------------------
"Williams, Murray Todd" wrote:
You are describing my problem xactly. I am using Sun's JDK 1.2.2 so it
uses green threads. I do not see the multiple javas but do see the
cycling of 8007 ports in netstat. I have opened an issue with Redhat and
they have gotten no where. I will work on that manual start of the JVM
and see.
Strangely enough, we have not had any problems with performance on some
machines but have seen them on others (i.e., tcp connections being blown
out and no new ones taken).
Thanks for the information!
Ben Ricker
> I've gone through the FAQ and the last three weeks of mailing list archives,
> and I've seen one person mention this problem, but no further discussion.
>
> I'm the (unofficial) maintainer of the RPM packages for Xerces, Xalan and
> Cocoon (these RPMs being built on top of the "official" JServ RPM that is
> posted on the java.apache.org web site. For the last few months I noticed
> something a little odd, but I didn't pay much attention. I've finally
> decided to look closer and I'm very concerned.
>
> I tried submitting a bug report on the automated web form, but I've tried on
> two days from two different locations (home and work) and I keep getting and
> error back telling me that all my form inputs are blank, so I guess that
> isn't working. Instead I've copied all the sections down here...
>
> ***Environment:***
> I have this occuring on two platforms: RedHat Linux 6.1 and 6.2 (Intel) and
> on
> LinuxPPC (specifically YellowDog) for the PowerPC. I recompiled the .src.rpm
> file
> on PPC to create the installation rpm. The Java environments include
> Blackdown's
> JDK 1.2.2RC4 on both Intel and PPC, as well as IBM's new JDK1.3 for Intel.
>
> ***Synopsis:***
> A bunch of zombie (defunct) jdk theads and constantly being created and
> destroyed.
>
> ***Full Description:***
> Once apache is started (/etc/rc.d/init.d/httpd start) the Jserv module also
> starts up the JDK (specified in jserv.properties). If the JDK is running
> with
> native threads, the problem is most visible. If you do a "ps aux" to examine
> the running processes/threads five or six times, you'll see that there is
> almost
> always a "[java <defunct>]" process with a new pid. I just did two "ps"
> statements one minute apart and in that time there were 20 java threads
> created and destroyed.
>
> The problem can also been seen by executing "netstat". You will see that
> there
> are about ten processes which are stuck in the TIME_WAIT state, waiting to
> time-out.
> For a while I thought the problem only existed with java native threads so I
> switched to green threads. Then I discovered that although there wasn't the
> new PID creation/destruction visible with "ps aux" but "netstat" was showing
>
> constantly newly created and destroyed IP bindings on port 8007.
>
> If, however, one sets jserv.conf ApJServManual "on" and launches the JDK
> manually, the problem does not happen, the threads do not get
> created/destroyed
> and "netstat" doesn't show about 10 defunct timed-out TIME_WAIT IP
> connections.
>
> ***How can we repeat this problem?***
> Install a fresh RedHat Linux 6.1 or 6.2. Install the ApacheJServ RPM from
> the official web site. Restart apache. This may or may not happen with
> hand-built
> installations. (I haven't tested that option.)
>
> Is this a known problem? I'm actually amazed that I didn't see if on the
> FAQ-o-Matic since I imagine a lot of people use the ApacheJServ RPM package.
> (And it might also exist on manual Linux installations!)
>
> I'd love to hear some feedback. I wish I knew more about writing daemon
> processes, 'cause I'd be willing to write a launcher/monitor/nuker to put
> under /etc/rc.d/init.d, but I don't want to get it wrong if I'm offering the
> workaround to the outside world. Besides, it kinda bites that manually
> kicking off the JVM doesn't seem to get proper classpath info from the
> wrapper.classpath= lines.
>
> Sigh.
>
> Murray Todd Williams
> Merck & Co., Inc.
>
> --
> --------------------------------------------------------------
> Please read the FAQ! <http://java.apache.org/faq/>
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Archives and Other: <http://java.apache.org/main/mail.html>
> Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
