Enfocus Community

Running 2018u1 on Windows Server 2012R2. I have a couple different flows that utilize the "HTTP request" configurator. Some of them hit external URLs, others hit internal URLs. But universally, randomly, the configurator has the red gear icon on it and is stalled out. One issue with this is that this doesn't appear to qualify as an actual "error" condition - so you can't even react based on the fact that it's happening. Secondly, of course it foils the workflow. You can manually right-click and "retry" but that's not a viable option at 3:00 a.m. when Switch is supposed to be just getting the job done.
None of these instances require authentication, and both internal (no firewall involved) and external URLs suffer from this malady occasionally.
In one instance it's doing a GET - downloading a JPEG from an outside URL. Another is doing a POST of many tiny XML files in succession (I've even added some delays in between the numerous requests to be sure I'm not overloading the service it's hitting - still seeing trouble.)
Thoughts?

Well, debug log and text on mouseover could help us to help...

Well, debug log and text on mouseover could help us to help...

One thing is certain: the HTTP Request is getting a 5xx error or it would not stall. If you have the opportunity to check the error handling on the server side, I advise you to look for 5xx errors being thrown and see if you can change them to 4xx errors as these will make the job fail, but not the element. That is in line with the guidelines for HTTP error codes (https://httpstatuses.com), but I know from experience that not all servers follow the rules correctly.

My first suspicion also goes to the rapid succession of many tiny XML's being posted as being the cause of the problem. How did you go about adding a delay?

You could also try to send GET commands with parameters instead of a lot of tiny XML-files. And on the server side take care of that GET and process it on the server with PHP or something else. I suspect you add information to a database.

Same problem at our side. Posted a message a few months back: viewtopic.php?p=10195#p10195 didn't find the solution. It is just downloading PDF files, and sometimes we get a error. Allso running on a windows server.

We had the same problem.
In our case I set "Switch Preferences > Error handling > Retry failed external processes after (minutes)" to 10 minutes. After that it has run flawlessly for a year. Try that if you don't already have the retry active.

Never have seen that option . At the moment it was "0" (disabled) I put it on 5 minutes. Keep you posted. Thanks!

Yes, it was disabled for us as well. That seems to be the standard setting.

If you enable "Retry failed external processes after ", then Switch will retry all failed processes in all active flows. This means that:

- If a job is crashing PitStop Server, then it will be retried, which is very likely going to result in another crash, and another one, ...
- If a job is crashing Photoshop, then it will be retried, which is very likely going to result in another crash, and another one, ...
- If a job is giving a unexpected error in a webservice (http 5xx status codes), then it will be retried. (This is what seems to happen for you)

5xx http status codes (the exact status code should be in the Switch messages) are usually bugs in the webservice (or some proxy/firewall/... between the webservice and Switch) and I would advise to have them investigated by the owner of the webservice if you haven't done so already.

It might also be a good idea to log a feature request to Enfocus to have the "Retry failed external processes after " setting in a flow element basis. This way you would be able to use this (in my opinion dangerous) setting only on the flow element that requires it. The more people that report it, the bigger the chance that it gets implemented.

Padawan wrote: ↑Wed Jun 10, 2020 10:25 am It might also be a good idea to log a feature request to Enfocus to have the "Retry failed external processes after " setting in a flow element basis. This way you would be able to use this (in my opinion dangerous) setting only on the flow element that requires it. The more people that report it, the bigger the chance that it gets implemented.

I fully agree with this. In my opinion also these preferences should be overrideable on a flow/element level:

• retry Mail/FTP/unreachable folder on flow and element levels
• problem alerts e-mail address(es) on flow level, so not only a setting if alerts are sent from problem jobs, but also who they are sent to and hopefully with custom subject, too.
• all of the problem alerts' "more than" options on flow and element levels

I have asked Enfocus these in the past, but haven't heard anything definite from them so a reminder from several users wouldn't hurt...

Well, I had the issue again today. After 5 minutes the retry started and the file was processed. So the setting fixed the problem for now. But the error I found in de messages:
Also, not a 500 message. Server where the file need to be download was up-and-running. No problems on that side. It is a "open" URL, so no credentials or login required.