Manually checking the MQ Version information in the WebSphere MQ JAR files

Manually checking the information in the WebSphere MQ JAR files 
Alternatively, you can check a specific JAR installed as part of WebSphere MQ to find out the version information. The JAR to check is shown below: 

WebSphere MQ classes for Java: com.ibm.mq.jar 
WebSphere MQ classes for JMS : com.ibm.mqjms.jar 

Both of these JARs are located in the directory MQ_INSTALLATION_PATH/java/lib. 

Once the JARs have been located, follow the procedure below: 

1) Unjar the appropriate JAR using one of the commands shown: 

WebSphere MQ classes for Java: 
#jar -xvf com.ibm.mq.jar 

WebSphere MQ classes for JMS: 
#jar -xvf com.ibm.mqjms.jar 

2) Enter the uncompressed jar directory. This will contain a subdirectory called META-INF, which has a file in it called MANIFEST.MF. 

3) Open this file, and look for a line similar to the ones shown below. These lines indicate which version of the WebSphere MQ classes for Java or classes for JMS are being used by your application: 

WebSphere MQ classes for Java - com.ibm.mq.jar 
Specification-Title: WebSphere MQ classes for Java 
Specification-Version: 7.1.0.0 

WebSphere MQ classes for JMS - com.ibm.mqjms.jar 
Implementation-Title: WebSphere MQ classes for Java Message Service 
Implementation-Version: 7.1.0.0 - k000-L111005.1 

Mark-and-Sweep Garbage Collection

 mark-and-sweep  garbage collection algorithm

 The mark-and-sweep algorithm was the first garbage collection algorithm to be developed that is able to reclaim cyclic data structures.gif Variations of the mark-and-sweep algorithm continue to be among the most commonly used garbage collection techniques.

When using mark-and-sweep, unreferenced objects are not reclaimed immediately. Instead, garbage is allowed to accumulate until all available memory has been exhausted. When that happens, the execution of the program is suspended temporarily while the mark-and-sweep algorithm collects all the garbage. Once all unreferenced objects have been reclaimed, the normal execution of the program can resume.

The mark-and-sweep algorithm is called a tracing garbage collector because is traces out the entire collection of objects that are directly or indirectly accessible by the program. The objects that a program can access directly are those objects which are referenced by local variables on the processor stack as well as by any static variables that refer to objects. In the context of garbage collection, these variables are called the roots . An object is indirectly accessible if it is referenced by a field in some other (directly or indirectly) accessible object.

com.bea.wli.sb.transports.TransportException: [OSB FLOW Transport:2030702]Unexpected error, the Split-Join transport configuration descriptor cannot be loaded. Root cause: "File not found

Issue : 

when deploying OSB project

Caused by: com.bea.wli.sb.transports.TransportException: [OSB FLOW Transport:2030702]Unexpected error, the Split-Join transport configuration descriptor cannot be loaded. Root cause: "File not found
Solution:
Please restart the All Domain Servers and redeploy the application.

BPM roles are not updating Properly

Issue: BPM roles are not showing properly for all BPM servers.

Solution: 

Please validate system-jazn-data.xml (location: $DOMAIN_HOME/config/fmwconfig) 

into all Managed Servers and Admin Server.And update 

Oracle Fusion Middleware: Undeploy the composite When soa_infra in down

Oracle Fusion Middleware: Undeploy the composite When soa_infra in down: Check the SOA logs and determine which composite is causing the problem and then follow the below process to undeploy the composite by edit...

Undeploy the composite When soa_infra in down

Check the SOA logs and determine which composite is causing the problem and then follow the below process to undeploy the composite by editing deployed-composites.xml:

1. Download and copy the ShareSoaInfraPartition.ear file to $MIDDLEWARE_HOME/oracle_common/common/bin

2. cd to $MIDDLEWARE_HOME/oracle_common/common/bin

and

run wlst.sh

3.

connect('weblogic','weblogic1','t3://localhost:7001')


provide the username, password and server URL

4. run the below command to deploy ShareSoaInfraPartition.ear

deploy('ShareSoaInfraPartition','ShareSoaInfraPartition.ear',upload='true')


5. Now run the below command by changing the "toLocation" ('/fmw11g/fmw1115/Middleware' is some location path on SOA machine)

exportMetadata(application='ShareSoaInfraPartition',server='AdminServer',toLocation='/fmw11g/fmw1115/Middleware',docs='/deployed-composites/deployed-composites.xml')


6. A deployed-composites folder will be created at "toLocation" path with deployed-composites.xml in it

7. Delete the composite which is causing the problem and save the file

For example, the MediatorTest composite:

<composite-series name="default/MediatorTest" default="default/MediatorTest!1.0">
<composite-revision dn="default/MediatorTest!1.0" state="on" mode="active" location="dc/soa_58b98be8-9ec8-41af-bb83-590f6004d1aa">
<composite dn="default/MediatorTest!1.0*soa_58b98be8-9ec8-41af-bb83-590f6004d1aa" deployedTime="2011-11-17T09:01:54.750+05:30"/>


8. Now run the below command by changing the "fromLocation" (this should be the same location as previous)

importMetadata(application='ShareSoaInfraPartition',server='AdminServer',fromLocation='/fmw11g/fmw1115/Middleware',docs='/deployed-composites/deployed-composites.xml')


9. Now bounce your server and the composite will not be deployed by SOA when it comes up and hence that should bring your soa-infra up.

Connection test failed with the following exception: weblogic.common.resourcepool.ResourceDeadException: 0:weblogic.common.ResourceException: Could not create pool connection. The DBMS driver exception was: Listener refused the connection with the following error: ORA-12514, TNS:listener does not currently know of service requested in connect descriptor

Error


 Connection test failed with the following exception: weblogic.common.resourcepool.ResourceDeadException: 0:weblogic.common.ResourceException: Could not create pool connection. The DBMS driver exception was: Listener refused the connection with the following error: ORA-12514, TNS:listener does not currently know of service requested in connect descriptor


Solution

The DB Service went down abrublty as This exception is generated when an application request to get a connection fails because the connection selected to be returned to the application from the pool fails the configured tests.

Weblogic tests a connection before it is given to a client.

DB needs to restart.

Find the Hostname with IPAddress

[test@srinfosoa01 logs]$ nslookup srinfosoa01
Server:         128.166.33.44
Address:        128.166.33.44#53



nslookup 208.77.188.166 
...
Non-authoritative answer:

166.188.77.208.in-addr.arpa     name = www.example.com.

oracle.bam.adc.common.exceptions.CacheException: BAM-01265

Error 

Caused by: oracle.bam.adc.common.exceptions.CacheException: BAM-01265: An error (weblogic.common.resourcepool.ResourceDeadException: 0:weblogic.common.ResourceException: Could not create pool connection. The DBMS driver exception was: Listener refused the connection with the following error:
ORA-12514, TNS:listener does not currently know of service requested in connect descriptor
 ) has occurred in the Active Data Cache storage system.

When you found the above issue 

Cause: 

Message icon - Warning Test of BAMDataSource on server bam_ms01 failed, reason:

Message icon - Error Connection test failed with the following exception: weblogic.common.resourcepool.ResourceDeadException: 0:weblogic.common.ResourceException: Could not create pool connection. The DBMS driver exception was: Listener refused the connection with the following error: ORA-12514, TNS:listener does not currently know of service requested in connect descriptor

Solution


Please check with BAMDataSource, there is an issue with DB connectivity .

Data source should be available