HTTP Request Not Reliable
HTTP Request Not Reliable
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?
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?
Re: HTTP Request Not Reliable
Well, debug log and text on mouseover could help us to help...
--
Sebastian Nafroth +++ 3f8h.net / electronic publishing
3f8h.net offers professional services and products for the graphic arts
industry.
contact details: http://www.3f8h.net/kontakt
Sebastian Nafroth +++ 3f8h.net / electronic publishing
3f8h.net offers professional services and products for the graphic arts
industry.
contact details: http://www.3f8h.net/kontakt
Re: HTTP Request Not Reliable
Well, debug log and text on mouseover could help us to help...
Last edited by 3f8h.net on Tue Apr 28, 2020 2:14 pm, edited 1 time in total.
--
Sebastian Nafroth +++ 3f8h.net / electronic publishing
3f8h.net offers professional services and products for the graphic arts
industry.
contact details: http://www.3f8h.net/kontakt
Sebastian Nafroth +++ 3f8h.net / electronic publishing
3f8h.net offers professional services and products for the graphic arts
industry.
contact details: http://www.3f8h.net/kontakt
Re: HTTP Request Not Reliable
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?
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?
Re: HTTP Request Not Reliable
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.
Re: HTTP Request Not Reliable
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.
Working with: Enfocus Switch, Pitstop Server, Quite Imposing, Kodak Nexpress (max 640mm sheets and 500grs) with most options (HD, Clear, Gold, White, Light-Black and Matt fuser), Polar Mohr D80 (compucut), Multigraf, Heidelberg, GMP, Duplo, Hohner.
- billy.olvestad
- Member
- Posts: 54
- Joined: Mon Nov 19, 2018 10:08 pm
- Location: Sweden
- Contact:
Re: HTTP Request Not Reliable
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.
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.
Re: HTTP Request Not Reliable
Never have seen that option . At the moment it was "0" (disabled) I put it on 5 minutes. Keep you posted. Thanks!
Working with: Enfocus Switch, Pitstop Server, Quite Imposing, Kodak Nexpress (max 640mm sheets and 500grs) with most options (HD, Clear, Gold, White, Light-Black and Matt fuser), Polar Mohr D80 (compucut), Multigraf, Heidelberg, GMP, Duplo, Hohner.
- billy.olvestad
- Member
- Posts: 54
- Joined: Mon Nov 19, 2018 10:08 pm
- Location: Sweden
- Contact:
Re: HTTP Request Not Reliable
Yes, it was disabled for us as well. That seems to be the standard setting.
Re: HTTP Request Not Reliable
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.
- 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.
Re: HTTP Request Not Reliable
I fully agree with this. In my opinion also these preferences should be overrideable on a flow/element level: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.
- 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
Re: HTTP Request Not Reliable
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.
Code: Select all
The HTTP request tool failed to connect to the server or the connection was interrupted
TCP/IP error occurred: Server disconnected before handshake completion [0xffffffff].
HTTP GET request error: Internal network subsystem error: 276
Working with: Enfocus Switch, Pitstop Server, Quite Imposing, Kodak Nexpress (max 640mm sheets and 500grs) with most options (HD, Clear, Gold, White, Light-Black and Matt fuser), Polar Mohr D80 (compucut), Multigraf, Heidelberg, GMP, Duplo, Hohner.