This content has been marked as final. Show 6 replies
I don't know any official document on that task (yet).
Derived from my personal experience, each APEX Listener instance needs its own home directory and its own config. You can share the images for your APEX instance between your APEX Listener deployments, but not the other two.
So your deployment can have a shared filesystem with +$HOME/apex_listener_<instance>+ (or no shared file system for that) and +$HOME/apex_images+ (or similar). Note that you should distribute the apex-config.xml manually in that scenario, as I'm not sure how stateful your clustering is when the config is rewritten after a change using listenerAdmin (especially in a situation where not all nodes are online).
So I did put a command line to delete bdb dir once the MS comes up to avoid the issue but really not sure if this is the right way at all?I wouldn't recommend that. You may be able to use APEX Listener anyway as long as you don't use the Resource Templates, because this bdb-file-database is used to store the definitions for them. But I don't think I'd feel fine with that kind of workaround.
On the other hand, with APEX Listener 2 (currently in EA-phase) the configuration for Resource Templates have been moved into the APEX SQL Workshop (APEX Workspace), so the bdb doesn't exist any longer. If you can live with your workaround until APEX Listener 2 gets production, this might be better than "splitting" the home per instance.
We have the same problem. Due to business requirements we need to deploy apex listener on WLS on one physical machine cluster with two managed servers. We are hitting "$HOME/apex/bdb The environment cannot be locked for single writer access" error and I've tried Oratime's work around without success. Since Apex Listener 2 is in production, I tried to resolve my problem with it. But Udo, sorry for that the bdb does exists... I tired "delete the direcory work around" with version 2 but the same results. dbd directory is still there and deleting does not end up with expected results. We will not be using REST services so there must be some kind of hack or work around to disable this behavior. I would like to hear a good solution from the community.
Edited by: tBodur on Dec 23, 2012 6:22 PM
I managed to fulfill my requirement..
If its a cluster on same machine or across machines, this should work
1. Login to machine, cd $DOMAIN_HOME
2. mkdir -p Apex_lsn_config/AdminServer Apex_lsn_config/<MS1> Apex_lsn_config/<MS2> # MS1 and MS2 are the Managed Server names as appropriate
#If you are planning for cluster spawning MS's across machines, make sure you create the dir's on step 2 for each machine respectively. (in my case $DOMAIN_HOME is not shared)
3. Copy apex-config.xml from the /tmp/apex or whatever location you have it currently to Apex_lsn_config/<MS1> Apex_lsn_config/<MS2>
4. cd $DOMAIN_HOME/bin; cp -p SetDomainEnv.sh SetDomainEnv.sh.orig #Backup the file
5. Append -Djava.io.tmpdir in SetDomainEnv.sh as below for JAVA_OPTIONS # Do it on both machine if you are not sharing DOMAIN_HOME and planning cluster across machines
Hint: Search for "iterativeDev" and append the same line with -Djava.jo.tmpdir
6. Modify "java.io.tmpdir" from the web.xml file of apex.war as below and re-deploy the war
7. Bounce Weblogic Admin and Manged Servers. Make sure to tail the Managed Server log to see apex-config.xml is picked from the new location.
8. Brew a Coffee for yourself :)
- You find the instructions on creating a cluster from weblogic documentation, the steps mentioned above are only to overcome the bdb locking issue whilst creating a cluster.
Did it help?
Edited by: Oratime on Mar 25, 2013 2:44 AM