Thursday, March 11, 2010

Windows Service

1)Installing Weblogic Server as a Windows Service:

Steps:

Create a batch file (.bat format) with the following script in the domain directory to Start WLS as a windows service and run this batch file through the command prompt.

Syntax:
---------------------------------------------------
SETLOCAL
set DOMAIN_NAME=
set USERDOMAIN_HOME=
set SERVER_NAME=
set JAVA_HOME=
call “
ENDLOCAL
---------------------------------------------------

For Example:
---------------------------------------------------
SETLOCAL
set DOMAIN_NAME= MyDomain
set USERDOMAIN_HOME= C:\bea101\user_projects\domains\MyDomain
set SERVER_NAME=AdminServer
set JAVA_HOME= C:\bea-WL-Server100\jdk150_11
call "C:\bea101\wlserver_10.0\server\bin\installSvc.cmd"
ENDLOCAL
---------------------------------------------------
After running this script in the command prompt you will observe a statement such as
“beasvc Server installed” When you observe in the windows services you will find the Admin server as installed and now start the service.

2)Procedure for Uninstalling Weblogic Admin Server as a Windows Service

Steps:

Create a batch file (.bat format) with the following script in the domain directory to Stop WLS as a windows service and run this batch file through the command prompt.
---------------------------------------------------
SETLOCAL
set WL_HOME=
rem *** Uninstall the service
"%WL_HOME%\server\bin\beasvc" -remove -svcname:"beasvc %DOMAIN_NAME%_%SERVER_NAME%"
ENDLOCAL
---------------------------------------------------

For Example:
---------------------------------------------------
SETLOCAL
set WL_HOME= C:\bea101\wlserver_10.0
rem *** Uninstall the service
"%WL_HOME%\server\bin\beasvc" -remove -svcname:"beasvc %DOMAIN_NAME%_%SERVER_NAME%"
ENDLOCAL
---------------------------------------------------
After running this script in the command prompt you will observe a statement such as
“beasvc _ removed”
When you observe in the windows services you will find that the Admin server is uninstalled.
------------------------------------------------------------------------------------------------------------


3)Steps to change the server mode from production to development when started as windows service:

Step1: Open regedit from “run” window

Step2: Go to HKEY_LOCAL_MACHINE -> SYSTEM -> CurrentControlSet -> Services -> -> Parameters -> CmdLine

Step3: Copy the value of CmdLine key to notepad

Step4: Modify -Dweblogic.ProductionModeEnabled to -Dweblogic.ProductionModeEnabled=false

Step5: Paste it back to CmdLine key

Step6: Save it & restart the server.

Memory

1)java.lang.OutOfMemoryError: PermGen space

Information related to the perm space:
The permanent generation is the area of heap that holds all the reflective data of the virtual machine itself, such as class and method objects (also called “method area” in The Java Virtual Machine Specification).
If an application loads “too many” classes then it is possible it will abort with an OutOfMemoryError.

The specific error is: “Exception in thread XXXX java.lang.OutOfMemoryError: PermGen space”.
The JVM itself needs memory to be able to run your application.
The PermGen is information about the classes that make up your application. Web applications and Servlet containers often need more PermGen memory than the JVM defaults to be able to run.
Fixing the java.lang.OutOfMemoryError: PermGen space error: Start your JVM with -XX:MaxPermSize=XXXm where XXX is a number like 256. This will allow the JVM to allocate XXX megabytes of memory for the PermGen space if that space is needed.

2)Information related to determining Memory Requirements:
How do I determine how much memory I need?
Weblogic recommends that you install a minimum of 256 MB of memory for each machine running Weblogic Server that will be handling more than minimal capacity.
If you are expecting a very heavy load then you increase your memory substantially.
A Weblogic Server deployment tracks session objects in memory, either to RAM or swapping to disk. There must be sufficient RAM/disk to store all the session objects. This RAM is accessible to Java through the Java heap.
Out of memory in java heap:
JVM throws java out of memory (java OOM) error if it is not able get more memory in java heap to allocate more java objects. The JVM cannot allocate more java objects if the java heap is full of live objects and it is not able to expand the java heap anymore.

In this situation, the JVM lets the application decide on what to do after throwing the java.lang.OutOfMemoryError.
For example, the application may handle this error and decide to shut down itself in a safe way or decide to run ignoring this error. If the application doesn’t handle this error, then the thread that throws this error will exit (you will not see this thread if you take a java thread dump).

In case of Weblogic server, this error is handled if it is thrown by an execute thread and the error is logged. If this error is being thrown continuously, then the core health monitor thread shuts down the Weblogic server.

Steps to follow in case of java OOM
a) Increase the java heap - Try increasing the java heap to see whether that solves the problem.
b) Caching in the application - If the application caches java objects in memory, then we should make sure that this cache is not growing constantly. There should be a limit for the number of objects in the cache. We can try reducing this limit to see if it reduces the java heap usage.

Java soft references can also be used for data caching as softly reachable objects are guaranteed to be removed when the JVM runs out of java heap.
c) Long living objects - If there are long living objects in the application, and then we can try reducing the life of the objects if possible. For example, tuning HTTP session timeout will help in reclaiming the idle session objects faster.
d) Add ‘-verbosegc’ flag in the java command line - This will print GC activity info to stdout/stderr. Redirect the stdout/stderr to a file. Run the application until the problem gets reproduced.

Make sure that the JVM does the following before throwing java OOM
Full GC run: Does a full GC and all the un-reachable, phantomly, weakly and softly reachable objects are removed and those spaces are reclaimed.
We can check whether full GC was done before the OOM message. A message like this is printed when a full GC is done (format varies depending on the JVM – Check JVM help message to understand the format)
[memory ] 7.160: GC 131072K->130052K (131072K) in 1057.359 ms
The format of the above output is (I will stick to the same format throughout this document) :
[memory ] : GC K->K (K), ms
[memory ] - start time of collection (seconds since jvm start)
[memory ] - memory used by objects before collection (KB)
[memory ] - memory used by objects after collection (KB)
[memory ] - size of heap after collection (KB)
[memory ] - total time of collection (milliseconds)
e) Memory leaks – One example of memory leak is when using database connection pools in application server. When using connection pools, the JDBC statement and resultset objects must be explicitly closed in a finally block.

This is due to the fact that calling close() on the connection objects from pool will simply return the connection back to the pool for re-use and it doesn’t actually close the connection and the associated statement/resultset objects.
It is recommended to follow the coding practices suggested in the following URLs to avoid memory leaks in your application.
http://download-llnw.oracle.com/docs/cd//E13222_01/wls/docs103/jdbc/troubleshooting.html

3)Information related to modifying the classpath:

After installation, Weblogic Server’s classpath is already set, but you may choose to modify it for a number of reasons such as adding a patch to Weblogic Server, updating the version of PointBase you are using, or adding support for Log4j logging.

To apply a patch to ALL of your Weblogic Server domains without the need to modify the classpath of a domain, give the patch JAR file the name, weblogic_sp.jar, and copy it into the WL_HOME/server/lib directory. The commEnv.cmd/sh script will automatically include a JAR named weblogic_sp on the classpath for you.

If you would rather not use the name weblogic_sp.jar for your patch file or you would just like to make sure a JAR file, such as one mentioned below, comes before weblogic.jar on the classpath:

* For ALL domains, edit the commEnv.cmd/sh script in WL_HOME/common/bin and prepend your JAR file to the WEBLOGIC_CLASSPATH environment variable.
* To apply a patch to a SPECIFIC Weblogic Server domain, edit the setDomainEnv.cmd/sh script in that domain’s bin directory, and prepend the JAR file to the PRE_CLASSPATH environment variable.

JConsole

Steps to use JConsole on remote process:

1) Add the following command in Weblogic server startup script:
-Dcom.sun.management.jmxremote

2) Enable Anonymous User under /Security

3) Enable IIOP under Servers//Protocols/IIOP

4) Provide user-name and password for IIOP under advance options

For JConsole:

a) In the JConsole window, select Connection > New Connection.

b) In the Connect to Agent window, select the Advanced tab.

c) On the Advanced tab, in the JMX URL box, enter:

service:jmx:rmi:///jndi/iiop://host:port/weblogic.management.mbeanservers.runtime

Where host:port is the host name and port of the Weblogic Server instance that hosts your MBeans.

For example:
service:jmx:rmi:///jndi/iiop://localhost:7001/weblogic.management.mbeanservers.runtime

d) In the User Name and Password boxes, enter the default IIOP user name and password.
e) Click Connect.

Reference URLs: http://download.oracle.com/docs/cd/E13222_01/wls/docs103/jmxinst/accesscust.html
http://java.sun.com/developer/technicalArticles/J2SE/jconsole.html

Weblogic workshop

1)Weblogic workshop debug flags:


Two ways to enable more logging for IDE:

a) Workshop.exe internally invokes workshop.cfg file, which is present in the {BEAHOME}\weblogic81\workshop directory. This file by default uses javaw, which suppresses the command window for the IDE process. Modifying this to use java instead causes the command window to appear. This window enables users to take a thread dump of the IDE process. This can be done by hitting Ctrl - Break on the command window.

b) Another option is to enable logging for the IDE. This can be done by adding the following entry to the workshop.cfg file.
-Dworkshop.enablelogging=true
sample workshop.cfg file

D:\bea\8platsp2\weblogic81\workshop
D:\bea\8platsp2\jdk141_05\jre\bin\java.exe
-XX:-UseThreadPriorities -Xmx256m -Xms64m -Xss256k -Dworkshop.enablelogging=true -client -Dsun.java2d.noddraw=true -Dsun.java2d.d3d=false - Djava.system.class.loader="workshop.core.AppClassLoader" -cp "D:\bea\8platsp2\weblogic81\workshop\wlw-ide.jar" workshop.core.Workshop

2) Process to take thread dumps on Workshop:

By default the Workshop.cfg file, which is used by the Workshop.exe file in the //workshop directory, uses javaw.exe to start the IDE process.

Changing this to java.exe will open an additional shell window along with the IDE itself, which will show the debug messages generated by the process.

Pressing a Ctrl-Break on this shell window on Windows, or doing a 'kill -3' for the IDE process on Linux, will throw a thread dump for the process on the shell window.

3) Steps to initialize all the plugins in Weblogic Workshop:

Step1: Stop the workshop (if it running)

Step2: Go to command prompt

Step3: Move to %workshopHome% directory where you find workshop.exe file

Step4: Run the following command

>Workshop.exe –clean –initialize

Step5: Start the workshop

>Workshop.exe