On this page:
Server activation failure is usually indicated by the receipt of a NoEndpointException
. This can happen for a number of reasons, but the most likely cause is an incorrect configuration. For example, an IceGrid node may fail to activate a server because the server's executable file, shared libraries, or classes could not be found. There are several steps you can take in this case:
IceGrid.Node.Trace.Activator=3
.PATH
or LD_LIBRARY_PATH
settings for its shared libraries. For a Java server, its CLASSPATH
may also require changes.Another cause of activation failure is a server fault during startup. After you have confirmed that the node successfully spawns the server process using the steps above, you should then check for signs of a server fault (e.g., on Unix, look for a core
file in the node's current working directory).
A client may receive Ice::NotRegisteredException
if binding fails for an indirect proxy. This exception indicates that the proxy's object identity or object adapter is not known by the IceGrid registry. The following steps may help you discover the cause of the exception:
icegridadmin
to verify that the object identity or object adapter identifier is actually registered, and that it matches what is used by the proxy:
{zcode} >>> adapter list ... >>> object find ::Hello ... {zcode} |
Ice.Trace.Locator=2
, then run the client again to see if any log messages are emitted that may indicate the problem.
Diagnosing a server failure can be difficult, especially when servers are activated automatically on remote hosts. Here are a few suggestions:
core
file.Ice.Trace.Protocol=1
to discover the object identity and operation name of all requests.
Ice::Logger
interface to emit your own trace messages.icegridadmin
:
{zcode} >>> server start TheServer {zcode} |
server stop
command.Another cause for a server to fail to activate correctly is if there is a mismatch in the adapter identifiers used by the server for its adapters, and the adapter identifiers specified in the server's deployment descriptor. After starting a server process, the node waits for the server to activate all of its object adapters and report them as ready; if the server does not do this, the node reports a failure once a timeout expires. The timeout is controlled by the setting of the property IceGrid.Node.WaitTime
. (The default value is 60 seconds.)
You can check the status of each of a server's adapters using icegridadmin
or the GUI tool. While the node waits for an adapter to be activated by the server, it reports the status of the adapter as "activating". If you experience timeouts before each adapter's status changes to "active", the most likely cause is that the deployment descriptor for the server either mentions more object adapters than are actually created by the server, or that the server uses an identifier for one or more adapters that does not match the corresponding identifier in the deployment descriptor.
You may find it necessary to disable a server that terminates in an error condition. For example, on a Unix platform each server failure might result in the creation of a new (and potentially quite large) core file. This problem is exacerbated when the server is used frequently, in which case repeated cycles of activation and failure can consume a great deal of disk space and threaten the viability of the application as a whole.
As a defensive measure, you can configure an IceGrid node to disable these servers automatically using the IceGrid.Node.DisableOnFailure
property. In the disabled state, a server cannot be activated on demand. The default value of the property is zero, meaning the node does not disable a server that terminates improperly. A positive value causes the node to temporarily disable a faulty server, with the value representing the number of seconds the server should remain disabled. If the property has a negative value, the server is disabled indefinitely, or until the server is explicitly enabled or started via an administrative action.