JGroups Log Configuration

Even though you set "org.collaxa.thirdparty.jgroups” logging level from BPELConsole to minimum, still you will find that jgroup messages are logged in file. To have full control on JGroups logging, please perform the following steps:

• Stop the OC4J process using opmnctl

• Open the $ORACLE_HOME/j2ee/<oc4j_name>/config/j2ee-logging.xml file and add the following log handler for jgroups. You can change the path to any other directory. I have set it to $ORACLE_HOME/bpel/system/logs/jgroups folder where a log.xml will be created. This file will contain the jgroups log messages:

<log_handler name="jgroups-handler" class="oracle.core.ojdl.logging.ODLHandlerFactory">
<property name="path" value="%ORACLE_HOME%/bpel/system/logs/jgroups"/>
<property name="maxFileSize" value="10485760"/>
<property name="maxLogSize" value="104857600"/>
<property name="encoding" value="UTF-8"/>
<property name="supplementalAttributes" value="J2EE_APP.name,J2EE_MODULE.name"/>
</log_handler>


Add the following logger, immediately below the org.quartz logger:

<logger name="org.collaxa.thirdparty.jgroups" level="SEVERE" useParentHandlers="false">
<handler name="jgroups-handler"/>
</logger>

• Start the BPEL OC4J process using opmnctl and confirm the jgroups trace level messages in the $ORACLE_HOME/bpel/system/logs/jgroups/log.xml file.

• You can use the EM console to change the level for "org.collaxa.thirdparty.jgroups" to the desired level, or directly edit this file and change the level.

FTP Adapter connection Pooling

In order to setup connection pooling on a connection factory with “none” connection pool we will need to modify oc4j-ra.xml of the FTP adapter. We need to make sure that “keepConnections” parameter is set to true

<config-property name="keepConnections" value="true"/>

and we need to create connection-pool settings. Please note that you might find an empty node like

<connection-pooling use="none">
        </connection-pooling>

and you need to replace it with

<connection-pooling use="private"> 
            <property name="waitTimeout" value="300" />
            <property name="scheme" value="fixed_wait" />
            <property name="maxConnections" value="50" />
            <property name="inactivity-timeout-check" value="all" />
            <property name="minConnections" value="5" />
            <property name="inactivity-timeout" value="50" />
</connection-pooling>

Or create a shared connection pool say “ftpPool” as shown below

<connection-pool name="ftpPool">
      <property name="waitTimeout" value="300" />
       <property name="scheme" value="fixed_wait" />
       <property name="maxConnections" value="50" />
       <property name="inactivity-timeout-check" value="all" />
       <property name="minConnections" value="5" />
       <property name="inactivity-timeout" value="50" />
</connection-pool>

and then modify connection-pooling section as

<connection-pooling use="shared">
      <use-connection-pool>ftpPool</use-connection-pool>
</connection-pooling>’

It’s a good practice to configure connection pool while configuring connection factory for the first time. At that time it asks whether to use “private” or “shared” or “none” connection pool. If you make this selection during that time, you won’t be required to modify configuration files manually (which I discourage most).

Unable to login to BPEL or ESB Console after unsuccessful login

After providing invalid credentials at BPEL Console, BPEL Admin Console, or ESB Control, if valid credentials are entered, then every attempt to log in will result in the "Authentication Failed" error message.

Reason is that the OC4J instance uses the parameter  ‘-Doc4j.formauth.redirect=true’, and OC4J does not redirect correctly.  This invalid redirection prevents BPEL and ESB from being redirected to the correct page after a successful login attempt if there was a failed login attempt.

Workaround is you take login_error.jsp off from URL http://<host>:<port>/BPELConsole/login_error.jsp, So your URL would look like http://<host>:<port>/BPELConsole/. This will automatically log you in. Since the problem was with redirection and not with your credentials

Fix is to apply patch 7202167 from metalink. 

SOA Suite Log File Rotation

In <ORACLE_HOME>/opmn/conf/opmn.xml, apply the following changes for each OC4J you want to modify log file settings

• Add -Dstdstream.filesize=FILE_SIZE_IN_MB -Dstdstream.filenumber=TOTAL_NO_OF_FILES parameters in the <java-options>. For example, if you want to limit log file size to 10MB and total number of files to be created to 10 than add

-Dstdstream.filesize=10 -Dstdstream.filenumber=10

• Add -out and -err parameters to the <oc4j-options> to specify standard output and standard error log files.

-out $ORACLE_HOME/opmn/logs/soa_log.out -err $ORACLE_HOME/opmn/logs/soa_log.err

Apply the changes and restart OC4J. If you are just restarting OC4J make sure to reload opmn before restarting.

After restart you should be able to see log files soa_log_YYYY_MM_DD_HH_MI_SS.out and  soa_log_YYYY_MM_DD_HH_MI_SS.err created under $ORACLE_HOME/opmn/logs/<oc4j_name>_<group_name>_<jvm_id> folder.

Failed to lock the record, another user holds the lock.

Error

JBO-26030: Failed to lock the record, another user holds the lock.
oracle.jbo.AlreadyLockedException: JBO-26030: Failed to lock the record, another user holds the lock.

Cause

Two possible causes are:

1. transaction-config timeout is set too low
2. connection caching is enabled

Solution

• Increase the transaction timeout in server.xml to a large number

<transaction-config timeout="120000" />

• Set connectionCachingEnabled  property in /j2ee/OC4J_BPEL/config/data-source.xml to false

<property name="connectionCachingEnabled" value="false"/>