Version 7.0 is the latest release WebSphere Application Server on iseries and is supported on IBM i.
http://www-03.ibm.com/systems/i/software/websphere/index.html
Showing posts with label websphere. Show all posts
Showing posts with label websphere. Show all posts
Thursday, May 07, 2009
Thursday, April 13, 2006
Basic WebSphere Application Server V5.0 and V5.1 wsadmin Programmers Guide
Websphere Application Server v5 and v5.1
Examples for the WebSphere Application Server V5.0 wsadmin tool are included in the information center, Redbooks and technotes. Many clients want to advance their skills, doing more than making minor modifications to these examples. A common goal for clients is to use wsadmin to create commands that duplicate the functionality of the administrative console.
The building blocks in this document help you build the skills necessary to correctly formulate commands that administer a WebSphere Application Server V5.x environment. This document explains how simple techniques that use wsadmin commands, and other available documentation, can help you reach your administrative design goals.
Content
Basic WebSphere Application Server V5.0 wsadmin
Programmers Guide
Index
1. Purpose
2. Official Product Documentation
3. Wsadmin Command Overview
3.1. Help
3.2. AdminApp
3.3. AdminConfig
3.4. AdminControl
4. Wsadmin Application Commands, AdminApp
4.1. Options
4.2. Interactive
5. Wsadmin Configuration Commands, AdminConfig
5.1. Basic AdminConfig Subjects
5.1.1. Types
5.1.2. Attributes
5.1.3. Required Attributes
5.1.4. Config IDs
5.2. Techniques for Formulating Administrative Configuration Commands
5.2.1. Scenario 1
5.2.2. Scenario 2
5.2.2.1. Discovering the Type
5.2.2.2. Understanding the Final Command
5.2.2.3. Forming the Final Command
6. Wsadmin Control Commands, AdminControl
7. Conclusion
--------------------------------------------------------------------------------
1. Purpose
Many examples for the WebSphere Application Server V5.0 wsadmin tool are provided in the information center, Redbooks or technotes. Many clients want to advance their skills beyond the making minor enhancements to examples, without calling IBM® Support.
The final goal for the client is the ability to create commands to mimic the administrative console and beyond. The Basic WebSphere Application Server V5.0 Wsadmin Programmers Guide advances the client skills by pointing out important documentation that IBM provides, and the simple techniques needed to correctly formulate any command to administer a WebSphere Application Server V5.x. This document shows how some public documentation and some simple techniques that use wsadmin commands, can reach the final administrative design goals.
2. Official Product Documentation
WebSphere Application Server V5.0 Information Center:
V5.0: http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp
V5.1: http://publib.boulder.ibm.com/infocenter/ws51help/index.jsp
The WebSphere Application Server Information Center contains many examples for wsadmin commands, the migration commands from WSCP to wsadmin, and information about WebSphere Application Server MBeans, JavaDoc.
The recommend starting point for new wsadmin users is the information center’s Contents view, where you can expand your WebSphere Application Server editions to find All topics by feature. Inside this view is the System administration section. Underneath System administration is Scripting, where new users can learn how to use wsadmin with the information center.
More advance users can employ good search strings to locate information directly.
One example of a generic search string is Example wsadmin; a more specific wsadmin search uses the specific command, for example, installInteractive. The search results show all the examples and descriptions that IBM has created. This is a powerful source, which IBM keeps up-to-date with current information.
WebSphere Application Server Support Web site:
http://www.ibm.com/software/webservers/appserv/was/support/
The IBM Redbooks, white papers, technotes and fixes for WebSphere Application Server are located on this Web site. The WebSphere Application Server Support Web site provides a variety of information to help you use and fix WebSphere Application Server.
The IBM Redbooks contain cook book examples for wsadmin; for example, the IBM WebSphere Application Server 5.0 System Management and Configuration Redbook contains “Command Line Administration and Scripting” in Chapter 22.
Technotes document specific examples that many customers run into that are not documented or that correct documented commands and examples from the Redbooks or other sources.
WebSphere developerWorks :
http://www.ibm.com/developerworks/websphere/
developerWorks is a Web site where advanced technical papers written by the architects and developers of WebSphere products explain the design and usage of the products.
3. Wsadmin Command Overview
Three major categories, or objects, comprise the WebSphere Application Server administration commands: AdminApp, AdminConfig and AdminControl. The most helpful command to use when lost in wsadmin is the help command.
The building blocks in this document help you build the skills necessary to correctly formulate commands that administer a WebSphere Application Server V5.x environment. This document explains how simple techniques that use wsadmin commands, and other available documentation, can help you reach your administrative design goals.
Content
Basic WebSphere Application Server V5.0 wsadmin
Programmers Guide
Index
1. Purpose
2. Official Product Documentation
3. Wsadmin Command Overview
3.1. Help
3.2. AdminApp
3.3. AdminConfig
3.4. AdminControl
4. Wsadmin Application Commands, AdminApp
4.1. Options
4.2. Interactive
5. Wsadmin Configuration Commands, AdminConfig
5.1. Basic AdminConfig Subjects
5.1.1. Types
5.1.2. Attributes
5.1.3. Required Attributes
5.1.4. Config IDs
5.2. Techniques for Formulating Administrative Configuration Commands
5.2.1. Scenario 1
5.2.2. Scenario 2
5.2.2.1. Discovering the Type
5.2.2.2. Understanding the Final Command
5.2.2.3. Forming the Final Command
6. Wsadmin Control Commands, AdminControl
7. Conclusion
1. Purpose
Many examples for the WebSphere Application Server V5.0 wsadmin tool are provided in the information center, Redbooks or technotes. Many clients want to advance their skills beyo"
Examples for the WebSphere Application Server V5.0 wsadmin tool are included in the information center, Redbooks and technotes. Many clients want to advance their skills, doing more than making minor modifications to these examples. A common goal for clients is to use wsadmin to create commands that duplicate the functionality of the administrative console.
The building blocks in this document help you build the skills necessary to correctly formulate commands that administer a WebSphere Application Server V5.x environment. This document explains how simple techniques that use wsadmin commands, and other available documentation, can help you reach your administrative design goals.
Content
Basic WebSphere Application Server V5.0 wsadmin
Programmers Guide
Index
1. Purpose
2. Official Product Documentation
3. Wsadmin Command Overview
3.1. Help
3.2. AdminApp
3.3. AdminConfig
3.4. AdminControl
4. Wsadmin Application Commands, AdminApp
4.1. Options
4.2. Interactive
5. Wsadmin Configuration Commands, AdminConfig
5.1. Basic AdminConfig Subjects
5.1.1. Types
5.1.2. Attributes
5.1.3. Required Attributes
5.1.4. Config IDs
5.2. Techniques for Formulating Administrative Configuration Commands
5.2.1. Scenario 1
5.2.2. Scenario 2
5.2.2.1. Discovering the Type
5.2.2.2. Understanding the Final Command
5.2.2.3. Forming the Final Command
6. Wsadmin Control Commands, AdminControl
7. Conclusion
--------------------------------------------------------------------------------
1. Purpose
Many examples for the WebSphere Application Server V5.0 wsadmin tool are provided in the information center, Redbooks or technotes. Many clients want to advance their skills beyond the making minor enhancements to examples, without calling IBM® Support.
The final goal for the client is the ability to create commands to mimic the administrative console and beyond. The Basic WebSphere Application Server V5.0 Wsadmin Programmers Guide advances the client skills by pointing out important documentation that IBM provides, and the simple techniques needed to correctly formulate any command to administer a WebSphere Application Server V5.x. This document shows how some public documentation and some simple techniques that use wsadmin commands, can reach the final administrative design goals.
2. Official Product Documentation
WebSphere Application Server V5.0 Information Center:
V5.0: http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp
V5.1: http://publib.boulder.ibm.com/infocenter/ws51help/index.jsp
The WebSphere Application Server Information Center contains many examples for wsadmin commands, the migration commands from WSCP to wsadmin, and information about WebSphere Application Server MBeans, JavaDoc.
The recommend starting point for new wsadmin users is the information center’s Contents view, where you can expand your WebSphere Application Server editions to find All topics by feature. Inside this view is the System administration section. Underneath System administration is Scripting, where new users can learn how to use wsadmin with the information center.
More advance users can employ good search strings to locate information directly.
One example of a generic search string is Example wsadmin; a more specific wsadmin search uses the specific command, for example, installInteractive. The search results show all the examples and descriptions that IBM has created. This is a powerful source, which IBM keeps up-to-date with current information.
WebSphere Application Server Support Web site:
http://www.ibm.com/software/webservers/appserv/was/support/
The IBM Redbooks, white papers, technotes and fixes for WebSphere Application Server are located on this Web site. The WebSphere Application Server Support Web site provides a variety of information to help you use and fix WebSphere Application Server.
The IBM Redbooks contain cook book examples for wsadmin; for example, the IBM WebSphere Application Server 5.0 System Management and Configuration Redbook contains “Command Line Administration and Scripting” in Chapter 22.
Technotes document specific examples that many customers run into that are not documented or that correct documented commands and examples from the Redbooks or other sources.
WebSphere developerWorks :
http://www.ibm.com/developerworks/websphere/
developerWorks is a Web site where advanced technical papers written by the architects and developers of WebSphere products explain the design and usage of the products.
3. Wsadmin Command Overview
Three major categories, or objects, comprise the WebSphere Application Server administration commands: AdminApp, AdminConfig and AdminControl. The most helpful command to use when lost in wsadmin is the help command.
The building blocks in this document help you build the skills necessary to correctly formulate commands that administer a WebSphere Application Server V5.x environment. This document explains how simple techniques that use wsadmin commands, and other available documentation, can help you reach your administrative design goals.
Content
Basic WebSphere Application Server V5.0 wsadmin
Programmers Guide
Index
1. Purpose
2. Official Product Documentation
3. Wsadmin Command Overview
3.1. Help
3.2. AdminApp
3.3. AdminConfig
3.4. AdminControl
4. Wsadmin Application Commands, AdminApp
4.1. Options
4.2. Interactive
5. Wsadmin Configuration Commands, AdminConfig
5.1. Basic AdminConfig Subjects
5.1.1. Types
5.1.2. Attributes
5.1.3. Required Attributes
5.1.4. Config IDs
5.2. Techniques for Formulating Administrative Configuration Commands
5.2.1. Scenario 1
5.2.2. Scenario 2
5.2.2.1. Discovering the Type
5.2.2.2. Understanding the Final Command
5.2.2.3. Forming the Final Command
6. Wsadmin Control Commands, AdminControl
7. Conclusion
1. Purpose
Many examples for the WebSphere Application Server V5.0 wsadmin tool are provided in the information center, Redbooks or technotes. Many clients want to advance their skills beyo"
Sunday, January 30, 2005
WAS Application hangs with previous J2CA0086W warning messages STATE_TRAN_WRAPPER_INUSE
IBM - Application hangs with previous J2CA0086W warning messages: "Application hangs with previous J2CA0086W warning messages STATE_TRAN_WRAPPER_INUSE
Technote (FAQ)
Problem
An application seems to be in a hang state while trying to connect to database. The logs show several ConnectionWaitTimeoutExceptions as well as other errors referring to problems obtaining free connections from the pool. Before occurrences of hang there are repeated J2CA0086W warning messages and the connection pool is at a maximum.
Cause
A warning message similar to the one below is observed in the logs before the hang occurs:
[8/19/03 21:37:53:366 CST] 1c86bdf0 SharedPool I J2CA0086W: Shareable connection MCWrapper id 686bbdf9 Managed connection com.ibm.ws.rsadapter.spi.WSRdbManagedConnectionImpl@6156bdf9
State:STATE_TRAN_WRAPPER_INUSE
The message reference contains the following explanation of this message:
J2CA0086W: Shareable connection {0} from resource {1} was used within a local transaction containment boundary.
Explanation: Shareable connections are not allowed within a local transaction containment boundary.
User Response: Connection was made non-shareable.
The above scenario suggests a possible problem in the application logic and how it is using the connection code. The J2CA0086 message is telling you that your application is using a shared connection in a LocalTransaction. Since the connection is enlisted in a Local Transaction, and not a Global Transaction, different rules are followed when it comes to connection sharing. The connection usage has to follow the pattern shown below:
get connection,
use connection,
close connection,
commit transaction
then the connection can be used again. If this logic is not followed, a second (or third) connection can be allocated.
For example, if the application calls getConnection() method it gets connection1, uses connection1, then, if it calls getConnection() method again and connection1 is not ready to be reused, connection2 is obtained. Both connections remain in the shared pool and both are associated with the Local Transaction, until the Local Transaction ends (is committed or rolled back, or the method ends).
This can result in more connections being created than is expected, which is why the application is reaching the maximum connections, and getting ConnectionWaitTimeoutExceptions among others). This can cause a hang if the pool is at a maximum, and none of the threads that have connections can complete because they are waiting to get another connection.
Solution
There are two solutions to this problem:
The application must be modified to use serial reuse
or
The maximum number of connections must be increased (you can use 0, which means infinite connections).
In general you will see better performance with a lower number of connections, so the best solution to the problem is to make sure that the application closes its connections when it's done using them If it needs another connection later, it calls getConnection again (the connection pool caches the physical connection and allows it to be reused, so the performance hit is less than leaving the connections open).
STATE_TRAN_WRAPPER_INUSE J2CA0086W
Technote (FAQ)
Problem
An application seems to be in a hang state while trying to connect to database. The logs show several ConnectionWaitTimeoutExceptions as well as other errors referring to problems obtaining free connections from the pool. Before occurrences of hang there are repeated J2CA0086W warning messages and the connection pool is at a maximum.
Cause
A warning message similar to the one below is observed in the logs before the hang occurs:
[8/19/03 21:37:53:366 CST] 1c86bdf0 SharedPool I J2CA0086W: Shareable connection MCWrapper id 686bbdf9 Managed connection com.ibm.ws.rsadapter.spi.WSRdbManagedConnectionImpl@6156bdf9
State:STATE_TRAN_WRAPPER_INUSE
The message reference contains the following explanation of this message:
J2CA0086W: Shareable connection {0} from resource {1} was used within a local transaction containment boundary.
Explanation: Shareable connections are not allowed within a local transaction containment boundary.
User Response: Connection was made non-shareable.
The above scenario suggests a possible problem in the application logic and how it is using the connection code. The J2CA0086 message is telling you that your application is using a shared connection in a LocalTransaction. Since the connection is enlisted in a Local Transaction, and not a Global Transaction, different rules are followed when it comes to connection sharing. The connection usage has to follow the pattern shown below:
get connection,
use connection,
close connection,
commit transaction
then the connection can be used again. If this logic is not followed, a second (or third) connection can be allocated.
For example, if the application calls getConnection() method it gets connection1, uses connection1, then, if it calls getConnection() method again and connection1 is not ready to be reused, connection2 is obtained. Both connections remain in the shared pool and both are associated with the Local Transaction, until the Local Transaction ends (is committed or rolled back, or the method ends).
This can result in more connections being created than is expected, which is why the application is reaching the maximum connections, and getting ConnectionWaitTimeoutExceptions among others). This can cause a hang if the pool is at a maximum, and none of the threads that have connections can complete because they are waiting to get another connection.
Solution
There are two solutions to this problem:
The application must be modified to use serial reuse
or
The maximum number of connections must be increased (you can use 0, which means infinite connections).
In general you will see better performance with a lower number of connections, so the best solution to the problem is to make sure that the application closes its connections when it's done using them If it needs another connection later, it calls getConnection again (the connection pool caches the physical connection and allows it to be reused, so the performance hit is less than leaving the connections open).
STATE_TRAN_WRAPPER_INUSE J2CA0086W
Thursday, January 13, 2005
Updating an EAR application into WAS Websphere Application Server from as400 WSAD / WDSC / WSSD using WAS admin client
Updating an EAR application into WAS Websphere Application Server from as400 WSAD / WDSC / WSSD using WAS admin client
Look for more on as400 WSAD / WDSC / WSSD
- Navigate to WAS Admin client via your browser and login
- Click Applications
- Click Enterprise Applications
- Tick the relevant application, and click stop (Before you do this take a look at the server name in the left from to make sure you looking at the right server instance, ie development rather than production! Also make sure you stop the right application!)
- When the status changes to stopped (Hover pointer to see various status's), tick the application and click update button
- Click browse to find the file (either from local path or server), and click next. At this point the EAR file will be uploaded to the server
- On the binding page I usually accept the defaults, so click next if your not sure
- On 'Provide options to perform the installation ', unless you need to change any of the settings, click next
- On 'Map virtual hosts for web modules ', select the virtual host that your application is installed under. If you on the as400 / iseries and you cant remember the virtual host at this point, login to the HTTP Server admin client, and look at the properties for the WAS application from there and it will tell you the virtual host it is installed under. The other option is to find the WAS HTTP plugin file, as this info is stored in there.
- Click next
- Unless you need to change these, on 'Map modules to application servers ' , click next
- Click Finish
- At this point, the application is installed to a temporary area. To finish the process, you need to click 'Save to Master Configuration'
- Click save to update the master repository (Or discard to abandon your changes)
- Click Enterprise Applications,select your application, and click start to restart your application
- Your Done!
Look for more on as400 WSAD / WDSC / WSSD
Monday, January 10, 2005
Websphere Web module or application server dies or hangs
From IBM Infocenter:
Web module or application server dies or hangs
If an application server dies (its process spontaneously closes), or freezes (its Web modules stop responding to new requests):
Isolate the problem by installing Web modules on different servers, if possible. Read the Monitoring performance with Tivoli performance viewer (formerly resource analyzer) topic. You can use the performance viewer to determine which resources have reached their maximum capacity, such as Java heap memory (indicating a possible memory leak) and database connections. If a particular resource appears to have reached its maximum capacity, review the application code for a possible cause: If database connections are used and never freed, ensure that application code performs a close() on any opened Connection object within a finally{} block. If there is a steady increase in servlet engine threads in use, review application synchronized code blocks for possible deadlock conditions. If there is a steady increase in a JVM heap size, review application code for memory leak opportunities, such as static (class-level) collections, that can cause objects to never get garbage-collected. As an alternative to using the performance viewer to detect memory leak problems, enable verbose garbage collection on the application server. This feature adds detailed statements to the JVM error log file of the application server about the amount of available and in-use memory. To set up verbose garbage collection: Select Servers > Application Servers > server_name > Process Definition > Java Virtual Machine, and enable Verbose Garbage Collection. Stop and restart the application server.
Periodically, or after the application server stops, browse the log file for garbage collection statements. Look for statements beginning with "allocation failure". The string indicates that a need for memory allocation has triggered a JVM garbage collection (freeing of unused memory). Allocation failures themselves are normal and not necessarily indicative of a problem. The allocation failure statement is followed by statements showing how many bytes are needed and how many are allocated.
If there is a steady increase in the total amount of free and used memory (the JVM keeps allocating more memory for itself), or if the JVM becomes unable to allocate as much memory as it needs (indicated by the bytes needed statement), there might be a memory leak.
If neither the performance viewer or verbose garbage collection output indicates that the application server is running out of memory, one of the following problems might be present: There is a memory leak in application code that you must address. To pinpoint the cause of a memory leak, enable the RunHProf function in the Servers > Application Servers > server_name > Process Definition > Java Virtual Machine pane of the problem application server: In the same JVM pane, set the HProf Arguments field to a value similar to depth=20,file=heapdmp.txt. This value shows exception stacks to a maximum of 20 levels, and saves the heapdump output to the install_root/bin/heapdmp.txt file. Save the settings.
Stop and restart the application server.
Re-enact the scenario or access the resource that causes the hang or crash, if possible. Stop the application server. If this is not possible, wait until the hang or crash happens again and stop the application server. Examine the file into which the heapdump was saved. For example, examine the install_root/bin/heapdmp.txt file: Search for the string, "SITES BEGIN". This finds the location of a list of Java objects in memory, which shows the amount of memory allocated to the objects. The list of Java objects occurs each time there was a memory allocation in the JVM. There is a record of what type of object the memory instantiated and an identifier of a trace stack, listed elsewhere in the dump, that shows the Java method that made the allocation. The list of Java object is in descending order by number of bytes allocated. Depending on the nature of the leak, the problem class should show up near the top of the list, but this is not always the case. Look throughout the list for large amounts of memory or frequent instances of the same class being instantiated. In the latter case, use the ID in the trace stack column to identify allocations occurring repeatedly in the same class and method. Examine the source code indicated in the related trace stacks for the possibility of memory leaks. The default maximum heap size of the application server needs to be increased.
There is a defect in the WebSphere Application Server product that you must either report, or correct by installing a fix or FixPak, from a maintenance download. Contact IBM support. If an application server spontaneously dies, look for a Java thread dump file. The JVM creates the file in the product directory structure, with a name like javacore[number].txt. Force an application to create a thread dump (or javacore). Here is the process for forcing a thread dump, which is different from the process in earlier releases of the product: Using the wsadmin command prompt, get a handle to the problem application server: wsadmin>set jvm [$AdminControl completeObjectName type=JVM,process=server1,*] Generate the thread dump: wsadmin>$AdminControl invoke $jvm dumpThreads.
Look for an output file in the installation root directory with a name like javacore.date.time.id.txt. Browse the thread dump for clues: If the JVM creates the thread dump as it closes (the thread dump is not manually forced), there might be "error" or "exception information" strings at the beginning of the file. These strings indicate the thread that caused the application server to die. The thread dump contains a snapshot of each thread in the process, starting in the section labeled "Full thread dump." Look for threads with a description that contains "state:R". Such threads are active and running when the dump is forced, or the process exited. Look for multiple threads in the same Java application code source location. Multiple threads from the same location might indicate a deadlock condition (multiple threads waiting on a monitor) or an infinite loop, and help identify the application code with the problem.
If these steps do not fix your problem, search to see if the problem is known and documented, using the methods identified in the available online support (hints and tips, technotes, and fixes) topic. If you find that your problem is not known, contact IBM support to report it.
Web module or application server dies or hangs
If an application server dies (its process spontaneously closes), or freezes (its Web modules stop responding to new requests):
Isolate the problem by installing Web modules on different servers, if possible. Read the Monitoring performance with Tivoli performance viewer (formerly resource analyzer) topic. You can use the performance viewer to determine which resources have reached their maximum capacity, such as Java heap memory (indicating a possible memory leak) and database connections. If a particular resource appears to have reached its maximum capacity, review the application code for a possible cause: If database connections are used and never freed, ensure that application code performs a close() on any opened Connection object within a finally{} block. If there is a steady increase in servlet engine threads in use, review application synchronized code blocks for possible deadlock conditions. If there is a steady increase in a JVM heap size, review application code for memory leak opportunities, such as static (class-level) collections, that can cause objects to never get garbage-collected. As an alternative to using the performance viewer to detect memory leak problems, enable verbose garbage collection on the application server. This feature adds detailed statements to the JVM error log file of the application server about the amount of available and in-use memory. To set up verbose garbage collection: Select Servers > Application Servers > server_name > Process Definition > Java Virtual Machine, and enable Verbose Garbage Collection. Stop and restart the application server.
Periodically, or after the application server stops, browse the log file for garbage collection statements. Look for statements beginning with "allocation failure". The string indicates that a need for memory allocation has triggered a JVM garbage collection (freeing of unused memory). Allocation failures themselves are normal and not necessarily indicative of a problem. The allocation failure statement is followed by statements showing how many bytes are needed and how many are allocated.
If there is a steady increase in the total amount of free and used memory (the JVM keeps allocating more memory for itself), or if the JVM becomes unable to allocate as much memory as it needs (indicated by the bytes needed statement), there might be a memory leak.
If neither the performance viewer or verbose garbage collection output indicates that the application server is running out of memory, one of the following problems might be present: There is a memory leak in application code that you must address. To pinpoint the cause of a memory leak, enable the RunHProf function in the Servers > Application Servers > server_name > Process Definition > Java Virtual Machine pane of the problem application server: In the same JVM pane, set the HProf Arguments field to a value similar to depth=20,file=heapdmp.txt. This value shows exception stacks to a maximum of 20 levels, and saves the heapdump output to the install_root/bin/heapdmp.txt file. Save the settings.
Stop and restart the application server.
Re-enact the scenario or access the resource that causes the hang or crash, if possible. Stop the application server. If this is not possible, wait until the hang or crash happens again and stop the application server. Examine the file into which the heapdump was saved. For example, examine the install_root/bin/heapdmp.txt file: Search for the string, "SITES BEGIN". This finds the location of a list of Java objects in memory, which shows the amount of memory allocated to the objects. The list of Java objects occurs each time there was a memory allocation in the JVM. There is a record of what type of object the memory instantiated and an identifier of a trace stack, listed elsewhere in the dump, that shows the Java method that made the allocation. The list of Java object is in descending order by number of bytes allocated. Depending on the nature of the leak, the problem class should show up near the top of the list, but this is not always the case. Look throughout the list for large amounts of memory or frequent instances of the same class being instantiated. In the latter case, use the ID in the trace stack column to identify allocations occurring repeatedly in the same class and method. Examine the source code indicated in the related trace stacks for the possibility of memory leaks. The default maximum heap size of the application server needs to be increased.
There is a defect in the WebSphere Application Server product that you must either report, or correct by installing a fix or FixPak, from a maintenance download. Contact IBM support. If an application server spontaneously dies, look for a Java thread dump file. The JVM creates the file in the product directory structure, with a name like javacore[number].txt. Force an application to create a thread dump (or javacore). Here is the process for forcing a thread dump, which is different from the process in earlier releases of the product: Using the wsadmin command prompt, get a handle to the problem application server: wsadmin>set jvm [$AdminControl completeObjectName type=JVM,process=server1,*] Generate the thread dump: wsadmin>$AdminControl invoke $jvm dumpThreads.
Look for an output file in the installation root directory with a name like javacore.date.time.id.txt. Browse the thread dump for clues: If the JVM creates the thread dump as it closes (the thread dump is not manually forced), there might be "error" or "exception information" strings at the beginning of the file. These strings indicate the thread that caused the application server to die. The thread dump contains a snapshot of each thread in the process, starting in the section labeled "Full thread dump." Look for threads with a description that contains "state:R". Such threads are active and running when the dump is forced, or the process exited. Look for multiple threads in the same Java application code source location. Multiple threads from the same location might indicate a deadlock condition (multiple threads waiting on a monitor) or an infinite loop, and help identify the application code with the problem.
If these steps do not fix your problem, search to see if the problem is known and documented, using the methods identified in the available online support (hints and tips, technotes, and fixes) topic. If you find that your problem is not known, contact IBM support to report it.
Thursday, December 23, 2004
IBM WebSphere Developer Technical Journal: Extending the IBM WebSphere Platform with Adobe Intelligent Documents
IBM WebSphere Developer Technical Journal: Extending the IBM WebSphere Platform with Adobe Intelligent Documents: "Extending the IBM WebSphere Platform with Adobe Intelligent Documents"
Subscribe to:
Posts (Atom)