Pages

25 January 2012

It may happen that all of a sudden you will see the following exception in your SystemOut.log of your managed server (that is the one managed from deployment manager console via nodeagent process). That may occur during either server run or (more often) during server startup attempted from shell level.

It usually means that your server has lost communication with it's nodeagent, and the reasons for that may be numerous, but the most common are:

nodeagent process crashed or was killed any other way - that is the easiest: just bring up back the nodeagent

something went wrong with network interfaces (that's more applicable to startup problem) - in that case you need to try to bring up/down lo interface (read here) or check if in the meantime your hostname or ip address hadn't been changed (little chance, but you never know)

if above fail, check if nodeagent NDS (node discovery service) port, among with other ports (soap etc.) are locally available with telnet. if not, you need to diagnose further system's ip sockets setup.

19 January 2012

If you see the following exception while or after starting your server (nodeagent or app server):JSSL0080E: javax.net.ssl.SSLHandshakeException - The client and server could not negotiate the desired level of security. then big chance is that there's something wrong with internal certificates between WAS instances, either:1. Hostname has been changed and hostname verification is turned on in SSL
setup. you may check this
here:http://www.ibm.com/developerworks/websphere/techjournal/0612_birk/0612_birk.htmlin paragraph:

The
default trust manager, IbmX509, performs fundamental certificate
validation, including the certificate signature validation (ensuring it
has not been modified) and certificate expiration validation (ensuring
it has not expired). This trust manager does not perform hostname
verification by default, although you can set the
com.ibm.ssl.performURLHostNameVerification=true property
in the security custom properties to enable this function for URL
connections only. If this is done, the trust manager will ensure that
for URL connections, the hostname specified on the connection matches
the SubjectDN in the certificate returned by the server (just as Web
browsers do). (recommend reading the whole article btw.)

2. Something went horribly wrong in terms of cell synchronization, so I'd
suggest stopping servers and nodeagent on remote machine and running
./syncNode.sh from profile's bin directory. not sure it will work as
probably wsadmin script client won't be able to connect to SOAP port due
to root cause. hence, we're back at point 1. and I guess only manual
copying of trust/keystores from dmgr machine to remote machine might help.

16 January 2012

Okay, there are numerous articles on how to trace XML SOAP messages sent to websphere server, but it seems all of them address some different scenario I am in. Eg. they involve custom development or code-changing in order to add handlers and so on.

What I needed was to simply dump content of SOAP messages incoming to my http inbound channel. However, anything less than wssecurity.*=all given no SOAP content, so I started to drill down to the very one I needed. Finally I found some least fraction of WAS framework to check if you want to get incoming XML content, out of WSSecurityHandler class. As XML parsing involves security processing, you simply need to use the following trace:

13 January 2012

Ever wondered how to disable SSL between IHS and WebSphere App Server? In some environments, your IHS and WAS remain in secure zone, and you don't want to spend any CPU time for doing SSL between web server and backend server.
In case of IBM HTTP Server + WAS combination there's a simple way to do it:

assuming you have Plugin already configured for IHS, you need to edit it's config (plugin-cfg.xml) with some editor eg. vi

It's a bit off topic, but worth noting: LG is going to release virtualized mobile phone. What for ? They claim many people are tired of carrying around two phones - privateone and the one from your employer so here's a thing: on new LG you'll be able to run two Android systems to provide for separate virtual devices for personal and professional use. VMWare folks did a good job. And well, it might as well work for me, although I'm rather cold for gadgets :)
You may rea more on ExpertsExchange. Let's see what more comes from CES 2012.

04 January 2012

When working with WebSphere Process Server (or Enterprise Service Bus, which is a limited set of WPS functionality) you may run into a problem with using database for messaging engines. That appears as a series of errors in SystemOut.log file during particular server startup, while the errors are: CWSIS1538I,CWSIS1545I,CWSIS1535E and CWSIS1546I. That usually means that you are trying to re-use SIB tables in the database, that were previously used by another WebSphere instance. Good example of this problem is given here in infoCenter but to say short that is what you need to do:

find database used by WPS/ESB

check if <YOURSCHEMA>.SIBOWNER table exists and what are it's contents (simply: SELECT * FROM <YOURSCHEMA>.SIBOWNER

you'll see that there's some ME UUID (messaging engine unique id) exists that is preventing WPS/ESB to start using this table exclusively (WPS needs to "know" that SIB tables are his and only his, so you need to ensure he can think so)

clear SIBOWNER table with DELETE * FROM <YOURSCHEMA>.SIBOWNER

restart the server and check if errors are gone

My recommendation (as well as support's) is to clear all tables used by SIB engine (which ones? check out in DB generation ddls, produced by sibDDLGenerator.sh scripts) to ensure no further data conflict will occur in future.

- or use passwordexpiry.war application supplied by helpful guys from Australia.
I did this and even enhanced app's functionality, but I need some confirmation from the authors that it has been
posted in the article.