Skip to main content
Solved

How to extend Gateway timeout after 600s (10 min) - HTTP Error 504

  • September 27, 2024
  • 4 replies
  • 437 views

InfFilipV
Hero (Partner)
Forum|alt.badge.img+14

Hi,

Our customer is experiencing issues with long-running online jobs, which fail after 10 minutes due to a timeout. The Network tab in DevTools shows a 504 Gateway Timeout error.

Where can we configure or extend this timeout?


 

 

Best answer by hhanse


Hi,
It’s in the techdoc:

https://docs.ifs.com/techdocs/24r1/070_remote_deploy/010_installing_fresh_system/200_installing_ifs_cloud/035_ifs_cloud_ifsinstaller/030_installation_parameters/#general_parameters

 

nginx.ingress.kubernetes.io/proxy-send-timeout: "{{ .Values.global.httpSendTimeout | default 600 }}"

nginx.ingress.kubernetes.io/proxy-read-timeout: "{{ .Values.global.httpReadTimeout | default 600 }}"

 

4 replies

Forum|alt.badge.img+11
  • Hero (Employee)
  • Answer
  • September 30, 2024


Hi,
It’s in the techdoc:

https://docs.ifs.com/techdocs/24r1/070_remote_deploy/010_installing_fresh_system/200_installing_ifs_cloud/035_ifs_cloud_ifsinstaller/030_installation_parameters/#general_parameters

 

nginx.ingress.kubernetes.io/proxy-send-timeout: "{{ .Values.global.httpSendTimeout | default 600 }}"

nginx.ingress.kubernetes.io/proxy-read-timeout: "{{ .Values.global.httpReadTimeout | default 600 }}"

 


Dharmendra
Hero (Employee)
  • Hero (Employee)
  • October 1, 2024

Forum|alt.badge.img+6
  • Do Gooder (Partner)
  • November 24, 2025

Hi,

 

How to increase global.httpSendTimeout and global.httpReadTimeout values?

What are the risks if we increase the timing for the global parameter?

 

 


Forum|alt.badge.img+8
  • Sidekick (Employee)
  • August 14, 2026

Hi,

 

How to increase global.httpSendTimeout and global.httpReadTimeout values?

What are the risks if we increase the timing for the global parameter?

 

 

Hi

I was running into the same errors (i.e. 504  Gateway timeout ) when trying to remove a cost set from costing basic data. 

I only saw this error when running DevTools. 
In the Apps10 IEE client, I instantly got an error message about a record being locked. (actual error was The update could not be performed since the Cost Set record is currently locked. Please retry the operation)

And if the operation took more than 30 minutes in IEE, I got an error “Request aborted”. In IFS Cloud, the screen just kept spinning and 10 minutes later, it came back without any error. (unless you turned DevTools on or obtained the client logs, you could not see the above error).

In my case, extending the above 2 timeout parameters was not the real answer. I think the default is 10 minutes, we could extend it a little more, but I do not know what the risks are. Again, if I had to extend it to 30 minutes and the cost set removal took over 30 minutes, my main concerns or question were:

“In the first place, why is the cost set removal taking over 10 minutes?”

“Is it supposed to finish in under 10 minutes in IFS Cloud? What is the customer's data volume/dependencies like?”

“If the cost set removal is a resource intensive process, why is there no background job option to remove this cost set via a background job and let it take whatever time it is supposed to take?” 
This is something that will be logged to R&D.