ISAM 9.0.7

We find that WebSocket connections get a timeout somewhere between 500ms - 1000ms, and would like help finding out which config is causing the timeout. We have a solution that runs behind WebSEAL and this solution requires a connection to be open for at least 5 seconds.

We have the following values ​​in config for affected Reverse Proxy instance:

[WebSocket]

max-worker-threads = 500

idle-worker-threads = 50

# jct-read-inactive-timeout = 120

clt-read-inactive-timeout = 120

jct-write-blocked-timeout = 20

clt-write-blocked-timeout = 20

For the [server] stanza, we first had default values:

client-connect-timeout = 120

persistent-con-timeout = 5

intra-connection-timeout = 60

With these default values, WebSocket connection works as long as the server sends 'KeepAlive' messages to all clients every 500ms. If we send messages every 1000ms then we get timeout eventually, and with messages every 2000ms we get timeout immediately. The conclusion is that there is a kind of socket / timeout setting in WebSeal that strikes around 1000ms, but which we have not so far managed to identify.

We have also tried this setting:

persistent-con-timeout = 0

- and then WebSocket connection fails as expected, but then we at least know that the setting is 'picked up'. We have also tried overriding persistent-con-timeout under [junction:/<junction-name>] stanza, without any effect..

ISAM 9.0.7

We find that WebSocket connections get a timeout somewhere between 500ms - 1000ms, and would like help finding out which config is causing the timeout. We have a solution that runs behind WebSEAL and this solution requires a connection to be open for at least 5 seconds.

We have the following values ​​in config for affected Reverse Proxy instance:

[WebSocket]

max-worker-threads = 500

idle-worker-threads = 50

# jct-read-inactive-timeout = 120

clt-read-inactive-timeout = 120

jct-write-blocked-timeout = 20

clt-write-blocked-timeout = 20

For the [server] stanza, we first had default values:

client-connect-timeout = 120

persistent-con-timeout = 5

intra-connection-timeout = 60

With these default values, WebSocket connection works as long as the server sends 'KeepAlive' messages to all clients every 500ms. If we send messages every 1000ms then we get timeout eventually, and with messages every 2000ms we get timeout immediately. The conclusion is that there is a kind of socket / timeout setting in WebSeal that strikes around 1000ms, but which we have not so far managed to identify.

We have also tried this setting:

persistent-con-timeout = 0

- and then WebSocket connection fails as expected, but then we at least know that the setting is 'picked up'. We have also tried overriding persistent-con-timeout under [junction:/<junction-name>] stanza, without any effect..

ISAM 9.0.7

We find that WebSocket connections get a timeout somewhere between 500ms - 1000ms, and would like help finding out which config is causing the timeout. We have a solution that runs behind WebSEAL and this solution requires a connection to be open for at least 5 seconds.

We have the following values ​​in config for affected Reverse Proxy instance:

[WebSocket]

max-worker-threads = 500

idle-worker-threads = 50

# jct-read-inactive-timeout = 120

clt-read-inactive-timeout = 120

jct-write-blocked-timeout = 20

clt-write-blocked-timeout = 20

For the [server] stanza, we first had default values:

client-connect-timeout = 120

persistent-con-timeout = 5

intra-connection-timeout = 60

With these default values, WebSocket connection works as long as the server sends 'KeepAlive' messages to all clients every 500ms. If we send messages every 1000ms then we get timeout eventually, and with messages every 2000ms we get timeout immediately. The conclusion is that there is a kind of socket / timeout setting in WebSeal that strikes around 1000ms, but which we have not so far managed to identify.

We have also tried this setting:

persistent-con-timeout = 0

- and then WebSocket connection fails as expected, but then we at least know that the setting is 'picked up'. We have also tried overriding persistent-con-timeout under [junction:/<junction-name>] stanza, without any effect..