Http and Node queued files and does not return them

Hi guys, we have 2 input processes, one http and another node.
that receive data and generate a pdf invoice, both run in multithreads, they work ok, but sometimes they don’t finish some tasks.
and in the planet tmp folders the files remain queued.
(C:\ProgramData\Objectif Lune\PlanetPress Workflow 8\PlanetPress Watch\ nodeJS\xxx)
(C:\ProgramData\Objectif Lune\PlanetPress Workflow 8\PlanetPress Watch\http\xxx)

in the log it shows that it is waiting for the response file, and then it dies by timeout, but the file exists, everything seems to not be able to capture it due to some permissions or antivirus problem.
Is there a way I can demonstrate this to the IT people, and have them help me unlock this?

Another thing, when I want to delete the files that were queued, there are times when I can’t, and it asks me for admin permissions, but if I stop the workflow service I can delete them.

Log:
REQST: HTTP Request - 9:28:49 AM
INFO : Connection from 192.168.109.152
INFO : Port used: 9090
INFO : URL: /generaRecibo3
DEBUG: Received action: generaRecibo3
DEBUG: Starting to download file
DEBUG: Temporary folder was created successfully
DEBUG: HTTP request content type is:
DEBUG: 0 attachments were downloaded
DEBUG: Writing request file
INFO : Sending event for Global_ol_process_trigger_http_010dwc1uk124zc2
DEBUG: Request file was successfully written
DEBUG: Waiting on response file
ERROR: Timeout
REQST: End time: 9:29:09 AM

By looking at your logs, seems that your time out is set to 20 seconds (9:28:49 - 9:29-09). You might want to increase that in the Preferences of Workflow.

hi @hamelj
he task lasts a few seconds, 2 or 3, initially the timeot was set to 10 seconds, and I raised it to 20 seconds and we have the same problem.
If I leave a very long timeout, with this problem many requests remain open and planet collapses.

How often is that happening? daily, hourly?

One test to do is to ask IT to turn off the AV for a period of time that you know it happens while.
You could also make sure that all folders rrelated to your processes as well as all Workflow and Connect Server folders are whitelisted in the AV.

They assure me that the AV has all the exclusions, and you can never get them to turn off the AV :frowning:
On the other hand, is there something in the Windows permissions that is blocking access to these files? The planetpress user is a local administrator of the server, but when I want to delete the files manually it doesn’t let me and asks for admin permissions, and if I stop the workflow I can delete the files.
All this while I was logged in as the planetpress user.

You could turn on the sequential logger. This will log everything as soon as it is happening as oppose to once the process is done (normal log).

To turn this on:

  • Click on the Workflow button in your configurator (big orange W).
  • Then Preferences->Plug-in-.General .
  • Then hit simultaneously SHIFT-CTRL-ALT-F12 key. A checkbox will appear labeled Log each process events synchronously in a separate log file or something quite similar, depending of your Workflow version.
  • Resend your configuration.

That will start logging each processes in its own log file (labeled as the process name) and at every step.

In your specific case, I’d say to turn on this option and turn it off after the issue has occurred.

BE WARNED…THIS OPTION MUST BE TURNED OFF AT SOME POINT . It will tax your resources and the logs files can become quite big. The created logs aren’t day stamped, only time BUT you will be able to see in them everything as they occurs.

To turned it off, simply go back to your Preferences and uncheck the box and resend your config.

These new log can be found in the same folder as the normal ones (which are still generated).
C:\ProgramData\Objectif Lune\PlanetPress Workflow 8\PlanetPress Watch

That should help you troubleshoot your behaviour. If it doesn’t shed some light on the source cause of the problem, you also can open a technical support ticket through our website.

Ok, I’ll do it, and I’ll share the detailed log, to determine the error.
If this is not enough, I will open a support ticket.

thank you so much!

The logs will be big and most likely you will not find an “error” per say but you will be able to track down the last Workflow step that was executed before the whole thing hanged. This way it will pinpoint what step is most likely the culprit.