Interviewer - Server > Architecture > Web Service tier > Session engine registration
 
Session engine registration
The Web Service uses a registration system to keep track of which interviewer session engines are available to run interviews at a given time. By default, one interviewer session engine runs on each Interviewing server but you may set up multiple engines per server if you want to take advantage of options to use more than 2Gb memory per process.
The registration procedure is as follows:
1 When an interviewer session engine starts, it uses the ISessionEngines interface to send a registration request to the Web Service. If you have more than one Web server, the same request is sent to each Web server.
2 The Web Service calls the session engine to verify that two-way communication is possible. If the call reaches the session engine, registration succeeds and the engine becomes available for interviews.
3 If the call fails, the engine is classed as Failed and must wait for the Web Service to recontact it (the waiting time is defined in the Web Service's Web.config file; see EngineRetryTimeout Web service configuration for details).
Note Engines are not retried if there is no activity on the cluster.
4 If the failed engine is still unavailable after a specified number of retries (also defined in the Web Service's Web.config file; see EngineMaxRetries) the engine is removed from the list of failed engines and will not be recontacted.
When an interviewer session engine is shut down, it unregisters itself.
The Web tier logs all registration attempts in the ISE log files. Successful attempts are logged at Info log level and failed attempts are logged at the Error log level.
RegisteredEngines.xml file
The registration service records the current status of each interviewer session engine in Server\mrIWebRegisteredEngines.xml in the UNICOM Intelligence Interviewer installation folder (normally [INSTALL_FOLDER]\IBM\SPSS\DataCollection\<version>\Interviewer Server\) on each computer running the Web Service. If you have multiple Web tiers running on a computer, the file is created on each instance of the Web tier on that computer, and it records the engines that have been registered with that Web tier.
Apart from making it easy for you to check engine status, this file is also used when you stop and restart the Web Service on a computer. The Web Service starts and then reads this file to find out which engines are currently available for interviewing; there is no need to reregister the engines with the newly started server. The following example shows a situation where two engines have registered and are available for interviewing, and another engine failed to register but has a time when it the registration service will attempt to reregister it:
<mrIWeb>
<Registered>
<Engine URL="http://red/mriengws" Name="engine1"/>
<Engine URL="http://red/mriengws2" Name="engine2"/>
</Registered>
<Failed>
<Engine URL="http://green/mriengws" Name="engine3"
RetryTime="1/28/2005 3:38:08 PM" RetryCount="0"/>
</Failed>
<Unregistered/>
</mrIWeb>
Using the registration service to register interviewer session engines is the normal and recommended way of working. Its use is controlled by the value of the WebTierRegistration registry setting. If you do not want engines to register in this way you can switch off automatic registration and name the engines that are to be registered in the Web Service's Web.config file (see Web service configuration). However, that all engines referenced in this file will then be automatically reregistered when the Web Service starts, even if they have been moved to the failed engines list.
See also
Web Service tier