Reports Apache Server Investigation & Findings.

The apache server on the Reports server logs are showing the following error :

[Thu May 23 13:07:16 2002] [error] OPM: EW: Fails to ping process with pid:4680.  Probably the process is hanging and can not response.  In most cases, the JVM is either heavily loaded or doing GC.  Please increase the jvm timeout value or decrease the jvm heap size to reduce the time of doing GC.  The process is about to be restarted.

Upon checking the httpd.conf everything looks fine. There are two additional lines for additional conf files to be loaded..

# Include the configuration for Apache JServ 1.1

include "C:\ORACLE\iSuites\Apache\Jserv\conf\jserv.conf"

 

# Include the Oracle configuration file for custom settings

include "C:\ORACLE\iSuites\Apache\Apache\conf\oracle_apache.conf"

The jserv.conf file is of interest to us and has the following values in it :

ApJServProperties "C:\ORACLE\iSuites\Apache\Jserv\conf\jserv.properties"

ApJServLogFile "C:\ORACLE\iSuites\Apache\Jserv\logs\mod_jserv.log"

ApJServVMTimeout 20

ApJServGroup group2 1 1 C:\ORACLE\iSuites\Apache\Jserv\conf\jservSoap.properties

All of which appear to be fine.  The ApJServVMTimeout could be extended however the default is 10 and so it has already been upped once.

The jserv.log file shows :

[23/05/2002 13:09:38:390 GMT+12:00] Repository c:\oracle\isuites\apache\apache\%SOAP_HOME%\webapps\soap\WEB-INF\lib\soap.jar doesn't exist!

[23/05/2002 13:09:38:390 GMT+12:00] ApacheJServ/1.1.2: Please define a servlet repository for servlet zone soap.

This is done by adding a "repositories=" line in the soap.properties file for the zone and defining it to be a path to a directory that exists on disk.

 

The mod_jserv.log shows:

[23/05/2002 01:07:16:640] (EMERGENCY) ajp12: ping: no reply (1)                 Please make sure that the wrapper.classpath is pointing                 to the correct version of ApacheJServ.jar

Upon checking the jserv.properties file I found this line:

wrapper.classpath=C:\ORACLE\iSuites\Apache\Jserv\ApacheJServ.jar

This indicates the line is correct as that file does indeed exist. Checking its version however is a little trickier. This however may be a symptom rather than a cause.

The below lines are found in c:\oracle\isuites\soap\webapps\soap\web-inf\config\soap.properties.

repositories=%SOAP_HOME%/webapps/soap/WEB-INF/lib/soap.jar

singleThreadModelServlet.initialCapacity=5

singleThreadModelServlet.incrementCapacity=5

singleThreadModelServlet.maximumCapacity=10

I have not been able to find where %SOAP_HOME% is defined in any confs and it’s not in the environment variables either.

The home of soap is c:\oracle\isuites\soap.

C:\Oracle\ISuites\Soap\Webapps\Web-Inf\Lib does contain a file called soap.jar.

Recommendations

Change request will need to be made to address the following errors and resolutions. The time frame for this should be minimal as the confs can be changed without effecting the services, and then the services can be restarted. The services are already loading ok with these problems so I do not expect changes to these areas to cause the service to not start at all.

[23/05/2002 13:09:38:390 GMT+12:00] Repository c:\oracle\isuites\apache\apache\%SOAP_HOME%\webapps\soap\WEB-INF\lib\soap.jar doesn't exist!

I think any reference to %SOAP_HOME% should be changed to C:\Oracle\Isuites\Soap…..  ie hard encode it.

“Please increase the jvm timeout value or decrease the jvm heap size to reduce the time of doing GC”

I found the jvm timeout in the jserv.properties file and this could be upped again. The heapsize is no where to be found unless the soap.properties thread parameters are about this.

[23/05/2002 01:07:16:640] (EMERGENCY) ajp12: ping: no reply (1)                 Please make sure that the wrapper.classpath is pointing                 to the correct version of ApacheJServ.jar

There is another jserv dir under C:\Oracle\Isuits\Apache2 directory that has the ApacheJServ.jar file of different size and date. This could be pointed to instead of the current one for testing, however I still think this is a red herring myself. Only testing will tell.

Not sure what actually fixed this in the end but this is a good example of how I troubleshoot and look around.