Don't play with Lock Files in OAM 11g:
You must have had noticed that there are some files present in diagnostics folder or in webgate profile folder with an extension .lck.
Eg:
polltracking.lck
oblog.log.lck
ObAccessClient.xml.lck
Basically these lock files are required by the server process so as to perform the read/write lock operations.
In case they are unable to do so, it might cause an issue.
So what could be the reason that the process is not able to acquire lock on a file and what can happen in that case.
Scenario:
1) In the Oracle Webtier instance directory we have a diagnostics folder where the logging info is captured.
Path: <MiddlewareHome>/<Oracle_WebTier>/instances/<instance_name>/diagnostics/logs/OHS/ohs1
In the above mentioned directory we have another directory having some numeric name like -> 2517662326/
So what this contains & how come this name?
- Basically this folder contains lock files which are as follows:
- polltracking.lck
- oblog.log.lck
- ObAccessClient.xml.lck
- And the name of this folder is the result of Hash done on the instance_name absolute path i.e. /scratch/ckukreja/OracleNew/Middleware/Oracle_WT1/instances/instance1/diagnostics/logs/OHS/ohs1
- So the hash of above path is 2517662326 this.
Now at the time server process is coming up, it checks for the directory path where the .lck file can be created or lock can be acquired.
As we know that webgate is integrated to the web-server like OHS, OTD, DOMINO, IIS, APACHE etc, So like in case of OHS server, the httpd.worker process looks for the directory path in following sequence:
1) Webgate Lock Directive mentioned in webgate.conf
2) Lock Directive mentioned in httpd.conf
3) Default Lock Directive
This sequence info can be found in webgate.conf file present in <MiddlewareHome>/<Oracle_WebTier>/instances/<instance_name>/config/OHS/ohs1/webgate.conf
Abstract from webgate.conf:
# WebGateLockFileDir: Optional directive specifying the location to create
# webgate lock files.
#
# If configured, then all webgate lock files will be created under
# <WebGateLockFileDir>/<Hash of WebGateInstancedir>. The hash subdir is to
# ensure uniqueness for each webserver instance and avoid locking conflicts
# if two different instances have configured the directive with same value.
#
# If the dir does not exist before, will try to create it first. If dir
# creation failed or the directive not configured, for Apache based web
# servers, will check web server's LockFile directive (also optional), extract
# its dir and use <LockFile's dir>/<Hash of WebGateInstancedir> if exists or
# created successfully.
#
# If none of above is defined or exists, then webgate falls back to old model,
# i.e. use same location as original file that lock is based upon.
#
# This directive is useful when webgate instance is located on NFS mounted
# disks and performance greatly impacted. Configure it to local dir will solve
# the issue.
#
# WebGateLockFileDir "<some_local_dir>"
So lets say we have specified the entry in the httpd.conf file:
- Under mpm worker module
- LockFile ${ORACLE_INSTANCE}/diagnostics/logs/${COMPONENT_TYPE}/${COMPONENT_NAME}/http_lock"
Thus from here the location is identified & webgate will initialize & read-write lock to this directive only for its task.
Problem:
So what if while the server is up & running and some one tries to play with these locks intentionally or unintentionally. In that case its a problem.........!!!!!!!
Usually what we do is that we specify the lock file location to some /tmp or other directive which is listed in some cron job. And the time cron job executes it deletes the directory.
Thus while the process is running & such tampering is done, so when some user request lands to the web server, it will result in failure of user requests.
WebGate will again create this directory and subsequent calls will be success.
Precaution:
Always specify the lock file directory to such a place where it is a surety that the directory won't gets deleted while the server is running and catering users requests............................
Enjoy :-)
