Products | Support | Send comments on this topic. | Email a link to this topic. | Back to Introduction | Help Version 18.0.1.22
LEADTOOLS Cloud Settings
Show in webframe
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.
Server Settings
Workers.xml
The LEADTOOLS Cloud Framework allows most worker settings to be configured in Workers.XML. This file is required by the WorkerService WCF Service and must exist in the App_Data directory of the WorkerService WCF Service on the server. This configuration file allows you to control which workers will be accepting jobs, what type of jobs each worker will process, the maximum number of concurrent jobs each worker will accept, CPU thresholds, and other machine related settings. The schema of this configuration file, along with the usage of each setting can be found below.<Workers> <Worker Name="*" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="XYZ" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> <Worker Name="Worker1" NewJobCheckPeriod="2"> <JobTypes> <JobType Name="Ocr" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> <JobType Name="Multimedia" MaxNumberOfJobs="5" CpuThreshold="80" UseCpuThreshold="false" ProgressRate="10" AssumeHangAfter="60" Attempts="3"/> </JobTypes> </Worker> </Workers>
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Worker: Node representing a worker machine.
Name (Worker Node): Attribute representing the name of the worker. "*" can be used here to specify settings which should be used for machines whose names are not located in the configuration.
NewJobCheckPeriod: Attribute representing the frequency in seconds the worker should poll the central server for new jobs of this type.
JobTypes: Node representing which types of jobs this machine will process.
JobType: Node representing the settings for a specific type of job for a worker.
Name (JobType Node): Attribute representing the name of this job type.
MaxNumberOfJobs: Attribute representing the maximum number of concurrent jobs this machine should take for this job type.
CpuThreshold: Attribute representing the maximum CPU percentage threshold this machine should use to limit acceptance of new jobs of this type. For example, if the CpuThreshold is set to 80, new jobs of this type will not be accepted unless the current CPU usage drops below 80.
UseCpuThreshold: Attribute representing whether the worker should use the value specified by CpuThreshold. If this value is true, the value set by CpuThreshold will be used to control when new jobs are accepted. If this value is false the value set by MaxNumberOfJobs will be used to control when jobs are accepted.
ProgressRate: Attribute representing the rate in seconds at which the worker process should post progress via the UpdatePercentage Method.
AssumeHangAfter: Attribute representing the maximum amount of time in seconds a job process can go without a change in progress before it is assumed hung and therefore killed. This value should be larger than the ProgressRate to prevent jobs from being mistakenly considered hung and killed. In cases where large periods of time can go by without a change in progress, you will want this value to be larger. For example, if your process could go 5 minutes without a change in progress, this value should be greater than 300 (5 x 60 seconds per minute).
Attempts: Attribute representing the maximum number of times to attempt jobs of this type if they do not complete successfully.
Web.config
The WCF Service web.config should contain the below settings.
Connection String: The connecting string to the Cloud database. The name of the connection string should be "LeadtoolsCloudDB". See below for an example.
<connectionStrings> <add name="LeadtoolsCloudDB" connectionString="data source =localhost\SQLEXPRESS;initial catalog =LeadtoolsCloudDB;Trusted_Connection=true;" providerName="System.Data.SqlClient" /> </connectionStrings>
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
License Information: The LEADTOOLS Cloud SDK must be unlocked before the user can actually use the Cloud properties, methods, and events. For more information on unlocking LEAD features, refer to Unlocking Special LEAD Features. To add your license information and unlock the Cloud SDK, specify the 'DeveloperKey' and 'LicenseFile' in the appSettings section. The 'LicenseFile' must be located in the WCF Service App_Data directory. See below for an example.
<appSettings> <add key="DeveloperKey" value="" /> <add key="LicenseFile" value="" /> </appSettings>
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Logging Information:Logging for the WCF service can be configured in the WCF Service web.config file (see below for example). Various WCF Service information will be logged including database interaction, calls made to the service, and other service related events. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
WCF Service Settings: Both the JobService and the WorkerService are hosted by the central server. Both services are required by the LEADTOOLS Cloud SDK, and must be defined in the '<services>' section of your web.config. The below table list each service, and an example which can also be found in the web.config of the WCF service installed with the Cloud SDK. For more information on hosting WCF services and using configurations files to store WCF settings, refer to Hosting WCF Services and Configuring Services Using Configuration Files.
| WCF Service | Name | Service Contract |
|---|---|---|
| JobService | Leadtools.Services.Cloud.ServiceImplementations.JobService | Leadtools.Services.Cloud.ServiceContracts.IJobService |
| WorkerService | Leadtools.Services.Cloud.ServiceImplementations.WorkerService | Leadtools.Services.Cloud.ServiceContracts.IWorkerService |
<services> <!-- JobService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.JobService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IJobService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service> <!-- WorkerService --> <service name="Leadtools.Services.Cloud.ServiceImplementations.WorkerService" behaviorConfiguration="LeadtoolsServiceBehavior"> <endpoint contract="Leadtools.Services.Cloud.ServiceContracts.IWorkerService" binding="basicHttpBinding" bindingConfiguration="HttpTextStreaming" bindingNamespace="http://Leadtools.Cloud.ServiceContracts/2009/01"/> <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" /> </service>
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Windows Service Worker Settings
App.config
Logging for the windows service and user worker assembly can be configured in the application app.config file (see below for example). Various windows service information will be logged including database interaction, WorkerService WCF service interaction, current job information, and other events related to the worker. Logging is implemented using the LEADTOOLS Logging Framework. For more information on the Leadtools.Logging logging framework, refer to Programming with LEADTOOLS Logging.
<configSections> <section name="leadLogging" type="Leadtools.Logging.Configuration.ConfigSectionHandler, Leadtools.Logging"/> </configSections> <logging> <channels> <channel name="EventLog" type="Leadtools.Logging.LoggingChannel.EventLogLoggingChannel, Leadtools.Logging" Enabled="false" Souce="Leadtools.Cloud"/> </channels> </logging>
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Each Windows Service can be setup to process any number of job types, and there are no limitations to the number of Windows Services from the LEADTOOLS Cloud Framework which can be installed on a single machine. For more information on using multiple job types, refer to Understanding the LEADTOOLS Cloud Database.
The Windows Service application configuration file (app.config) allows you to specify what type of job this service will process. It also contains the endpoint information for the WorkerService WCF Service. The below settings can be found in the 'appSettings' section of the app.config file.
UserClassTypeName: The namespace and class (Specified as 'Namespace.Class') of the class which will override the OnJobReceived Method and process new jobs.
JobType: The type of jobs this service will process. If a job type is specified here, a matching job type should be defined in Workers.xml under the same machine, or the default machine settings (*) if the machine is not defined. If no job type is specified here, the worker will process all job types defined for that worker in Workers.xml, as well as jobs which were added with no job type specified. This case would be useful if you have a single worker assembly which can process multiple job types.
WorkerLayerPath: The path to Leadtools.Cloud.Workerlayer.exe.
UserDllPath: Path to your custom worker assembly. This assembly will be loaded by Leadtools.Cloud.Workerlayer.exe to process jobs.
The Windows Service will use the settings specified in the application configuration file to connect to the WorkerService WCF Service (contract="IWorkerService"). For more information on how to specify WCF binding, behavior, and endpoint information in the application configuration file, refer to Configuring Services Using Configuration Files.
Products | Support | Contact Us | Copyright Notices