What’s the difference between “managed” web servers and “unmanaged” web servers?
I’m glad you asked! There are several types of web servers that can be used with IBM WebSphere Application Server (WAS), including the Apache HTTP Server, Microsoft IIS web server and Sun Java System web server, among others. However, these non-IBM web servers CANNOT be controlled by IBM’s WebSphere Application Server (WAS).
Only the IBM HTTP Server (IHS) can be controlled by IBM WAS. And it’s the IBM HTTP Server (IHS) web server, specifically, that drives the concept of “managed” versus “unmanaged.”
A managed IHS web server is one that is installed on the same system as a WAS node agent and controlled by that WAS node agent.
WAS Admin —commands–> WAS node agent —controls–> IHS web server
An unmanaged IHS web server is one that is installed on a system that does not have any WAS node agent; therefore, it must use the IBM HTTP Server Administration Server to be controlled from WAS.
WAS Admin —commands–> IHS Admin server —controls–> IHS web server
It’s possible to use WAS Admin console to control the IHS web server in both cases. Managed simply means that the commands go from WAS Admin to a WAS node agent that controls the IHS web server on that system. Unmanaged means that the commands go from WAS Admin to an IHS Admin server which controls the IHS web server on that system.
Maybe an example will help shed some light on this concept: IHS installed on a stand-alone WAS server (no node agent) can be controlled by WAS only if the IHS Admin Server is configured and running. This is an unmanaged scenario. In version 8.0 and later, the Plug-in Configuration Tool (PCT) refers to this as “local_standalone” config type.
Here’s another example to explain further: IHS installed on a WAS node that’s federated to a WAS cell, and under the control of a WAS deployment manager, can be controlled by the WAS deployment manager – sending commands through the WAS node agent on the IHS system. This is the managed scenario. In version 8.0 and later, the Plug-in Configuration Tool (PCT) refers to this as “local_distributed” config type. Note the difference between the config types in our two examples.
What about IHS installed on the WAS deployment manager system itself?
If there’s also a federated WAS node on that same system, you can use that WAS node agent to control the IHS web server in a managed scenario (local_distributed).
If there is not any federated WAS node on that same system, you will need to use IHS Admin Server to control the IHS web server in an unmanged scenario (local_standalone).
If the IHS web server is installed on a separate system that does not have any WAS, and you want to control it remotely from the WAS Admin Console on another system, that would be considered an unmanaged scenario, so you will need to use the IHS Admin Server on the IHS system. In version 8.0 and later, the plugin Configuration Tool (PCT) refers to this as “remote” config type.
WAS Admin —commands across network—> IHS Admin server —controls–> IHS web server
For detailed instructions on how to configure IHS, plugin, or IHS Admin server, please contact consulting@txmq.com. To speak with a TxMQ WebSphere sales representative, call (716) 636-0070 (228) for company Vice President Miles Roty.
Tag: websphere application server
Server Issues With WebSphere Application Server In Relational Database
WebSphere news from IBM: December 11, 2013
Technote (troubleshooting)
Problem(Abstract)
If you have chosen to store your WebSphere Application Server transaction and compensation logs in a Relational Database, and your system has constrained resources, the server might fail to start.
Cause
The recovery log service has attempted to obtain information from the WebSphere Application Server Directory Service before that service has fully initialized, and this recovery log service operation has timed out. The length of time taken for the directory service to initialize can vary depending on your system environment.
Diagnosing the problem
The following exception is reported in the WebSphere Application Server log file:
WsServerImpl E WSVR0009E: Error occurred during startup
com.ibm.ws.exception.RuntimeError: com.ibm.ws.recoverylog.spi.InternalLogException: Failed to locate DataSource, com.ibm.ws.recoverylog.spi.InternalLogException: Failed to locate DataSource
at com.ibm.ws.tx.util.WASTMHelper.asynchRecoveryProcessingComplete(WASTMHelper.java:176)
at com.ibm.tx.util.TMHelper.asynchRecoveryProcessingComplete(TMHelper.java:57)
at com.ibm.tx.jta.impl.RecoveryManager.recoveryFailed(RecoveryManager.java:1412)
at com.ibm.tx.jta.impl.RecoveryManager.run(RecoveryManager.java:1942)
at java.lang.Thread.run(Thread.java:773)
Caused by: com.ibm.ws.recoverylog.spi.InternalLogException: Failed to locate DataSource, com.ibm.ws.recoverylog.spi.InternalLogException: Failed to locate DataSource
at com.ibm.ws.recoverylog.custom.jdbc.impl.SQLMultiScopeRecoveryLog.openLog(SQLMultiScopeRecoveryLog.java:525)
at com.ibm.tx.jta.impl.RecoveryManager.run(RecoveryManager.java:1886)
… 1 more
Caused by: Failed to locate DataSource, com.ibm.ws.recoverylog.spi.InternalLogException: Failed to locate DataSource
at com.ibm.ws.recoverylog.custom.jdbc.impl.SQLNonTransactionalDataSource.getDataSource(SQLNonTransactionalDataSource.java:249)
at com.ibm.ws.recoverylog.custom.jdbc.impl.SQLMultiScopeRecoveryLog.getConnection(SQLMultiScopeRecoveryLog.java:760)
at com.ibm.ws.recoverylog.custom.jdbc.impl.SQLMultiScopeRecoveryLog.openLog(SQLMultiScopeRecoveryLog.java:393)
… 2 more
Resolving the problem
Increase the timeout value for the recovery log service operation by completing the following steps:
- Open the WebSphere Application Server administrative console.
- Click Servers > Server Types > WebSphere application servers > server_name.
- Under Server Infrastructure, click Java and Process Management > Process definition.
- Under Additional properties, click Java Virtual Machine > Custom properties > New.
- In the Name field, enter com.ibm.ws.recoverylog.custom.jdbc.impl.ConfigOfDataSourceTimeout.
- In the Value field, enter an integer timeout value in milliseconds; for example, to set the timeout to 10 seconds, enter 10000.
- Click OK, then click Save to save your changes to the master configuration.
The default value for the com.ibm.ws.recoverylog.custom.jdbc.impl.ConfigOfDataSourceTimeout property is two seconds.