Saturday, November 14, 2009

Installing Oracle Fusion Middleware Tips based on my experience with installing on Kubuntu 9.10

I have installed Oracle Fusion Middleware on my local Kubuntu 9.10 (64bit). This posting contains some tips based on my experience.

Please have a look here to find more details about where to find the new Oracle Fusion Middleware Release.

To install the new release you have to upgrade WLS to 10.3.2 and install the new SOA component again. I decided to throw everything away, download the complete new release including the new RCU and JDeveloper release (don't forget this component!) and install everything again..

Required software:
- Weblogic Server 10.3.2 generic (I have a 64 bit config)
- JDeveloper
- SOA Suite
- RCU (See additional software section)

Please follow the installation instructions, which can be found here, to install the components in the correct order.

JDK issues
With my default OpenJDK version (build#16) I encountered problems with the WLS installer and with starting the installer of the SOA Suite component.

The WLS installer only started in console mode:

tomhofte@tomhofte-laptop:~/downloads$ java -jar wls1032_generic.jar
Unable to instantiate GUI, defaulting to console mode.
Extracting 0%....................................................................................................100%

<-------------------- Oracle Installer - WebLogic ------------------->


This installer will guide you through the installation of WebLogic
Type "Next" or enter to proceed to the next prompt. If you want to change data entered previously, type "Previous". You may quit the installer at any time by typing "Exit".

Enter [Exit][Next]>

<-------------------- Oracle Installer - WebLogic ------------------->

Not really convenient...

When I tried to start the SOA Suite installer using my OpenJDK as the java runtime the following problem showed up in the console and the installer UI did not show up.

Starting Oracle Universal Installer...

Checking if CPU speed is above 300 MHz. Actual 800 MHz Passed
Checking Temp space: must be greater than 150 MB. Actual 47087 MB Passed
Checking swap space: must be greater than 500 MB. Actual 9507 MB Passed
Checking monitor: must be configured to display at least 256 colors. Actual 16777216 Passed
Preparing to launch Oracle Universal Installer from /tmp/OraInstall2009-11-14_08-16-57PM. Please wait ...
Please specify JRE/JDK location ( Ex. /home/jre ), /bin/java should exist :/usr/lib/jvm/java-6-openjdk
tomhofte@tomhofte-laptop:~/downloads/soa_11112/Disk1$ Exception in thread "main" java.lang.UnsatisfiedLinkError: Can't load library: /usr/lib/jvm/java-6-openjdk/jre/lib/amd64/xawt/

I assumed that something was wrong with my JDK version so I decided to install JRockit Realtime JVM version 6. After installing JRockit Realtime JVM version 6 and using this Java distribution for installing WLS and SOA Suite everything was able to install without any problems. The JRockit version I used is available from here.

Note: this will definitely not mean that FMW will only install with JRockit Realtime JVM version 6! It is only that this made it work for me and in case you hit the same issue you now how I solved it :)

Configuring JDeveloper

After I had installed JDeveloper, I noticed that the SOA Composite editor extension is not part of the JDeveloper bundle as it was with the previous to Help -> Check for Updates and select the SOA Composite editor extension:
Install the extension and restart JDeveloper to activate the update.

Activate the Preview Spring component designer
(Thanks to this posting)
To activate the Spring component in the Component palette of the Composite editor in JDeveloper, you have to change the soa-config.xml file that can be found in JDEV_HOME/integration/seed/soa/configuration. Uncomment the following the part and restart JDeveloper



All of the above did the job for me.

Tuesday, November 10, 2009

Monitoring Oracle AQ message systems with SQL based User defined Metrics in Oracle Enterprise Manager

By default Oracle Advanced Queueing (AQ) provides monitoring views (in this posting we use the V_$AQ view) to monitor things like
  • Number of waiting messages per queue
  • Number of expired messages per queue
  • Number of messages on status ready per queue
  • Average waiting time per queue
  • Total waiting time per queue
In large messaging systems it is important to detect possible delays and bottlenecks at an early stage. The above metrics can help you with this. Of course it is possible to write a custom monitoring application to make monitoring information accessible, but in most large environments it makes more sense to use a dedicated monitoring product that is able to monitor your complete application environment and provides a single monitoring console.

Oracle Enterprise Manager (OEM) is such a tool. OEM provides functionality to specify User-defined SQL-based metrics that allows you to easily integrate your own SQL monitoring scripts in OEM together with defined thresholds on the metrics, OEM will trigger alert notifications. The SQL queries below can be used for creating SQL based User-defined metrics in OEM to monitor specific queues on specific aspects:

-- Average wait metric
select, vaq.average_wait from sys.dba_queues dbaq, sys.V_$AQ vaq where in ('SOME_Q_A', 'SOME_Q_B') and dbaq.qid = vaq.qid

-- Total wait metric
select, vaq.total_wait from sys.dba_queues dbaq, sys.V_$AQ vaq where in ('SOME_Q_A', 'SOME_Q_B') and dbaq.qid = vaq.qid

-- Expired messages metric
select, vaq.expired from sys.dba_queues dbaq, sys.V_$AQ vaq where in ('SOME_Q_A', 'SOME_Q_B') and dbaq.qid = vaq.qid

-- Ready messages metric
select, vaq.ready from sys.dba_queues dbaq, sys.V_$AQ vaq where in ('SOME_Q_A', 'SOME_Q_B') and dbaq.qid = vaq.qid;

  • The queries are Two-Column queries and the Metric type is Number
  • Determine a correct value for Consecutive Occurrences Preceding Notification option to prevent false positives
  • Set a correct interval. Keep in mind that monitoring causes some minor don't set the interval too small.. 30 minutes should be sufficient in most scenario's

Set up a Weblogic Server 11g (10.3.1) JMS Store and Forward demo

Weblogic Server (supported from 9.x) contains JMS Store-and-Forward (JMS SAF) functionality. Basically this functionality makes it possible to receive messages on a specific server instance (proxy), forward the messages to different Weblogic server instances and process them on those 'hidden' instances or forward them again...In case the processing server is unavailable the message will be automatically redelivered when the server is available again..You can think about many use cases in which JMS SAF can be very useful. For example, in the situation in which you don't want to stop the message communication when an update of 'processing logic/functionality is needed, JMS SAF can increase the high-availability of your messaging solution. Also it can be used to off-load complex message processing to dedicated servers.

In this posting I will describe how you can set up JMS SAF using Weblogic Server 11g (10.3.1) with a domain configuration consisting out of 1 AdminServer and 2 non-clustered Managed Servers serve in the roles of sender (or actually the forwarder) and receiver.

I skip the domain set up and assume you are familiar with it. To define the JMS SAF resources the best thing to do is to follow the steps that are described Oracle Fusion Middleware 11g SAF guide. I will a not repeat them in this blog.. In its place, I will give additional explanation about specific configuration steps and things you have to do but which are not covered completely in the guide.

Receiving Side - Extra
  • Create a JMS Server
  • Create a Subdeployment in the receiving JMS module and target it to the JMS Server
  • Create a destination queue and remember the JNDI name that you choose. We need it when the sending side will be configured. Target the queue to the JMS module's Subdeployment
  • Create also Connection factory at the receiving side (At least I did it. However, you could try not to create a connection factory, because the sending side never uses it..). In the picture below you can see the configuration of the JMS resources at the receiving side that I have used in my demo:

Sending Side - Extra
  • Create a JMS Connection Factory in the sender JMS module. Use the default settings and and choose a easy-to-remember JNDI name. We need it in the Java client to test the JMS SAF configuration.

Sending Side - Additional notes
- I simply used the default settings for
  • the persistent store of the SAF agent
  • targeting and subdeployment
  • the type of error handling (log). If you decide to use an Error destination, make sure that the queue is targeted to same JMS server/Subdeployment as used for the SAF queue. Most probably, this will mean that you have to create a Subdeployment instead of using the default as I did :)
- For the SAF queue you have to use the JNDI name that you have chosen during the configuration of the destination queue at the receiving side for the remote JNDI location. For simplicity, you can use the same for the local JNDI name
- The JNDI name of the SAF Remote Destination will serve as the prefix of the local JNDI name that you defined for your SAF queue. Keep that in mind when you try to connect to the SAF remote queue (see further on in this posting for in the Java example)

Here's the overview of the JMS SAF resources in the JMS module, which is targeted to the sending server, that I have used in my demo set up:

JMS SAF remote Java client
Now that we have finished the Weblogic Server 11g JMS SAF configuration, we can test it by using a simple Java client. The code fragment below shows the code that you can use to test your configuration. Please note:

  • Import the J2EE 1.5 and Weblogic Remote client libraries in JDeveloper 11g
  • If you are not sure about the exact JNDI binding names for the Connection Factory and JMS destination, you can browse the JNDI tree of the sending server (Admin Console -> Environment -> servers -> -> Configuration/General tab)
  • You can either use '.' or '/' as the separator in your JNDI name

String CFName = "jms/ConnectionFactorySending";
String destName = "jmssaf.RemoteDestjms.Queue_Receiving";

Connection conn = null;
Session session = null;
MessageProducer prod = null;
//Set the Initial Context properties
Properties env = new Properties( );
env.put(Context.SECURITY_PRINCIPAL, "weblogic");
env.put(Context.SECURITY_CREDENTIALS, "welcome1");

InitialContext context = new InitialContext(env);

//Lookup connection factory
QueueConnectionFactory queueConnectionFactory =
(QueueConnectionFactory) context.lookup(CFName);

//Create a connection and session
conn = queueConnectionFactory.createConnection();
session = conn.createSession(false, 0);

//Lookup queue
Queue q = (Queue) context.lookup(destName);

//Send message
prod = session.createProducer(q);
TextMessage msg = session.createTextMessage();
msg.setText("SAF Test message");

catch(NamingException ne){
System.out.println("NamingException: "+ne.toString());
catch(JMSException jmse){
System.out.println("NamingException: "+jmse.toString());
catch(Exception e){
System.out.println("Excepion in finally branch: "+e.toString());

Run your program to send a message to the sending server. Before you do this make sure the receiving server is not running to check if SAF is working as expected. When the message is submitted, check the Monitoring tab in the Sending SAF agent configuration screen to check if the message is stored and waits for redelivery (from here you are able to perform more management tasks, like pausing forwarding etc.). When you start the receiving server the message will be redelivered automatically to the receiving server..

This blog serves as a starting point for using JMS SAF. More info about all the specific configuration options and monitoring/management options can be found here.