Salomon Zalzman

Hi Kakarla,

Look around for possibly a java core dump. In the case of a crash, the JVM may have core dumped in the working directory or somewhere in the $WAS_HOME tree. Don't remember much about v3.5.6 but I think the nanny process was part of it already and it may be restarting it.

Since it happens only on one clone, it may be worth turning on tracing even in production and work from there. With such a "mammoth" enterprise, I'm surprised your company is still running on v3.5.6. This situation makes it difficult to obtain official support from IBM.

In any case, it might also be worth backing up the configuration, removing, and re-creating the clone. With the configuration repository in a database on v3.5, there were ocassionally corruptions which destabalized the system. Those are tough to track down, hence remove/recreate.

Good luck,

Salomon Zalzman
Versant Corporation
http://www.versant.com

Hi Gaurav,

In WebSphere you implement was is called a Custom Registry. You have to implement the interface com.ibm.websphere.security.UserRegistry and add some jar files to your classpath to compile with. Implement the interface and modify the methods to suit your implementation.

You can find the details and an example in the IBM WebSphere V5.0 Security redbook which can be obtained free of charge from:

http://www.redbooks.ibm.com/redbooks/pdfs/sg246573.pdf

Good luck,

Salomon Zalzman
Versant Corporation
http://www.versant.com

Ok, since it works when you disable security, you must have the correct port number so don't be concerned about that.

The other thing I can think of here is to provide the security user Id and password in the soap.client.props. Nonetheless, I find it odd that it isn't letting you shut it down.

Also, when enabling security, make sure that the user authenticates properly by clicking the OK button once you check the "enable global security" checkbox. You should get a message stating that the user was properly authenticated. Make sure not to save the configuration until the user authenticates properly when clicking on the OK button at the bottom of the page.

Good luck,

SZ.

Hi Ajay,

I don't think you can change the soap connector port on the fly anyway. You'd need to re-start for the change to take effect.

We might need more info here. Why did you try to change it specifically to 8882. Sounds like you're running WAS base. If so, the default port would be the 8880 as indicated in the error message. Of course it could've been changed by someone.

If you can't shut it down, I assume you are still able to access the admin console. If so you can verify the SOAP port under the server1 EndPoints link (Servers->server1->EndPoints->SOAP_CONNECTOR_ADDRESS).

Disable security from the console and see if it let's you stop it then (Don't know what you've tried so far). If you can't stop it then, the process is probably in an unrecoverable state. If running Windows, kill it from the Task Manager or shutdown the box.

If running Unix, get the process Id (ps -ef | grep java) and a "kill -9" should do it. In Linux you have to kill all of the child threads as well which you could accomplish with something like
ps -ef | grep java | grep server1 | grep -v grep | awk '{print $2}' | xargs kill -9

If you can't get to the console, you can disable security manually. To do this, backup your security.xml file and load it on an editor, search for the very first ocurrance of "enabled=true" and change it to false. If you're able to get to the wsadmin prompt (I doubt it) you can issue a "securityOff" command.

After you bring the process down and disable security, start the process over. This may all be due to the process running in some unstable state. If it does come up, monitor the log files for any errors and work from there.

Hope this helps,

Salomon Zalzman
Versant Corporation
http://www.versant.com

Sounds like the Was40 database needs to be uncataloged before you can create the DB again (db2 uncatalog database Was40).

Hope this helps,

Salomon Zalzman
Versant Corporation
http://www.versant.com

Hi Sol,

You don't mention the Linux version in question but I worked on a project where just by upgrading Linux, peformance was improved by 60% and the system in general became much more stable. I know it sounds hard to believe but there is not no exageration here. This was due to several improvements and fixes to threading issues, memory optimizations, Asynchronous I/O, network performance, and a much reduced thread size. I believe the versions were Red Hat ES 2.1 going to 3.1. Perhaps you may find something similar in your implementation.

Regarding the process explosion as you call it, what you heard is correct. I think I remember a WAS nodeagent alone kicking off 42 child threads on startup and they are all listed on a "ps" command.

You may be able to find more information through your linux provider and the IBM trouble repository for WebSphere v5.

Hope this helps,

Salomon Zalzman
Versant Corporation
http://www.versant.com

You may find useful information in chapter 10 of the redbook "IBM WebSphere Application Server v5.1 System Management and Configuration".

You can get the book at http://www.redbooks.ibm.com/redbooks/pdfs/sg246195.pdf

Salomon Zalzman
Versant Corporation
http://www.versant.com

Using compound names (such as you are)for JNDI bindings is the recommended way for WAS v5 since it introduced the Federated name space concept, however, you seem to have a special need to go to Server B in your case.

You might want to try instead to use a Corbaname of the form:

corbaname::myhost1:9812/NameServiceServerRoot#ejb/com/bmc/wsm/peter/test/TestJndiHome

You can find the "Endpoints" (ports) under the server configuration. From the WebSphere admin console, select "Application Servers", click on the server in question (Server B) and click on EndPoints. You'll find a listing of ports such as SOAP and the Bootstrap address.

Hope this helps.

Salomon Zalzman
Versant Corporation
http://www.versant.com

Also, It does not come out of the box with visual tools for editing meta data or relational mapping. Some third party tools provide visualization for specific portions of Hibernate development but no one tool has all the capabilities so several tools must be used.

As far as pricing, the leading JDO vendors offer very attractive pricing models as compared to Hibernate as there is only a marginal cost for development licenses and no runtime charge. It is worth considering a JDO solution in your planning.

Salomon Zalzman
Versant Corporation
www.versant.com