Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

 

Anchor
_Toc154574490
_Toc154574490
Anchor
_Toc95297323
_Toc95297323
Root configuration files

Root configuration files define the behaviour of DELFT-FEWS on the local machine. These files are synchronised in the live system environment, nor are they available in the database. The files must be installed locally with the DELFT-FEWS system.

Warning

The clientType of a system may be changed from OperatorClient to StandAloneStand alone.
Under no conditions should a system that was once StandAlone be changed to an Operator Client system. This may only be done if the local data store is first deleted.

...

Elements of the clientConfig configuration

clientType

Definition of the client type. Enumeration of options includes;

...

The following example demonstrates how event logging is enabled for an OC or FSS by addition of a logging section to the clientConfig.xml.

Code Block
xml
xml

<?xml version="1.0" encoding="UTF-8"?>
<clientConfiguration xmlns="http://www.wldelft.nl/fews" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.wldelft.nl/fews http://fews.wldelft.nl/schemas/version1.0/clientConfig.xsd">
<clientType>Operator Client</clientType>
    <logging>
        <windowsEventLogEnabled>true</windowsEventLogEnabled>
        <linuxSyslogFacility>local6</linuxSyslogFacility>
    </logging>
</clientConfiguration>

...

If for instance a custom adapter is required to log to this facility, the adapter should log using log4j with a Syslog prefix in the message, e.g.

Code Block

log.info("Syslog.Adapter: imported file" + filename);

Per default the Operator Client logs key events for logins to this facility.

Code Block

Delft-FEWS Operator Client: userName=User mcId=MC INFO - RemoteSession.login - Login.Started: Login to Master Controller
Delft-FEWS Operator Client: userName=User mcId=MC INFO - RemoteSession.login - Login.Finished: Successfully logged in to Master Controller: USBPMC00. Session ID USBPMC00:000017435
Delft-FEWS Operator Client: userName=User mcId=MC INFO - RemoteSession.logout - Logout.Finished: Successfully logged out from Master Controller: USBPMC00
Delft-FEWS Operator Client: userName=User mcId=MC INFO - RemoteSession.logout - Login.Failed: Cannot Log to Master Controller: USBPMC00

Sample linux configuration (Redhat based system) (nippet of modifications to /etc/rsyslog.conf) that sends errors and logins to /var/logs/fews.log.

Code Block

# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

local6.*                                                /var/log/fews.log

Anchor
_Toc154574492
_Toc154574492
Anchor
_Toc95297325
_Toc95297325
LogConfig

To be completed

Anchor
_Toc154574493
_Toc154574493
Anchor
_Toc95297326
_Toc95297326
synchConfig

Looks something like this for an OC:

Code Block
xml
xml

<?xml version="1.0" encoding="UTF-8"?>
<fews-master-config xmlns="http://www.wldelft.nl/fews" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.wldelft.nl/fews http://fews.wldelft.nl/schemas/version1.0/synchronisationConfiguration.xsd">
	<queueconnection>
		<factory jndi="ConnectionFactory"/>
	</queueconnection>
	<defaultMcId>MC00</defaultMcId>
  <mc id="MC00">
		<jndicontext factory="org.jnp.interfaces.NamingContextFactory" provider="jnp://localhost:1099" prefixes="org.jboss.naming:org.jboss.interfaces"/>
		<queue>
			<root jndi="TEST/MC00/"/>
			<synch jndi="External/JMSQueue/OCIncoming" timeout="10"/>
		</queue>
   </mc>
	<synchronisation>
		<messaging maxrecords="1000" maxlobdata="30000000"/>
		<processor maxlistsize="500000"/>
		<schema location="nl/wldelft/fews/master/data/synchdata/synchronisation_schema.xsd"/>
	</synchronisation>
      <login timeout="10" />
</fews-master-config>

...

The only setting that may demand editting is the <login timeout="10" />, which controls the timeout for a login attempt of the OC on the MC (in seconds). (This element may be absent, in which case the timeout is 10secs)
It may be needed to extend this timeout if the JMS server is very busy (very many clients starting up and synchronising at the same time, e.g. when all the PCs for a workshop are all starting up at the same time).
Note: the xml config can only extend the time out from the default 10 secs. Settings less than 10 secs are ignored)

 

Anchor
_Toc154574494
_Toc154574494
Anchor
_Toc95297327
_Toc95297327
synchProfiles

...

From version 2010.01 onwards, it is possible to get an overview of the active users. This overview is available in both the Operator Client and the Admin Interface. In order to make this functionality work, the file synchProfiles.xml has to be configured properly in each of the Operator Clients. Before version 2010.01, the file synchProfiles.xml would typically contain several profiles containing the following snippet:

Code Block
xml
xml

			<activity id="Activity.In.FewsSessions">
				<channelId>Channel.In.FewsSessions</channelId>
					<schedule>
						<single/>
					</schedule>
				<timeOut>10000</timeOut>
			</activity>

From version 2010.01 onwards, it is recommended to replace this snippet for the profiles 'Full', 'Minimal' and 'Custom' (not for ConfigManager) by the following:

Code Block
xml
xml

			<activity id="Activity.In.FewsSessions">
				<channelId>Channel.In.FewsSessions</channelId>
				<schedule>
					<continuous>
						<period unit="minute" multiplier="3" divider="1"/>
						<priority>low</priority>
					</continuous>
				</schedule>
				<timeOut>10000</timeOut>
			 </activity>

...

See also User Administration - Active Users

Anchor
_Toc154574495
_Toc154574495
Anchor
_Toc95297328
_Toc95297328
synchChannels

To be completed

Working with pool of localDataStores (under Citrix)

...