Wednesday, November 30, 2011

Rotate .out log files

1) If you are using nodemanager you can redirect .out to .log and control them via console (server -> logging tab under console)
traverse to */user_projects/domains/base_domain/bin/nodemanager
take a backup of wlscontrol.sh and edit it
change OutFile=$ServerDir/logs/$ServerName.out to OutFile=$ServerDir/logs/$ServerName.log

ELSE

2) You can make changes to the OS parameters under /etc/logrotate.conf
add the below lines at the end of the file

<Location of logs directory>/*.out
{
copytruncate
rotate 4
size=20Mb
}

ELSE

3)Add the flag  -Dweblogic.log.RedirectStdoutToServerLogEnabled=true to redirect .out to .log and control them via console (server -> logging tab under console)
and if you are starting via nodemanager add below additional parameters
nodemanager.properties under */wlserver_10.3/common/nodemanager
StartScriptName=startWebLogic.cmd
StartScriptEnabled=true

ELSE

4)Use OS command "logrotate" (via cron) to achieve your target. You can combine it with copytruncate to rotate logs.
http://linuxcommand.org/man_pages/logrotate8.html

Monday, November 21, 2011

certicom is unable to read cacerts

Error msg:
java.io.IOException: PKIX: Unsupported OID in the AlgorithmIdentifier object: 1.2.840.113549.1.1.11
       at weblogic.server.channels.DynamicSSLListenThread.<init>(DynamicSSLListenThread.java:64)
       at weblogic.server.channels.DynamicListenThreadManager.createListener(DynamicListenThreadManager.java:289)
       at weblogic.server.channels.AdminPortService.bindListeners(AdminPortService.java:76)
       at weblogic.server.channels.EnableAdminListenersService.start(EnableAdminListenersService.java:39)
       at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)
       at weblogic.work.ExecuteThread.execute(ExecuteThread.java:201)
       at weblogic.work.ExecuteThread.run(ExecuteThread.java:173)
Caused by: java.security.cert.CertificateParsingException: PKIX: Unsupported OID in the AlgorithmIdentifier object: 1.2.840.113549.1.1.11
       at com.certicom.security.cert.internal.x509.X509V3CertImpl.<init>(Unknown Source)
       at com.certicom.tls.interfaceimpl.CertificateSupport.addTrustedCertificate(Unknown Source)
       at com.certicom.net.ssl.SSLContext.addTrustedCertificate(Unknown Source)
       at com.bea.sslplus.CerticomSSLContext.addTrustedCA(Unknown Source)
       at weblogic.security.utils.SSLContextWrapper.addTrustedCA(SSLContextWrapper.java:62)
       at weblogic.security.utils.SSLContextManager.createServerSSLContext(SSLContextManager.java:424)
       at weblogic.security.utils.SSLContextManager.getChannelSSLContext(SSLContextManager.java:336)
       at weblogic.security.utils.SSLContextManager.getSSLServerSocketFactory(SSLContextManager.java:91)
       at weblogic.server.channels.DynamicSSLListenThread.<init>(DynamicSSLListenThread.java:59)
       ... 6 more



After looking at the execption it seems that WLS 10.3 does not support cipher suite with Object ID 1.2.840.113549.1.1.11 (sha256WithRSAEncryption)
Please take a backup and replace the cacerts file located in JDK_HOME/jre/lib/security with the cacerts located file in WL_HOME/server/lib.

Looks like the 10.3.0.0 version of certicom is unable to read the cacerts of JDK 1.6 u29.

Monday, November 14, 2011

A version attribute is required

WLS 10.3.4 
error message:
<Warning> <Munger> <BEA-2156203> <A version attribute was not found in element webservices in the deployment descriptor in weblogic.utils.classloaders.ChangeAwareClassLoader@49e98c6d finder: weblogic.utils.classloaders.CodeGenClassFinder@65254b11 annotation: bea_wls9_async_response@bea_wls9_async_response.war/WEB-INF/webservices.xml. A version attribute is required, but this version of the Weblogic Server will assume that the JEE5 is used. Future versions of the Weblogic Server will reject descriptors that do not specify the JEE version.>

I applied the parameter -Dweblogic.wsee.skip.async.response=true in setdomainenv.sh
and error message disappeared. 
else you could always apply patch 11720907 or cumulative patch 12770299.

Wednesday, November 9, 2011

Timeout read connections from JDBC side on weblogic.

When a client requests data from the DB through a thread and there is no reply from the server the client indefinitely waits for the reply.
You can avoid this situation by timing out the thread from JDBC side. It will end up with a "Socket READ TIMEOUT" error so you don't indefinitely wait for a reply from server.Make sure the time period you set is strictly not shorter than any of the normal db queries of your application, else it will timeout normal connections.

oracle.net.READ_TIMEOUT
works for jdbc driver versions <=10.2
does NOT work for jdbc driver versions >= 11.1

oracle.jdbc.ReadTimeout
works for jdbc driver versions >= 10.1.0.5
Does not work for jdbc driver versions <10.1.0.5

You can set it in the JDBC_Data_*-jdbc.xml in the domain/config/JDBC folder. Timeout in miliseconds.

<jdbc-driver-params>
     <url>jdbc:oracle:thin:@localhost:1521:XE</url>
    <driver-name>oracle.jdbc.xa.client.OracleXADataSource</driver-name>
     <properties>
      <property>
        <name>user</name>
        <value>SYSTEM</value>
      </property>
      <property>
        <name>oracle.jdbc.ReadTimeout</name>
         <value>18000</value>
      </property>
     </properties>
    <password-encrypted>{3DES}s447QVesIco=</password-encrypted>
   </jdbc-driver-params>

also you can set it via console in

Admin Console -> JDBC Data Source: Configuration: Connection Pool, and set "Properties" as follows. Note to list each property=value pair on a separate line.


oracle.net.READ_TIMEOUT=30000 
oracle.jdbc.ReadTimeout=30000


To check the JDBC driver version:
 D:\work\wls\wlserver_10.3\server\lib>java -jar ojdbc6.jar
Oracle 11.1.0.7.0-Production JDBC 4.0 compiled with JDK6

Monday, November 7, 2011

Activate changes taking long time

Activate changes was taking forever....
I went ahead and deleted crc.ser and ver.ser under
user_projects\domains\base_domain\config\configCache.
Then i found out that the config.xml copy under the different jvm's present in other physical machines are not similar in size.
restart those jvm's whose config.xml size is not equal to that of the admins.
Activate changes is working fine now.