My Findings

For DB the sid is nothing but name of the database

when db was down it will through
weblogic.common.resourcepool.ResourceDeadException: Could not create pool connection. The DBMS driver exception was: [BEA][Oracle JDBC Driver][Oracle]ORA-12505 Connection refused, the specified SID (XE) was not recognized by the Oracle server. at weblogic.common.resourcepool.ResourcePoolImpl.checkAndReturnResource(ResourcePoolImpl.java:1445) at weblogic.common.resourcepool.ResourcePoolImpl.checkAndReturnResource(ResourcePoolImpl.java:1401) at weblogic.common.resourcepool.ResourcePoolImpl.reserveResourceInternal(ResourcePoolImpl.java:329) at


A complete message could not be read on socket: 'weblogic.rjvm.t3.T3JVMConnection'" on WebLogic :
weblogic.rjvm.PeerGoneException: ; nested exception is: java.io.IOException: A complete message could not be read on socket: 'weblogic.rjvm.t3.T3JVMConnection@12c22dd4', in the configured timeout period of '60' secs
at weblogic.rjvm.BasicOutboundRequest.sendReceive(BasicOutboundRequest.java:108)
at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:284)


for this we can increase timeout period by setting the parameters 
-Dweblogic.CompleteT3MessageTimeout=<value in seconds>
-Dweblogic.CompleteMessageTimeout=<value in seconds>


T3 Protocol in WebLogic Server:

T3 is Oracle WebLogic Server's proprietary RMI protocol. Basically, t3 protocol is a protocol that sits on top of Java RMI. There is some documentation available.
RMI communications in WebLogic Server use the T3 protocol to transport data between WebLogic Server and other Java programs, including clients and other WebLogic Server instances.
If you need to control T3 access through a firewall, you may use the protocol filter "T3".

Any two Java programs with a valid T3 connection—such as two server instances, or a server instance and a Java client—use periodic point-to-point “heartbeats” to announce and determine continued availability. Each end point periodically issues a heartbeat to the peer, and similarly, determines that the peer is still available based on continued receipt of heartbeats from the peer.

• The frequency with which a server instance issues heartbeats is determined by the heartbeat interval, which by default is 60 seconds.
• The number of missed heartbeats from a peer that a server instance waits before deciding the peer is unavailable is determined by the heartbeat period, which by default, is 4. Hence, each server instance waits up to 240 seconds, or 4 minutes, with no messages—either heartbeats or other communication—from a peer before deciding that the peer is unreachable.
• Changing timeout defaults is not recommended.

java.lang.NumberFormatException: null from the Embedded LDAP:

This is happens because of corruption of EmbededLdap file
we can fix this issue by removing replica.props under data/ldap/config else change the prop file add replica.num=0


Weblogic server dint support mixed jdk version for the same domain.
Message bridge cant work if u specify the name of domain and jms resources are same.


Some times we find that our access.log are not updating this is because the server buffer the logs upto its default value 8kb and once it fills then it directs to our disk. By putting these flags we can set the buffer size to 0
-Dweblogic.logging.bufferSizeKB={BUFFER SIZE (KB)}
-Dweblogic.logging.bufferSizeKB=0 


We can cahnge jdk to jrocket easily by changing the java home in setDomainEnv.cmd then the server will start using jrocket