Nodeagent status is not appearing in adminconsole (WAS 6.1.0.19) - Websphere

Nodeagent status is not updating in Admin console of WAS 6.1 env. Which is started successfully through command line and logs are also not showing any errors. restarted DMGR and Nodeagent, sycnNode with DMGR-soap, still it is appearing red mode in admin console.

The only 2 reasons I can think of si, that either the nodes havent been federated, or that the nodes cant contact the Dmgr.

Follow the blow steps to come out of this issue:

Well, I had the same problem but it was not 6.1 its was on 6.0. I opened a PMR with IBM and they suggested me to do the following steps

1) Stop the dmgr and Stop the nodeagent and application server

2) Clear all content under temp of dmgr wstemp of dmgr, logs/dmgr, logs/ffdc of dmgr, logs/nodeagent, logs/jvm and logs/ffdc of nodeagent

for example

/opt/IBM/WebSphere/AppServer/profiles/BT1_Dmgr/temp
/opt/IBM/WebSphere/AppServer/profiles/BT1_Dmgr/wstemp

/opt/IBM/WebSphere/AppServer/profiles/BT1_Dmgr/logs/dmgr
/opt/IBM/WebSphere/AppServer/profiles/BT1_Dmgr/logs/Activity.log
/opt/IBM/WebSphere/AppServer/profiles/BT1_Dmgr/logs/ffdc

on Node

/opt/IBM/WebSphere/AppServer/profiles/PT2_AppSrv01/logs/jvm
/opt/IBM/WebSphere/AppServer/profiles/PT2_AppSrv01/logs/nodeagent
/opt/IBM/WebSphere/AppServer/profiles/PT2_AppSrv01/logs/ffdc

3) start the dmgr only

4) once dmgr is up. Manually sync the node with dmgr using syncnode command on node

for example: syncnode.sh dmgrhostname dmgrsoapport -username user -password password

5) start the nodeagent only

6) once the nodeagent is up start the application server from console. and try to stop the application server see if problem occurs

SRVE0133E: An error occurred while parsing parameters. java.net.SocketTimeoutException: Async operation timed out

You might have seen this error in your websphere environment.

[9/28/09 22:23:29:538 EST] 00000040 SRTServletReq E   SRVE0133E: 

An error occurred 

while parsing parameters. java.net.SocketTimeoutException:

 Async operation timed out
 at com.ibm.ws.tcp.channel.impl.AioTCPReadRequestContextImpl.

processSyncReadRequest

(AioTCPReadRequestContextImpl.java:157)
 at com.ibm.ws.tcp.channel.impl.TCPReadRequestContextImpl.read

(TCPReadRequestContextImpl.java:109)
 at com.ibm.ws.http.channel.impl.HttpServiceContextImpl.fillABuffer

As you can see this error will originate from Web Container’s http transport channel. And the reason for this error to come is Network delay. By default, in WebSphere application server, ConnectionTimeout will be set to 5 seconds for http transport channels. So if your network is slow, you may see this error in the logs

If you would like to change this timeout settings, follow these steps:

• • • • Application Servers -> serverA -> Web Container -> HTTP Transport -> Application Name
      • go to custom properties
      • Add these two parameters (where xx is the time in seconds)
      • ConnectionIOTimeOut=xx and ConnectionKeepAliveTimeout=xx
      • Repeat this for all servers, if your application is mapped to multiple servers.
      • Restart the server (s)

WebGroup / virtual host not defined error in WebSphere

When you have a “WebGroup / virtual host not defined” error what to do?

If we find in log file can see this error:

PLGN0021E: Servlet Request Processor Exception: Virtual Host/WebGroup Not Found : The host xxxxxxx has not been defined.

Access application from app server: By pass the web server and access the application directly from the application server using app_server_name:port/context_root

Check any recent application install/update: If you have recently updated or installed the application, ensure that the Web server plug-in was regenerated and propagated to the Web server. Also, ensure
that the Web server is using the new plug-in configuration file.

Verify Plug-in is working: Attempt to access other applications running on the same application server through the Web server. If you can access another application, this will verify that the plug-in and Web server are working with the application server, but not necessarily that the plug-in configuration is correct.

Verify Virtual Host/ Host Alias etc..

Verify that the virtual host associated with the Web module has a host alias defined containing the host name and port matching the host name and port in the URL causing the failure.

1. Find the URL pattern for the servlet.
2. Find the context root of the Web module containing the servlet.
3. Find the virtual host where the Web module is installed.
4. Find the aliases by which the virtual host is known.

After finding above four, check the following:

• Combine the virtual host alias, context root and URL pattern to form the correct URL request for the servlet.
• Compare the correct URL for the servlet with the URL reported in the problem.
• If they are the same, verify the resource file exists in the deployed application.
• If not, correct the application calling the resource.

If you don’t know how to check url pattern/context root/virtual host/host alias….follow these instructions

• Finding URL pattern

1. In the administrative console, select Applications -> Enterprise Applications.
2. Click on the application name.
3. Select Manage Modules.
4. Click the WebModule_name Web application
5. Click View Deployment Descriptor.
Look for the servlet in a <servlet-mapping> entry and note the url-pattern value.
Note: If the Web module has security configured, check the <security-constraint> and <security-role> deployment descriptor tags for the role that is needed for access to the selected Web resource.

• Finding the context root of the web module

1. Select Applications ?Enterprise Applications.
2. Click on the application name.
3. Click on Context Root for Web Modules.
4. Note the context root for the appropriate Web module.

• Finding the virtual host used for application

Find the virtual host where the Web module is installed:
1. Select Applications ?Enterprise Applications.
2. Click on the application name.
3. Click on Virtual hosts under Web Module Properties.
4. Note the virtual host for the Web module.

• Finding the host aliases for the virtual host

1. From the console navigation tree, select Environment ?Virtual Hosts.
2. Click on the virtual host.
3. Select Host Aliases under Additional Properties.

An alias is composed of a host name and port number. Each alias represents a valid host:port combination for the Web module to be accessed from web server.

[9/28/09 22:23:29:538 EST] 00000040 SRTServletReq E SRVE0133E: An error occurred while parsing parameters. java.net.SocketTimeoutException: Async operation timed out

[9/28/09 22:23:29:538 EST] 00000040 SRTServletReq E   SRVE0133E: An error occurred while parsing parameters. java.net.SocketTimeoutException: Async operation timed out
Explanation:

As you can see this error will originate from Web Container’s http transport channel. And the reason for this error to come is Network delay. By default, in WebSphere application server, ConnectionTimeout will be set to 5 seconds for http transport channels. So if your network is slow, you may see this error in the logs

If you would like to change this timeout settings, follow these steps:

• Application Servers -> serverA -> Web Container -> HTTP Transport -> Application Name
• go to custom properties
• Add these two parameters (where xx is the time in seconds)
• ConnectionIOTimeOut=xx and ConnectionKeepAliveTimeout=xx
• Repeat this for all servers, if your application is mapped to multiple servers.
• Restart the server (s)

Memory leak detection and analysis in WebSphere Application Server: Part 1: Overview of memory leaks

Overview of memory leaks

############################################################

WMSG1603E - An error occurred trying to read the bundle

WMSG1603E - An error occurred trying to read the bundle


I encountered a strange error this weekend whilst installing multiple fix packs across numerous WAS systems. Despite installing these fixes numerous times, this error only occurred on one system.


I was upgrading from WAS 6.1.0.21 to 6.1.0.27 - that included WAS, SDK, IHS and Plugin fixes.


After installing the fix packs when I restarted the server I got the following error:


WMSG1603E: An internal error occurred. It was not possible to register the WebSphere MQ JMS client with the application serve

r due to exception org.osgi.framework.BundleException: An error occurred trying to read the bundle



followed by a java stack which included the following:

WMSG1603E: An internal error occurred. It was not possible to register the WebSphere MQ JMS client with the application serve

r due to exception org.osgi.framework.BundleException: An error occurred trying to read the bundle

A quick search and the reason was obvious. This WAS system does not run as root but when I checked the file permissions on the org.osgi.framework bundles in {WAS_INSTALL_DIR}/profiles/{PROFILE_NAME}/configuration the bundle in question was owned by root:


drwxr-x--- 2 wasadm wasadm 256 07 Feb 10:25 org.eclipse.update

drwxr-xr-x 4 root system 256 07 Feb 10:26 org.eclipse.osgi

drwxr-x--- 3 wasadm wasadm 256 04 Jan 11:24 org.eclipse.core.runtime


A quick change of permissions on the directory and all sub directories followed by a restart and everything came up fine.

If the installation fails, what are the probable reasons? Where do I check?

If the installation fails, what are the probable reasons? Where do I check?


* Confirm the installation failed by finding “INSTCONFFAILED” and EXITCODE=1 messages in /logs/install/install.log file.

* If you were enable trace you can find same messages and more info from /logs/install/trace.txt.

* Check the command prompt from which the installation panel was launched for error messages.

* Look up any error or warning messages in the message reference table by selecting the ″Reference″ view in the information center navigation and expanding the ″Messages″ heading.

* Check the profiles logs to find out error messages and proceed according to them

* Missing prerequisites

* Incorrect response file configuration during a silent install

* Errors due to limitations in non-root installations

Errors in WebSphere Application Server 6.1.0.9 when enabling SSL

I was working on a SSL configuration in one of my WAS servers and after I changed the default SSL setting I couldn't start the server (server1) anymore.


These are the errors I was getting (SystemOut.log for server1):

-----------------------------------

0000000a WSKeyStore E CWPKI0033E: The keystore located at "...../emsNode01Cell/nodes/emsNode01/trust.p12" failed to load due to the following error: Unable to verify MAC..

0000000a ORBRas E com.ibm.ws.orbimpl.transport.WSTransport createServerSocket P=173499:O=0:CT ORBX0390E: Cannot create listener thread. Exception=[ org.omg.CORBA.INTERNAL: CAUGHT_EXCEPTION_WHILE_CONFIGURING_SSL_SERVER_SOCKET, Exception=com.ibm.websphere.ssl.SSLException: java.io.IOException: Unable to verify MAC. vmcid: 0x49421000 minor code: 77 completed: No ].

----------------------

I went online and the only thing I found was asking me to go to the WAS Console and change the SSL configuration back to default. But, How I can do it if my server doesn't start ?


Well, the answer is easy (after you know how to do it):

Open your Security.xml file and fix it. My error was related to a wrong password in the trust.p12 file.... the password I didn't change. When I created a new SSL configuration with new Trust and Key stores, the password for trust.p12 got changed.

Open the Security.xml and check for any inconsistence

The password for trust.p12 had been changed to the password being used my SametimeTrustStore. Finally, default key and trust stores created by WebSphere have the same password ({xor}CDo9Hgw=), so I changed it back to the original and everything started working again.



This problem has been fixed in 6.1.0.13.
 
##########################################################################

EnableTrace in Plugin-cfg.xml

WebServer Plugin writes a log, by default its named as http-plugin.log, by default placed under PLUGIN_HOME/logs/
Plugin writes Error messages into this log. The attribute which deals with this is
< Log > in the plugin-cfg.xml
Ex.,
< Log LogLevel="Error" Name="/usr/IBM/WebSphere/Plugins/logs/http_plugin.log" / >

According to above line all Error messages will be written into http-plugin.log.

How to enable trace in the plugin-cfg.xml? if that is the question, do like this -

< Log LogLevel="Trace" Name="/usr/IBM/WebSphere/Plugins/logs/http_plugin.log" / >

From the InfoCenter -
Plug-in Problem Determination Steps
The plug-in provides very readable tracing which can be beneficial in helping to figure out the problem. By setting the LogLevel attribute in the config/plugin-cfg.xml file to Trace, you can follow the request processing to see what is going wrong.
Note: If you are using a Veritas File System with large file support enabled, file sizes up to two terabytes are allowed. In this case, if you set the LogLevel attribute in the plugin-cfg.xml file to LogLevel=Trace, then the http_plugin.log file might grow quickly and consume all available space on your file system. Therefore, you should set the value of the LogLevel attribute to ERROR or DEBUG to prevent high CPU utilization.
At a high level, complete these steps.
The plug-in gets a request.
The plug-in checks the routes defined in the plugin-cfg.xml file.
It finds the server group.
It finds the server.
It picks the transport protocol, HTTP or HTTPS.
It sends the request.
It reads the response.
It writes it back to the client.