Distributed Rendering - Date, time & Regional settings are preventing DRP's to start up.

After a couple of PC's got upgraded to the Windows 10 April (1803) update, the DRP's wouldn't start anymore on some systems.

After spending quite some time investigating this issue I expected this to be caused by the upgrade and/or User access rights.
However, as it turned out the issue was caused by the Date, time & Regional settings on the upgraded systems.

Here's a snipped of the DistributedProcessing.log
2018-05-30 15:30:49,116 [JobThread] ERROR DistributedProcessing.Controller [(null)] - Processor license is not configured.
2018-05-30 15:31:09,709 [JobMessagePollingThread] ERROR DistributedProcessing.Core [(null)]
 - Failed to process messages: System.FormatException: String was not recognized as a valid DateTime.
   at System.DateTimeParse.Parse(String s, DateTimeFormatInfo dtfi, DateTimeStyles styles)
   at Bentley.DistributedProcessing.JobMessage.ReadMessage(String filePath, String machineId)
   at Bentley.DistributedProcessing.JobListener.HandleJobMessage(String filePath)
   at Bentley.DistributedProcessing.JobListener.MessageThreadRun()
......
This message is repeated many times...
After making the Date, time & Regional settings on all systems the same the problem seems to be resolved.
All systems participate in the DR rendering process.
However, although all works as expected, there's still a reported error in the DistributedProcessing.log files;
2018-05-30 18:28:51,834 [JobThread] ERROR DistributedProcessing.Controller [(null)] - Processor license is not configured.
All systems are using V8i SS3 (08.11.09.459)
My Questions:
1 What is the expected Date/time format ?
2 What does the ERROR msg "Processor license is not configured" actually mean ?
Looks like it can be simply ignored as all it working as expected.
Pierre
Parents Reply
  • I am using ss4 this days,  previously ss3.personally I found that all machines should be as close as possible for being identical. Regional settings, file names etc. 

    For example i found the file created in German version of mstn cannot be rendered in Russian mstn, simply because difference in OS internal date format and file names. 

    We have agreed internally,  that we use international (UK) setting for all mstn across our offices for files and regional settings. This is a small compromise for my colleagues,  but the simple solution for get things done. 

    Nikolay Vyglazov

Children
No Data