Type |
Bug
|
Priority |
Normal
|
Assignee | |
Version |
tigase-server-8.3.0
|
Spent time |
15m
|
Issue Votes (0)
Watchers (0)
Type |
Bug
|
Priority |
Normal
|
Assignee | |
Version |
tigase-server-8.3.0
|
Spent time |
15m
|
(From: https://github.com/tigase/tigase-server/issues/154)
Describe the bug
BoshSession has an inactivity timer task that will be started at the end of every connection. When this timer fires, the user's session will be closed. However, if the chat client sends another connection before this timer expires then the timer is cancelled and the users' session will continue to remain. The duration for this timer, according to BoshConnectionManager code, is default to 10 seconds, and should be configurable via the bosh/max-inactivity property key in config.tdsl config file. However, this configuration override is not possible and the inactivity timeout is always stuck at 10s.
The cause of the issue seems to be another property in BoshConnectionManager, max_pause, that happens to use the same config key as max_inactivity. When we set max-inactivity in config.tdsl file, only max_pause value is updated to the new config value, but not max_inactivity.
BoshConnectionManager.java
To Reproduce Steps to reproduce the behavior:
Also enable "FINEST" logging level in tigase, by modifying logging section in config.tdsl like this:
Impact BoshSession inactivity timer always uses 10s timeout regardless of config. This leads to the user's session getting closed prematurely when the browser stop sending requests due to timer throttling in the browser (see https://bugs.chromium.org/p/chromium/issues/detail?id=1186569 ). This causes the chat client to be disconnected.
Expected behavior BoshSession inactivity timer uses the timeout value set in max-inactivity config property in config.tdsl.
Details (please complete the following information):
Additional context
tigase log shows the inactivity timer starting and firing after 10 seconds (note that the 1st log line has a bug where the part "Setting inactivityTimer for 10..." wasn't printed correctly, which I patched myself while investigating this issue):