Tuesday, April 19, 2011

weblogic clustering on different host

Hello Everyone,
Today we will discuss about weblogic clustering on different host, lets discuss about clustering.
I have posted some screenshots as well, if any mismatch in that then please correct me.... :)

"A WebLogic Server cluster consists of multiple WebLogic Server server instances running simultaneously and working together to provide increased scalability and reliability. A cluster appears to clients to be a single WebLogic Server instance. The server instances that constitute a cluster can run on the same machine, or be located on different machines. You can increase a cluster's capacity by adding additional server instances to the cluster on an existing machine, or you can add machines to the cluster to host the incremental server instances. Each server instance in a cluster must run the same version of WebLogic Server."

There are also several methods for setting up the clustered domain, namely using the Fusion Middleware Configuration Wizard, the Administration Console, the wlst command line utility and even programmatically. In this example we will combine the first three: we will create the domain using the Configuration Wizard and setup the domain cluster using the Administration Console and the wlst utility.

Briefly the steps involved in setting up the cluster are:

1. Install WebLogic on both physical machines
2. Create the WebLogic Domain on one physical machine
3. Configure the domain by adding Managed Servers and Machines on one physical machine
4. Copy the domain file structure to the other physical machine and enroll it to the WebLogic Domain
5. Ensure that both WebLogic Machines are operational
6. Create and configure the Cluster
7. Ensure that the Cluster is operational



1. Install WebLogic on both physical machines

The same exact version of WebLogic must be installed on both physical machines. Also, WebLogic must be installed on the same Middleware Home in both machines. This is necessary since we will be copying the domain file structure from one physical machine to the other - step 4 above.

Start by going to the Oracle WebLogic downloads page and download the latest version of WebLogic for Linux.


The 32-bit Linux WebLogic version 10.3.3. file that is downloaded is called wls1033_oepe111150_linux32.bin. For installing and administering this installation create a weblogic Linux user account and use it to login and perform the installation. Make sure that the maximum number of open files is set to 4096 for the user account.

Ensure that the wls1033_oepe111150_linux32.bin has execute permission and start the installation by typing ./wls1033_oepe111150_linux32.bin. The installation will self-unpack and present the Welcome page.




On the Choose Middleware Home Directory page accept the default Oracle/Middleware under the /home/weblogic and press Next.




On the Register for Security Updates page click Next. On the Choose Install Type page select Custom and click Next. On the Choose Products and Components page you may deselect Oracle Enterprise Pack for Eclipse and click Next. Accept the defaults on the JDK Selection page - both the Java and JRockit SDKs are selected - and click Next. On the Choose Product Installation Directories page accepts the defaults and click Next.


Verify the installation parameters on the Installation Summary page and press Next to proceed with the installation.

Now proceed with the installation of WebLogic using the exact same installation package and the steps outlined above on the other machine.


Ensure that in page Choose Middleware Home Directory the same Middleware Home is specified. In this case we will accept the default Oracle/Middleware under the weblogic user's home directory /home/weblogic.




2. Create the WebLogic Domain in one physical machine

Now, having completed the WebLogic installations on both machines, we can proceed with the creation of the WebLogic Domain. We will do this only on one of the two machines.

Start the Fusion Middleware Configuration Wizard utility - it is called config.sh and is located in the wlserver_10.3/common/bin directory under the Middleware Home (/home/weblogic/Oracle/Middleware for our installation) and on the Welcome page select Create a new WebLogic domain.


At this point accept the default products on the Select Domain Source page and click Next. On the Specify Domain Name and Location page specify the name and location of the domain. For this example we have called it clusteredDomain. On the Configure Administrator User Name and Password page specify the weblogic administrator password. Accept the appropriate startup mode and JDK on the Configure Server Start Mode and JDK page and click Next. On the Select Optional Configuration page select Administrator Server only. We will create the Managed Servers, Machines and Clusters later on using the Administration Console.


On the Configure the Administration Server page you can accept the defaults for the administration server  Name and Listen port and click Next. Verify your selections on the Configuration Summary page and when ready click on Create to proceed with the creation of the domain.


The Configuration Wizard proceeds with the creation of the domain under the path specified, which defaults to user_projects/domains under the Middleware Home. Once the domain is created successfully, we can start it by running the startWebLogic.sh script in the user_projects/domains/clusteredDomain. Verify that the domain is started successfully by observing the logs in the terminal window.


3. Configure the domain by adding Managed Servers and Machines in one physical machine
With the domain running we can proceed with the creation of the Managed Servers and Machines using the WebLogic Administration Console. So, start your browser and go to the Administration Console by specifying its address as: http://machine1:7001/console ,where machine1 is the ip address or host name of the machine that you used in step 2 above to create the Administration Server. This should display the Administration Console login form.


Enter the server administration name and password you specified in step 2 when creating the domain - username defaults to weblogic - and click Log In to login.

The first thing that we need to do now is to create the managed servers. Using the Domain Structure tree navigate to Environment and then Servers. On the Summary of Servers screen Configuration tab click on the New button to create a new Managed Server.


On the Create a New Server screen specify the Server Name, Server Listen Address and Server Listen Port. For the Server Listen Address specify the address of the first physical machine. You can click Next to verify your input and finally Finish to proceed with the creation of the Managed Server.


The Administration Console proceeds with the creation of the server. When done displays a success message in the Messages area and the server is shown in the Summary of Servers table in a SHUTDOWN state.


Repeat the steps above to create the Managed Server sunning on the other physical machine. Make sure that you specify the Server Listen Address of the other physical machine.


Now that the Managed Servers have been created we will proceed with the creation of the WebLogic Machines - one for each physical machine - and assign the Managed Servers to them.

Using the Domain Structure tree navigate to Environment and then Machines. On the Summary of Machines table click on the New button to create a new WebLogic Machine.


On the Create a New Machine page specify the name of the first machine and click OK to create the Machine.


A success message in the Messages should indicate the successful creation of the Machine and the Machine will be available in the Summary of Machines table.


Now, click on the newly created Machine and then on the Node Manager tab under the Configuration tab. The node manager will be used on each physical machine to start the Managed Servers. On this tab we need to properly configure the node manager parameters. Make sure that the Type is set to Plain and that the Listen Address corresponds to the ip address of the physical machine where this Machine's node manager is running. You can leave the port to the default 5556. Don't forget to click on the Save button to save your settings.


Verify that your settings were set successful by observing the Messages area.

Now you will need to assign the appropriate Managed Server to the Machine. You do this by clicking on the Servers tab under the Machine Configuration tab and then the Add button.


In the Add a Server to Machine page ensure that the appropriate Managed Server - the one that corresponds to this Machine - is selected in the Select a server choice list. Click Next or Finish to proceed with the server assignment.


The Managed Server should be assigned successfully and should be displayed in the Servers table for this Machine.


Now repeat the steps above to create a WebLogic Machine for the second physical machine. Make sure that you configure the Machine correctly and assign the appropriate Managed Server to it.


Now with the WebLogic Machines created and configured we can start the node manager on the machine. Remember that we are still working on the same machine where we run the Configuration Wizard in the first place. It can be started by running the startNodeManager.sh script in the wlserver_10.3/server/bin directory under the Middleware Home. Before starting it, go over the start-up parameters specified in the nodemanager.properties configuration file in the wlserver_10.3/common/nodemanager directory and verify that it is not configured for SSL by ensuring that the SecureListener parameter is set to false. Once started the terminal window should indicate that the node manager is  running and listening to the port configured.


To verify that the node manager is reachable by the WebLogic Machine, return to the Machines page in the Administrator Console and on the Summary of Machines table click on the first Machine - Machine1 in this case the one we are currently configuring. Click on the Monitoring tab and observe in the Node Manager Status tab that the node manager Status is Reachable.




4. Copy the domain file structure to the other physical machine and enroll it to the WebLogic Domain

WebLogic comes with a pack utility that allows you to pack a domain and move it from one place to another. We will instead use plain old Linux tar and gzip to pack our WebLogic domain directory file structure and move it from one physical machine - the one that we have done steps 2 and 3 so far - to the other. Before doing so, we will shutdown the domain and node manager if they are still running on the first machine. Once the packing is done, we will re-start them.

To shutdown the domain, simply press Ctrl-C within the console running the domain. Alternatively, you could shutdown the  domain by shutting down the Administration Server using the Administration Console. Once the  domain is shutdown, go to the Middleware Home directory and issue the following tar command to pack the domain directory file structure and contents, i.e. the user_projects directory: tar cvf user_projects.tar user_projects


When the tar command is done, zip the archive by typing: gzip user_projects.tar. The file that needs to be moved and unpacked on the other machine is called user_projects.tar.gz


The compressed archive of the user_projects domain file structure should be moved to the Middleware Home on the other physical machine - remember that the Middleware Home directories on both physical machines should be exactly the same - and uncompress by typing gunzip user_projects.tar.gz


Finally extract the archive by typing tar xvf user_projects.tar. This will create the user_projects directory structure on the second physical machine.


Now you need to re-start the domain - on the first (original) machine - and use the  WebLogic Scripting Tool - on the second machine - to enroll the domain structure - the one we just extracted - to the WebLogic Domain. So, after making sure that the domain is started and is in RUNNING state, issue the following commands on the second machine - the one we are now setting up - to enroll it to the WebLogic Domain:

Start the WebLogic Scripting Tool by changing to the wlserver_10.3/common/bin directory and typing wlst. On the wlst prompt issue the following command to connect to the WebLogic Domain running on the other machine: connect('weblogic','weblogic1','t3://192.168.1.106:7001').






Verify that the connection was successful and then issue the following command to enroll this machine to the WebLogic Domain:


nmEnroll('/home/weblogic/Oracle/Middleware/user_projects/domains/clusteredDomain', '/home/weblogic/Oracle/Middleware/wlserver_10.3/common/nodemanager')

Verify that the machine was successfully enrolled into the Domain.




5. Ensure that both WebLogic Machines are operational


Now that the second machine was successfully enrolled into the WebLogic Domain, we can start the node manager on the second machine and verify that it is Reachable by the WebLogic Machine. We have already verified that the node manager on the first machine is Reachable back in step 3.


You can start the node manager by running the startNodeManager.sh script in the wlserver_10.3/server/bin directory. Again, ensure that the node manager is not started in SSL mode by setting the SecureListener parameter to false in the nodemanager.properties configuration file in wlserver_10.3/common/nodemanager. Note that nodemanager.properties might not exist until you first run startNodeManager.sh.


Now, with the node managers running on both physical machines return to the Administration Console and verify that the node managers are Reachable for both Machines.


6. Create and configure the WebLogic Cluster


To create a WebLogic Cluster use the Administration Console and via the Domain Structure tree navigate to Environment and then Clusters. On the Summary of Clusters table click the New button to create a new WebLogic Cluster.


On the Create a New Cluster page enter the Name of the Cluster, select Unicast for the Messaging Mode and click OK.


Ensure that the WebLogic Cluster is created successfully by observing the messages on the top Messages area and the new Cluster appearing in the Clusters table. Now, click on the newly created Cluster to go to the Settings for Cluster page. On the Configuration General tab on the Cluster Address field enter the IP addresses of the physical machines separated by comma(s) supplying 7003 as the cluster listen port, e.g. 192.168.1.106:7003,192.168.1.107:7003 in this example. Click Save to save the changes.


While still on the Settings for Cluster page, go to the Configuration Servers tab and click Add on the Servers table to assign the Managed Servers to the Cluster.


On the Add a Server to Cluster page select the Managed Servers - one at a time - to add to the Cluster using the Select a server drop down and click Finish.


Repeat this step for both Managed Servers. In the end both Managed Servers should be shown on the Servers table for the Cluster.



7. Ensure that the Cluster is operational

Now that the Cluster is setup we can start the Managed Servers and do some monitoring on the Cluster to ensure its proper operation. You can start the Managed Servers either by running the startManagedWebLogic.sh script in the user_projects/domains/clusteredDomain/bin directory - for each physical machine - or from within the Administration Console. We will use the Administration Console to do so, which will at the same time validate our setup. So, go to the Summary of Servers page - via the Domain Structure tree by clicking on Environment and then Servers - and click on the Control tab. Click on the  checkboxes to select both Managed Servers - notice that they are both in SHUTDOWN state - and click the Start button to start them.


The Administration Console will delegate the start-up process to the node managers running on both machines. Each node manager will start the Managed Server assigned to the Machine controlled by the node manager. The process might take a minute or so to complete and once done both Managed Servers should be displayed on the Servers table with a RUNNING state. The Status of Last Action should be TASK COMPLETED. You will need to periodically refresh the page to see the final start-up status.


Now with both Managed Servers running, let's take a look at our Cluster status. Return to the Summary of Clusters page - via Environment and then Clusters on the navigation tree - and click on the Cluster in the Clusters table. Then click on the Monitoring tab and observe the Cluster Server status on the Summary tab.


Click on the Health and Failover tabs to see other monitoring information and status.






We have completed Oracle Weblogic clustering on different hosts, I hope this will help you in Clustering.


Enjoy working in middleware and any queries, suggestions and any mistakes, kindly let me know via comments,


Regards,
Ajinkya Vichare
ajinkya-vichare.blogspot.com

Wednesday, April 13, 2011

How to move In-Process Reports Server to default standalone under OPMN and EM control?



Hello everyone,

Today we will discuss about , "How to move In-Process Reports Server to default standalone under OPMN and EM control?"

The In-process reports server is a child of OC4J_BI_FORMS and requires restart of application to restart reports server.
Can the reports server:
1)  be standalone and still have the same name,
2)  be able to be started independently by OPMN and EM,
3)  and still be the default reports server so that the "server=" parameter can be omitted from the URL? 

This post will give the steps to accomplish this.

Solution

To implement, do the following:
This applies to Unix and Windows. Only Unix traversing is shown in this note.

Step 1. Stop opmn.
$ cd $ORACLE_HOME/opmn/bin
$ opmnctl stopall

Step 2. Stop EM console.
$ cd $ORACLE_HOME/bin
$ emctl stop iasconsole


Step 3. Edit the $ORACLE_HOME/reports/conf/rwservlet.properties file:

From
SERVER_IN_PROCESS=YES
To
SERVER_IN_PROCESS=NO


Step 4. Note the in the rwservlet.properties file the value for SERVER=<somename>.
The SERVER parameter defines the "default" reports server names when server=.. is omitted from URL.

Step 5. Make a backup of $ORACLE_HOME/sysman/emd/targets.xml.


Step 6. Delete the existing in-process report server entries from the targets.xml file:
<Target TYPE="oracle_repserv" NAME="localAS.localhost_Reports_Server:<somename>" DISPLAY_NAME="Reports Server: <somename>" VERSION="1.0" ON_HOST="localhost">
.....
</Target>


Step 7. Add the report server to opmn.xml and targets.xml fles using addnewservertarget.sh or addnewservertarget.bat:
$ cd $ORACLE_HOME/bin/
$ addNewServerTarget.sh <somename>   <= this is the name from step 4


Step 8. Restart opmn.
$ cd $ORACLE_HOME/opmn/bin
$ opmnctl startall

Step 9.
Verify that report server is an ias-component.
$ opmnctl status
- Look for the report server name in the first column.


Step 10. Restart EM console.
$ cd $ORACLE_HOME/bin
$ emctl start iasconsole

To start and stop the ONLY reports server from OPMN use the following command:
$ cd $ORACLE_HOME/opmn/bin
$ opmnctl startproc ias-component=<somename>
$ opmnctl stopproc ias-component=<somename>
 
NOTE:
If using namingService for reports server discovery, then Dependancy need to be added to new entry in OPMN.XML
1. Edit the new opmn.xml and add the following to the repserv tag:

FROM

<dependencies>
<OID infrastructure="true"/>
<database infrastructure-key="portal"/>
<managed-process ias-component="OC4J" process-type="OC4J_BI_Forms" process-set="default_island" autostart="true"/>
<managed-process ias-component="HTTP_Server" process-type="HTTP_Server" process-set="HTTP_Server" autostart="true"/>
</dependencies>

TO

<dependencies>
<OID infrastructure="true"/>
<database infrastructure-key="portal"/>
<managed-process ias-component="OC4J" process-type="OC4J_BI_Forms" process-set="default_island" autostart="true"/>
<managed-process ias-component="HTTP_Server" process-type="HTTP_Server" process-set="HTTP_Server" autostart="true"/>
<managed-process ias-component="namingservice" process-type="namingservice"
process-set="namingservice" autostart="true"/>
</dependencies>


I hope this will help you in such scenarios..

Regards,
Ajinkya Vichare
ajinkya-vichare.blogspot.com

Monday, February 14, 2011

Generate Key store 2048 in Websphere application server 6.x

Hello Everyone,

Last week one of my consultant had issues with creating SSL certificate 2048 in Websphere Application server v6.

We had apply some workaraounds for the same.


Problem discription :

The iKeyman utility within IBM HTTP Server V6.0 does not provide the option to create a certificate request (CSR) 2048 key size

After a CMS key database has been created using the iKeyman utility, in the task of creating a certificate request, the key size options listed are 512 and 1024.

After searching on google and IBM site we have found following cause :

By default, the iKeyman utility uses the Java 1.4 version of the gskikm.jar file installed with IBM HTTP Server V6.0. The file is located in the following directory:

/_jvm/jre/lib/ext/

The classes within this version of the gskikm.jar file only supply the key size options of 512 and 1024. By renaming and moving the gskikm.jar file from its default location, the iKeyman utility will load the Global Security Toolkit (GSKit) v7 classes providing an additional key size of 2048.


So for Resolving the problem we had Followed steps:

1. Stop the iKeyman utility.

2. Ensure the GSKit is installed with IBM HTTP Server V6.0, and has a 7.0.3.18 or higher version to support a key size of 2048. Applying the latest available IBM HTTP Server V6.0 fix pack will upgrade the GSKit V7 to a higher version.

OR

From the IBM HTTP Server Fixes web site, download and manually install the latest GSKit V7.0.4.28 ( PM07113 - IHS Version 6). A readme file will be included with instruction on how to install GSKit on a UNIX or Windows platform.

3. Rename and move the /_jvm/jre/lib/ext/gskikm.jar file to a directory that is not detectable to the JDK class path, extdirs, or bootclasspath.

For example:

From:

/_jvm/jre/lib/ext/gskikm.jar

To:

/_jvm/jre/lib/ext/gskfiles/gskikm.jar.org

4. Restart the iKeyman utility.

5. Follow the create a certificate request task and select the Key Size

Now we can see key size 2048 with 512 and 1024, before troubleshooting this problem i was not aware of this reasons.

So finally we resolve the issue and thanks to google and IBM site..... :)

Enjoy wroking with Middleware... Hope it will help you,,,


Regards,
Ajinkya Vichare

How to create E-mail notification in Weblogic using WebLogic Diagnostics Framework (WLDF)

Dear All,


Today we will discuss about Weblogic diagnostics and framework. and how to configure mail notification on Weblogic.
Actually i came across one of the requirement where we configure e-mail notifications for different-different purposes, now will discuss about Heap_size notifications.

WebLogic Diagnostics Framework (WLDF) – Watch & Notification

One of the features of WLDF is Watch and Notification. You can configure server(s) with watch condition and respective notification(s) to be sent if the watch conditions are met. For example, if the number of request waiting on a JDBC Data Source to grab a connection exceeds 10 and if the free heap in the server is less than 5% then you can trigger a notification.

The notification can be one or more of the following types:

* JMX Notification - Application(s) can register notification listener with WLDF to receive notifications.
* JMS Notification - WLDF can post a message to JMS destination to alert the situation which can be consumed by a message listener or MDBs to further processing.
* SNMP Notification - SNMP traps can be sent to alert SNMP managers.
* SMTP Notification - Email notifications through a Java Mail session.
* Image Notification - Generates a server image which contains information from different subsystem during the watch.

Creating JavaMail Session

First step is to make sure that the underlying resources for the notification are setup. In this case we are going to use SMTP notification so let us first create the Java Mail Session to connect to Mail Server.

1. Click "Lock & Edit" to acquire a configuration lock

2. Expand Services > Mail Sessions and click "New" to create a new Java Mail Session.

3. Provide Name, JNDI Name and JavaMail Properties as follow:

4. Name - WL-MailSession

5. JNDI Name - com.test.MailSession

6. JavaMail Properties:

mail.transport.protocol=smtp
mail.host=hostname_smtp
mail.user=admin
mail.password=password
mail.port=(port_number)
mail.from=admin@domain.com

(Note : The port number of the mail server for the specified protocol. If not specified the protocol's default port number is used.
mail.protocol.port=port_number)


So We can use following mail property



7. Click next to target the mail session to a server (Eg. AdminServer or mange_server1) and click finish.

8. Activate the changes by clicking "Activate Changes".



Creating WLDF Module

Next step in configuring watch and notification is to create a diagnostic module and target it to the server. You can use console or WLST to create a diagnostic module. The following steps illustrate the steps to create a WLDF system module:

1. Click "Lock & Edit" to acquire a configuration lock

2. Click Diagnostics > Diagnostics Modules and click "New" to create a new diagnostics module. Provide a name and description.

3. Name - Mail_WLDF_Module

4. Description - This is a WLDF module for testing email notifications

5. Select the newly created module and select targets tab. Select the appropriate server for target as before

6. Click "Save" and "Activate"


Creating Watch & Notification

Each WebLogic Server instance can be configured with only one diagnostic module but you can target the same diagnostic module to multiple servers or clusters. Once the WLDF system module is created and targeted to the appropriate server then watches and notifications can be configured. The following steps illustrate how to create a Watch and a Notification.

To create a watch:

1. Click "Lock & Edit" to acquire a configuration lock

2. Navigate to the diagnostic module created above (Mail_WLDF_Module) and select the "Watches and Notifications" tab and "Watches" sub-tab (if not already selected)

3. Click "New" to create a new Watch. Provide the name and select the type as "Collected Metrics" [Select "Collected Metrics" for inspecting Runtime MBean values, "Server Log" to watch log data and "Event Data" to watch instrumented data]

4. Name - Heap_Notification

5. Watch Type - Collected Metrics

6. Enable Watch - Selected

7. Click "Next"

8. Click "Add Expressions"

9. Ensure that "ServerRuntime" is selected and click "Next"

10. If you are running WebLogic Server on Java HotSpot VM, make sure
"Select an MBean Type from the following list" is selected and select "weblogic.management.runtime.JVMRuntimeMBean" and click "Next".

If you are using JRockit VM, make sure "Select an MBean Type from the following list" is selected and select "weblogic.management.runtime. JRockitRuntimeMBean" and click "Next".

11. Select the instance for the appropriate server from the list for "Instance" and click "Next"

12. For "Message Attribute" select "HeapFreePercent", "<" for "Operator" and type "85" for "Value". Click "Finish" twice to create a Watch 13. Activate the changes The above watch will trigger the configured notification if the percentage of free heap is less than 90. You could make complex rule expression by combining multiple attributes from different MBean. For now we haven't configured any notification for this watch. We will create the notification and will associate it to the watch in the following steps. To create a notification:

1. Click "Lock & Edit" to acquire a configuration lock

2. Navigate to the diagnostic module created above and select the "Watches and Notifications" tab and "Notification" sub-tab

3. Click "New" to create a new Notification

4. Select "SMTP (E-Mail) for Type and click "Next"

5. Provide a name - Email_Notification. Make sure the notification is enabled and click "Next".

6. Configure the following properties for the "Config Notification - SMTP Properties" page

7. Mail Session Name - MailSession01

8. E-Mail Recipients - admin@localhost

9. Click "Finish".

10. Activate the changes



To associate the watch and the notification:

1. Click "Lock & Edit" to acquire a configuration lock

2. Navigate to the diagnostic module created above (Mail_WLDF_Module) and select the "Watches and Notifications" tab and "Watches" sub-tab (if not already selected)

3. Select the watch you created earlier - Heap_Notification

4. Select the "Notifications" tab and move the "Email_Notification" from Available to Chosen

5. Click "Save"

6. Select the "Alarms" tab and select "Use an automatic reset alarm". Set the "Automatic reset period" to 6 and click "Save". This will ensure that the notifications are at least 90 seconds apart.

7. Click "Activate Changes"


As we configured the watch type to be Collected Metrics, the attributes involved in the watch rule will be harvested and tested for watch rule expression(s). The default sampling period for the harvester is 300,000 milliseconds (or 5 minutes). So the time between samples will be 5 minutes. To change the sampling period for metrics collection:

1. Click "Lock & Edit" to acquire a configuration lock

2. Navigate to the diagnostic module created above (Mail_WLDF_Module) and select the "Collected Metrics" tab

3. Ensure that "Enabled' check-box is selected

4. Change the "Sampling Period" as "120000" so that it will collect samples once every two minute


I hope it will help you in creating notifications.


[NOTE : change settings/names and properties as per your requirements. It could have some mismatch in above blogs]


Enjoy working in Middleware...... Cheerzzzz

Regards,
Ajinkya

Friday, January 21, 2011

Warnings while starting Oracle SOA 11g

Hello,

Few days back while starting SOA i noticed that SOA gave me the following warning :
"
Warning: JMS queue 'weblogic.wsee.DefaultQueue' is not found, as a result, Web Service async responses via jms transport is not supported. If the target service uses JMS transport, the responses will not be able to come back.
"
I was worried for this warning msg but when i tried to solve it i came accross following conclusion :

It's a harmless warning message and that can be avoided.But still if you don't want to see this WARNING message then please apply the following flag in the JAVA_OPTIONS of your Server :

-Dweblogic.wsee.skip.async.response=true

Why we see this WARNING is your Server Log:

Async web service support is not fully configured. The async response web service uri for this server was not fully deployed because the JMS reliability queue was not defined/deployed: queueName. The server will periodically retry completing the deploy for the service. This message can usually be ignored unless there are async web service applications. To completely disable async web service support, thus avoiding this message,

set -Dweblogic.wsee.skip.async.response=true.

Enjoy Working with fusion middleware... All the best..


I hope it will help you while working with SOA,

Regards,
Ajinkya

WLST Error - java.lang.UnsupportedClassVersionError

Hello Everyone,

Today i have gone through issue working with WLST, it gives me following error while stopping weblogic server via WLST

" Problem invoking WLST - java.lang.UnsupportedClassVersionError: Bad version number in .class file Done "

I have gone through some documents which gives me some idea about this issue, finally i got solution for the same.

Solution: The jdk version used while creating the domain is not supported. Use higher version ( present in the same WebLogic server installed location) and point it while domain creation.

I hope it will help you while working with WLST...

Keep working and smiling..... :)


Regards,
Ajinkya

Friday, January 7, 2011

Error while accessing Websphere Application Server console

Hi Everyone,

Today i have faced one issues while working on Websphere application server on AIX.

I finished my websphere application server installation successfully but while accesing console, was getting following error.

WebSphere Admin Console SRVE0190E: FileNotFound Errors when clicking certain hyperlinks

Should you find that you have some links in your WebSphere Administration console that generate an error in the following format:

com.ibm.ws.webcontainer.webapp.WebAppErrorReport:

SRVE0190E: File not found: /xxxxxxxxxxx.content.main
at com.ibm.ws.webcontainer.webapp.WebAppDispatcherContext.sendError(WebAppDispatcherContext.java)
at com.ibm.ws.webcontainer.srt.SRTServletResponse.sendError(SRTServletResponse.java)
at com.ibm.ws.webcontainer.servlet.FilterProxyServlet.dispatch(FilterProxyServlet.java)
at com.ibm.ws.webcontainer.servlet.FilterProxyServlet.service(FilterProxyServlet.java)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java(Compiled Code))
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java(Compiled Code))
at com.ibm.ws.webcontainer.filter.WebAppFilterChain.doFilter(WebAppFilterChain.java(Compiled Code))
at com.ibm.ws.webcontainer.filter.WebAppFilterChain._doFilter(WebAppFilterChain.java(Compiled Code))
at com.ibm.wsspi.webcontainer.extension.WebExtensionProcessor.invokeFilters(WebExtensionProcessor.java)
at com.ibm.ws.webcontainer.extension.DefaultExtensionProcessor.handleRequest(DefaultExtensionProcessor.java)It appears that the admin console couldn’t find the servlet that should be used to display the page.


I did some R & D on it, and finally i got resolution for the same.

in my case, had corrupted Admin console registry. so i run following command for the same from profiles.

iscdeploy -restore


This will cause WebSphere Application Server to reinstall the admin console.

this is very helpful while working with Websphere Application server console...... :)


Hope it will help you...


Regards,
Ajinkya Vichare