1 Reply Latest reply on Aug 29, 2013 1:18 PM by Colm Divilly-Oracle

    question on apex listener configdir



      I have couple of questions related to apex.war configdir


      Question 1:

      My original config dir was like this


      java -jar apex.war configdir

      Aug 16, 2013 3:02:43 AM oracle.dbtools.common.config.cmds.ConfigDir execute

      INFO: The config.dir value is /as10g/apex_listener



      Now I changed it to this

      java -jar apex.war configdir /as10g/apex_listener_<sid_name>


      Prior to running the above command, I created the directory /as10g/apex_listener_of3dev


      This changed my cconfigdir to /as10g/apex_listener_<sid_name> from /as10g/apex_listener.

      Now I copied the contents of /as10/apex_listener to /as10g/apex_listener_<sid_name> (cp -r /as10/apex_listener/* /as10g/apex_listener_<sid_name> )

      Is it ok to copy the files and diretories like this after renaming configdir?


      Question 2:

      While moving this I noticed the following



      00000000.jdb je.info.0 je.info.0.lck je.lck


      There is a directory called bdb and another directory underneath it and some files.

      What is the meaning and signficance of this directories and files?


      Thank you


        • 1. Re: question on apex listener configdir
          Colm Divilly-Oracle

          A1: Yes that's fine, you can delete the bdb/ folder and it's sub-folders, see below.


          A2: These are transient storage files used by the Berkeley DB engine, which Listener uses internally. Each startup of Listener (since 2.0.2) creates a new temp folder under the bdb folder to store it's transient data. Also when starting up Listener will attempt to clean up any existing folders under bdb, that do not have an open file within.


          Previously in 2.0.1 and earlier all BDB files were stored directly in the bdb folder. This causes complications when attempting to run Listener in a clustered environment. If all the nodes shared the same configuration folder, then only the first node started in the cluster would work, because BDB needs an exclusive lock to it's data files, the first node would get this, and then the all other nodes would fail to obtain the lock and become non functional.


          So if you were using Listener 2.0.1 or earlier in a clustered environment the advice was to give each node its own configuration folder to avoid this problem.


          Now since Listener 2.0.2 the best practice is the opposite, if you are running listener in a clustered environment and all nodes connect to the same database(s) then each node should point to the same configuration folder (e.g an NFS folder share, with write access). This gives the advantage of it being easier to maintain consistent configuration across all nodes.