The Apex listener 1.1 (running WL 10.3.4.0) gives this error when it gets shutdown abruptly, or disconnected from its database. I remove the file and restart the managed server and this resolves it. Just wondering if there is anything else that could be done to avoid the issue.
Caused By: com.sleepycat.je.EnvironmentLockedException: (JE 4.0.103) /app/runtime/apex1/bdb The environment cannot be locked for single writer access. ENV_LOCKED: The je.lck file could not be locked. Environment is invalid and must be closed.
do you really receive that error when the APEX Listener loses its database connection? You'll probably get an error 500 in both cases, but the cause should be different in the database case and you should be able to get the APEX Listener back on with just restarting the application - or just by running the number of requests needed to invalidate any hanging connection from the pool, so it gets reconnected.
This leaves you with the problem with the "abrupt" shutdown. Just for curiosity: How does this happen?
Anyway, this is a common problem with the Berkeley DB in Java when the JVM-process holding that lock is still running. As far as I know, this can only be fixed by changing the lock-handling in the APEX Listeners code. I'm not sure if there is a way to get the "hanging" lock released without restarting the JVM, which in turn would result in the need to open and close the file upon each request to not hold the lock longer than needed. But this overhead would possibly cause performance problems.
Perhaps one of the developers can make a short statement on that issue...
It looks like you have more than one instance of Apex Listener deployed, and both instances are attempting to use the same APEX Listener configuration folder. The first instance gets the lock on the configuration folder and the second and subsequent instances fail to get the lock.
Prior to 1.1.1 there was a bug in the listener that caused multiple instances to use the configuration folder of the first deployed instance. Please ensure you are running the latest version (1.1.2 as of this writing) when deploying multiple instances.
Hope this helps:
On my case I found I had two java -jar apex.war process that did not exit gracefully when I completed the initial apex listener configuration on a ssh session side: and since I runt the java -jar apex.war twice then it created two process...
oracle 3662 699 0 11:09 pts/5 00:00:02 java -jar apex.war
oracle 3894 699 0 11:17 pts/5 00:00:04 java -jar apex.war
running I kill -9 these two then I was able to bypass the error: now my other challenge is that I get 404 - Not Found
when I tried to access the listener configure admin page: http://rhel6.urimagination.local:7001/apex/listenerConfigure
Edited by: Alf_URI on Feb 26, 2013 9:18 AM