Registered: 1158198299 Posts: 5,507
Reply with quote
Monitoring Engine Availability
Last edited: 08 Aug 2005
The information in this article applies to product:
e-Work 6.6.1 and later Question Can e-Work engine availability be monitored through a specific port? Discussion Communication with the engine is done through (D)COM only. A discussion of ports is somewhat misleading. The exact network transport by which DCOM communications are handled (TCP/IP, named pipes, etc.) is a function of the OS installation. However, it's possible to keep track of which engines are up through a database lookup. When an engine starts, it verifies that an entry specifying its engine name (as defined in the registry) is present in the eActiveEngine table. When it shuts down, this entry is removed (assuming the engine is able to shut down in an orderly fashion). In version 6.6.1 of the engine, further refinements were made to this mechanism. An additional datetime column called eAliveAsOf was added to the eActiveEngine table. A 6.6.1 engine periodically updates its eAliveAsOf entry to show it is still running. The frequency with which this is done is defined in a new column in the eServer table, eKeepAliveInterval. This value is in minutes, with a default of 2. This means that in a multi-engine environment, each engine makes sure it keeps its own eAliveAsOf entry up to date. If for some reason the engine ceases to function, this becomes obvious because its eAliveAsOf value becomes out of date. Indeed this is used by the 6.6.1 engine to determine whether other engines have ceased to function. When processing events, the 6.6.1 event manager will check to see whether other engines are no longer alive. "No longer alive" means that an engine's eAliveAsOf entry is out of date by more than 150% of the eKeepAliveInterval. Thus if the default is 2 minutes, and more than 3 minutes have elapsed since the last update, then the engine is considered "no longer alive". If such an engine is found, any events (timers, flags) marked for processing by this engine are unmarked, and the engine's eActiveEngine entry is removed. Note that this mechanism is passive. It is only activated when an engine is about to start processing timers / conditionals / flags. So it should be possible to see which engines are current, using a database lookup against eActiveEngine. Ideas for how to code this query can be found in the 6.6.1 stored procedure esp_check_for_inactive_engines.
Keywords: kb601 __________________ Post an example, and we will have a much better idea what the problem is. In about 90% of posts, the problem is one of communication. Examples bridge that gap.