It is quite common for Oracle Tech support, while troubleshooting any 11i E-Business Suite Self Service Applications (SSWA) related error messages, to ask to enable debug logging in JServ configuration files.
The procedure to enable debug logging in JServ is to update following line in file
log=true, and then bounce Apache using:
$ cd $COMMON_TOP/admin/scripts/$CONTEXT_NAME $ adapcctl.sh stop $ adapcctl.sh start
After the bounce, we start seeing debug messages in the log file
Please note, the logfile’s and config file’s locations can be different from those mentioned above. In case you have a shared tech stack implemented, replace
The main problem with this procedure is the bounce of Apache. In cases where the client is not a heavy SSWA user and the issue isn’t affecting a significant number of users, then often we will be asked to wait until off-business hours to do the bounce of Apache. These delays can make your metalink SR hop between different Oracle support offices in different timezones, which can lead to delays in resolution of the issue.
Let’s have quick review of JServ configuration files which are of interest to us.
jserv.conf — this is the configuration file of
mod_jserv module in Apache. Here’s a snippet from
# jserv.conf ApJServGroup OACoreGroup 1 1 /test/prodora/iAS/Apache/Jserv/etc/jserv.properties ApJServGroup DiscoGroup 1 1 /test/prodora/iAS/Apache/Jserv/etc/viewer4i.properties ApJServGroup FormsGroup 1 1 /test/prodora/iAS/Apache/Jserv/etc/forms.properties ApJServGroup XmlSvcsGrp 1 1 /test/prodora/iAS/Apache/Jserv/etc/xmlsvcs.properties
Its syntax is as follows:
ApJServGroup groupname num_of_jvms weight configuration_file. In the above example, each group gets one JVM started and this JVM reads parameters from the corresponding configuration file.
Here is a trick that you can use to make changes in
xmlsvcs.properties take effect immediately. Each of the JVMs that gets started has a logfile in the
$ ls |sort DiscoGroup.0.stderr DiscoGroup.0.stdout FormsGroup.0.stderr FormsGroup.0.stdout OACoreGroup.0.stderr OACoreGroup.0.stdout XmlSvcsGrp.0.stderr XmlSvcsGrp.0.stdout
So let’s say you want to make changes in
jserv.properties. In effect, the corresponding log file is
OACoreGroup.0.stdout, so find the process that’s writing to this and kill it. Here’s how:
$ /sbin/fuser OACoreGroup.0.stdout OACoreGroup.0.stdout: 21433 $ /sbin/fuser -k OACoreGroup.0.stdout OACoreGroup.0.stdout: 21433 $ /sbin/fuser OACoreGroup.0.stdout OACoreGroup.0.stdout: 22194
The PID of the JVM that was writing to the log file was 21433; we killed it using
fuser -k. The JVM gets restarted immediately by the
mod_oprocmgr module, and we can see the new JVM pid in effect.
The procedure we followed here saved us a complete bounce of Apache, but unfortunately, for changes in
jserv.conf to take effect, we still need a complete Apache bounce. This trick will only work for files
Interested in working with Vasu? Schedule a tech call.