Ahoy there! This is my personal blog which I use as my memory extension and a medium to share stuff that could be useful to others.

Problem:

The Administration server of a WebLogic domain comprising WebLogic Server 10.0 and WebLogic Integration 10.2, consumes high CPU and throws java.lang.OutOfMemory errors.

 

Background:

The WebLogic Domain’s admin server had only two web applications deployed on it – the WebLogic Administration console and WebLogic Integration console. After start-up, its CPU utilization gradually increased and reached around 80% within a couple of days. Also, java.lang.OutOfMemory errors were observed in the server logs. This behaviour was observed even when there was no load on the managed servers and the web applications on the admin server were not accessed (all servers idle from a user perspective).

WebLogic Domain details:

Version: WebLogic Server 10.0 MP1, WebLogic Integration 10.2
JVM: JRockit R27.5.0-110 (JRE Standard Edition build 1.5.0_14-b03)
Admin Server JVM Heap: Minimum (Xms) = Maximum (Xmx) = 2 GB
Number of managed servers: 2
Operating System: 64-bit Red Hat Enterprise Linux 5.1
CPU Architecture: AMD64

 

Solution:

The following patches were applied and the problem was resolved. Contact Oracle support or use their Smart Update procedure to obtain the patches.

SL# PATCH COMMENTS
1. D76T CR380997 Admin server gives OOM: Closed the Queue and Session Objects properly.
2. LJTR CR373884 Unable to apply some of the patches for jpd.jar when using "inject" mechanism
3. ZSX5 BUG8174387 MEMORY LEAK OBSERVED ON ADMIN SERVER: No public details available. Patch provided for WLI 10.2

 

Root Cause:

Known issues with WebLogic Integration 10.2

 

NOTE:

(1) The solution above describes a successful problem-solving experience and may not be applicable to all problems with similar symptoms.

(2) Your rating of this post will be much appreciated. Also, feel free to leave comments.

VN:F [1.6.5_908]
Rating: +2 (from 2 votes)

Problem:

A software’s log4j framework could not find the log4j configuration file which I specified. Details with debug below:

 

Command:

java -Dlog4j.debug=true -Dlog4j.configuration=/mysoftware/config/mylog4j.properties ...

 

Debug Output:


log4j: Trying to find [mysoftware/config/mylog4j.properties] using context classloader sun.misc.Launcher$AppClassLoader@164b95.
log4j: Trying to find [mysoftware/config/mylog4j.properties] using sun.misc.Launcher$AppClassLoader@164b95 class loader.
log4j: Trying to find [mysoftware/config/mylog4j.properties] using ClassLoader.getSystemResource().
log4j: Could not find resource: [mysoftware/config/mylog4j.properties].

 

Background:

I did not want to use the default location for the log4j configuration file and wanted to be able to specify to a file with a name and location of my choice.

 

Solution:

The debug output indicates that the absolute path of the resource (log4j.properties) is missing a beginning “/”. That’s because the file:// protocol was not specified. So, the following worked and enabled log4j locate the properties file:

 

java -Dlog4j.debug=true -Dlog4j.configuration=file:///mysoftware/config/mylog4j.properties ...

NOTE: If your log4j configuration file is called log4j.xml or log4j.properties, then placing it in the application classpath will suffice and you will not need the -Dlog4j.configuration option.

 

 

Root Cause:

The file:// protocol was not used to specify the log4j configuration file.

 

Reference:

Short Introduction to log4j – Ceki Gülcü

 

NOTE:

(1) The solution above describes a successful problem-solving experience and may not be applicable to all problems with similar symptoms.

(2) Your rating of this post will be much appreciated. Also, feel free to leave comments.

VN:F [1.6.5_908]
Rating: +5 (from 5 votes)

Problem:

When using WLShell 2.1.0.1 to connect to a WebLogic server, the connection fails and the following error is displayed:

couldn’t find or load connector class: wlshell.connect.jmx.weblogic.Connector for protocol: t3 check the libraries required by this connector are in the classpath. use the "ver" and "info -v" commands to display the current classpath.

 

Background:

In order for WLShell 2.1.0.1 to start properly and connect to a WebLogic server, the following must be present in the CLASSPATH: weblogic.jar, wlshell-2.1.0.1.jar, wlshell-2.1.0.jar and log4j-1.2.8.jar

My CLASSPATH had all the above jars, but I still received the error.

WebLogic was installed as a user called "bea" and I was running WLShell as my user (saturg). Both users were not part of the same group, but I ensured that weblogic.jar was accessible and readable by user saturg.

 

Solution:

As I did not have privileges to make both users bea and saturg part of the same group, I executed the following command as the bea user in the WebLogic installation root directory:

 

find . -type f | xargs -i chmod 744 {}

 

So, basically, I ensured that all files in the WebLogic installation were accessible and readable by all users on the host.

Note:The recommended method is to make both the weblogic installation user and WLShell user part of the same group, thereby restricting access to the WebLogic installation

 

Root Cause:

The error message is misleading as the class wlshell.connect.jmx.weblogic.Connector is available in wlshell-2.1.0.jar. The solution above indicates that WLShell requires to access other jars in the WebLogic installation (apart from weblogic.jar) or rather classes in weblogic.jar require to access other jars in the WebLogic installation.

 

NOTE:

(1) The solution above describes a successful problem-solving experience and may not be applicable to all problems with similar symptoms.

(2) Your rating of this post will be much appreciated. Also, feel free to leave comments.

VN:F [1.6.5_908]
Rating: +1 (from 1 vote)

My blogs are hosted on hostmonster and run on the WordPress platform. About 8 months ago, before I started blogging (finally!), I researched the pros and cons of various blogging platforms and tried out a few before selecting WordPress. So far, it’s been a great experience blogging using WordPress.

When I first started blogging, I registered the domain www.mrkips.com for my blogs. A few days ago, I registered another domain www.cybergav.in (a domain name which relates more to  me and my ethnic roots). Yesterday, I finally switched my blogs from mrkips.com to cybergav.in and although the WordPress forums provide adequate information on how to do this task, I’m describing the process below which worked for me.

Let’s say you host your WordPress blog on hostmonster (process should be applicable to most hosting platforms) and wish to switch its domain from www.abc.com to www.xyz.com.

 

STEP 1: Register your domain and specify DNS servers

Register your new domain xyz.com after doing a bit of research and choosing an appropriate registrar (typical factors in choosing a registrar are cost, DNS management facility, Domain privacy (not available for all ccTLDs) and customer service – there are other goodies usually provided such as web forwarding, domain cloaking, etc.). When you select your registrar and register your domain, you must ensure that you use the registrar’s DNS management facility to configure the DNS servers belonging to your hosting platform. For example, for my domain, I configured my DNS servers as ns1.hostmonster.com and ns2.hostmonster.com. It is this DNS configuration that will ensure the required DNS A records are inserted in your hosting platform’s DNS servers to map your domain name with your hosting account (and consequently your website).

 

STEP 2: Verify your domain

My domain was registered in less than half an hour and I could verify its registration using a WHOIS search. If your domain name registrar and hosting provider are different companies, then ensure you inform your hosting provider after registering your domain. My hosting provider switched my primary domain to cybergav.in and I configured mrkips.com as a parked domain. Now before you migrate your website to your new domain, you must verify if your new domain is resolvable. To do this, you can either use any one of the myriad websites available (e.g. www.who.is ) or use the nslookup utility as follows:

#
# SYNTAX 1: nslookup <domain name>
#
c:\>nslookup cybergav.in
Server:  BeBox.config
Address:  192.168.1.130:53
 
Non-authoritative answer:
Name:    cybergav.in
Address:  66.147.240.162
 
#
# SYNTAX 2: nslookup <domain name> <dns server>
#
c:\>nslookup cybergav.in ns1.hostmonster.com
Server:  UnKnown
Address:  74.220.195.131:53
 
Name:    cybergav.in
Address:  66.147.240.162

STEP 3: Change your WordPress blog’s domain name

(i) Define the WP_HOMEand WP_SITEURLvariables: This is required in order to give your WordPress blog its new domain name and access its Administration console (wp-admin). You do this by adding the following in wp-config.php (in the root of your WordPress installation):

define('WP_HOME','http://www.xyz.com');
define('WP_SITEURL','http://www.xyz.com');

 

(ii) Update your blog’s WordPress database by ensuring that URLs containing your old domain reflect your new domain as per the following example :

UPDATE wp_posts SET guid = REPLACE (
guid,
'abc.com',
'xyz.com');
 
UPDATE wp_posts SET post_content = REPLACE (
post_content,
'abc.com',
'xyz.com');

 

STEP 4: Redirect all traffic from your old domain to your new domain

After getting your blog up and running with your new domain name, you must redirect all traffic arriving at your old domain to your new domain to ensure your users and search engines know that you’ve switched domains. You must use a HTTP 301 Redirect method (permanent move) so that search engines and browsers will recognize your blog’s new home. You can configure this redirect by either using your hosting provider’s management tools or configuring .htaccess (Apache web server) as per the following example:

 

RewriteEngine On
RewriteCond %{HTTP_HOST} ^abc.com$ [OR]
RewriteCond %{HTTP_HOST} ^www.abc.com$
RewriteRule ^/?$ "http\:\/\/www\.xyz\.com\/" [R=301,L]
VN:F [1.6.5_908]
Rating: +2 (from 2 votes)

If you’re given access to a Linux machine without being told the Linux distribution being used, there are a couple of ways by which you can determine the Linux distribution

OPTION 1: Use the lsb_release utility.

The Linux Standard Base (LSB) is a joint project by several Linux distribution vendors working under the Linux Foundation, to develop and promote a set of open standards that will increase compatibility among Linux distributions and enable software applications to run on any compliant system even in binary form.

The lsb_release utility which is part of all Linux distributions which adhere to the LSB specification will print distribution specific information. Check the lsb_release manpage for details on usage. Example screenshots of using lsb_release on Ubuntu and Fedora distributions are given below:

 

lsb_release_ubuntu

 

lsb_release_fedora

 

OPTION 2: Check release files in /etc.

Linux distribution vendors typically include release files with details about the distribution, in the /etc directory. Screenshots of examples showing how to check such files on Ubuntu and Fedora are given below:

 

etc_release_ubuntu

 

etc_release_fedora

VN:F [1.6.5_908]
Rating: +1 (from 1 vote)

 Page 12 of 27  « First  ... « 10  11  12  13  14 » ...  Last »