Qlik Talend Data Stewardship R2025-02 keeps on loading status On AWS EC2 instance

wei_guo — Wed, 28 Jan 2026 06:28:57 GMT

Qlik Talend Data Stewardship R2025-02 keeps on loading and does not open up in Talend Management Console.

Resolution

Patch fix

Apply the latest Patch_20260105_TPS-6013_v2-8.0.1-.zip or latter version of patch

TCP stack tunning

##sysctl
sudo vi /etc/sysctl.conf
#add the following lines
net.ipv4.tcp_keepalive_time=200
net.ipv4.tcp_keepalive_intvl=75
net.ipv4.tcp_keepalive_probes=5
net.ipv4.tcp_retries2=5

sudo sysctl -p #activate

MTU change (avoid TCP traffic re-transmission)

temp change without rebooting :

sudo ip link set dev eth0 mtu 1280

Persist on os:

sudo vi /etc/sysconfig/network-scripts/ifcfg-eth0
MTU=1280

network_mtu.html | docs.aws.amazon.com

Explanation on the Linux tcp tunning parameters

These sysctl settings are primarily used to make your server more aggressive at detecting and closing "dead" or "hung" network connections. By default, Linux settings are very conservative, which can lead to resources being tied up by connections that are no longer active.

Here is a breakdown of what these specific changes do and why they are beneficial.

TCP Keepalive Settings

The first three parameters control how the system checks if a connection is still alive when no data is being sent (the "idle" state).

net.ipv4.tcp_keepalive_time=200	This triggers the first "keepalive" probe after 200 seconds of inactivity. The Linux default is 7,200 seconds (2 hours).
net.ipv4.tcp_keepalive_intvl=75	Once probing starts, this sends subsequent probes every 75 seconds. The default is 75 seconds.
net.ipv4.tcp_keepalive_probes=5	This determines how many probes to send before giving up and closing the connection. The default is 9.

The Benefit: In a standard Linux setup, it can take over 2 hours to realize a peer has crashed. With your settings, a dead connection will be detected and cleared in roughly 20 minutes (200 + (75* 5) = 575 seconds). This prevents "ghost" connections from filling up your connection tables and wasting memory.

TCP Retries

net.ipv4.tcp_retries2=5

This controls how many times the system retransmits a data packet that hasn't been acknowledged before killing the connection.

The Benefit: The default value is usually 15, which can lead to a connection hanging for 13 to 30 minutes during a network partition or server failure because the "backoff" timer doubles with each retry. By dropping this to 5, the connection will "fail fast" (usually within a few minutes).

This is excellent for high-availability systems where you want the application to realize there is a network issue quickly so it can failover to a backup or return an error to the user immediately rather than leaving them in a loading state.

Summary Table	Default	Your Values
Parameter	Default (Approx)	Your Value (Impact)
Detection Start	~2 Hours	~3.3 Minutes ( Much faster initial check)
Total Cleanup Time	~2.2 Hours	~20 Minutes (Frees up resources significantly faster)
Data Timeout	~15+ Minutes	~2-3 Minutes(Stops "hanging" on broken paths)

Use Cases for These Settings

Microservices: To ensure fast failover and prevent a "cascade" of waiting services in a distributed system.

If These changes are not permanent until you add them to /etc/sysctl.conf. Running the command with -w only applies them until the next reboot.

Cause

There are 2 major factors contributing to this issue

invalid_grant error caused by current design defects
ERROR [http-nio-19999-exec-2] g.c.s.Oauth2RestClientRequestInterceptor : #1# Message: '[invalid_grant] ', CauseMessage: '[invalid_grant] ', LocalizedMessage: '[invalid_grant] '
EC2 Linux sysctl tcp stack default setting not ideal for clean the hang connections.

article Qlik Talend Data Stewardship R2025-02 keeps on loading status On AWS EC2 instance in Official Support Articles