Topic Options
#56222 - 08/10/18 05:18 AM Single process randomly stopping
douglasb Offline
OL Toddler

Registered: 08/24/04
Posts: 42
Loc: Cheshire, UK
A customer has experienced this twice in the last couple of days. Their configuration has about 25 processes, most of which use hotfolder input. Data files are either XML or ASCII. Processes pick up the data files and either send an email or produce a print file.

Two days ago the delivery note process apparently stopped. It should pick up data files from (eg) \\server1\inputfiles\deliverynotes. They could see files backing up in this folder and not being picked up. All other processes picking files up from \\server1\inputfiles\document_type_x were still running.

Yesterday something similar happened and a process which picks up files from \\server2\inputfiles\orderacks stopped working. Once again they could see the files backing up and once again other processes picking up from \\server2\inputfiles\document_type_x were still running.

Thee doesn't seem to be anything in common here as it was different processes affected each day. The processes pick up data files from different servers and other processes that pick up files from the same server were still running at the time.

Is there a quick way to tell if a single process has stopped and to restart it if it has stopped? Any ideas why something like this would happen?

#56223 - 08/10/18 09:19 AM Re: Single process randomly stopping [Re: douglasb]
Raphael Lalonde Lefebvre Offline
OL Expert

Registered: 10/14/05
Posts: 4953
Loc: Objectif Lune Montreal
Hi douglasb,

There is no way to simply stop one process. If the services are running, then all processes are also running. If the services are stopped, all processes will be stopped.

However, there are things that could prevent a specific process from capturing data, while other processes are working fine. The two most common problems would be one of these:

- There could be a data file "stuck" in one of the process. For example, something in the data caused the PlanetPress template to enter an infinite loop and to never finish. The process normally waits till a data file has been processed before capturing another one, but if it's stuck, it never finishes processing, and so it will never capture the next files. This would not affect the other processes, and they would continue to work normally, while this one remains stuck.

Solution: You might have to kill the services from the PlanetPress Service Console, or from Windows Task Manager, and then delete the spool files in C:\ProgramData\Objectif Lune\PlanetPress Suite 7\PlanetPress Watch\Spool in order to "free" the process, since the services won't stop or restart until all processes are finished processing, but this one will never finish. Deleting the Spool files is necessary, otherwise, the process will resume once you restart the services, and could get stuck again. After it's done, you might want to check which data file caused the issue, and maybe try to isolate it, and then run it in debug mode, to see if you can reproduce the issue.

- There could be issues in accessing the input folder of one specific process. For example, a network folder could suddently become inaccessible due to network issues, or maybe the user associated with the PlanetPress services don't have permission to access this folder. It's a fairly common issue that a network drive cannot be accessed by PlanetPress due to permission issues with the user associated with the services.

Solution: Make sure the input folder is accessible and didn't become inaccesible due to network issues. Also make sure that the user associated with the PlanetPress services have proper permissions to access the folder.

In any cases, I suggest that you check the PlanetPress Workflow log files, located in If this is the problem, you might see errors in the PlanetPress Workflow log files, located in C:\ProgramData\Objectif Lune\PlanetPress Suite 7\PlanetPress Watch\Log, to see if there was any errors. An infinite loop wouldn't throw error messages, but inaccessible drives would. It could also point to another problem, depending on what you find.

Raphaƫl Lalonde-Lefebvre