When engine shutdown is already in progress, the server is still running and listening for/processing incoming packets including possible login requests.
But during shutdown the security database is unavailable, therefore plugins may return auth failures.
In some cases (like all db users using same login) this may cause "banning" of login attempts (due to multiple login failures -- which is designed to manage DDOS attack conditions). This causes the related worker threads to sleep for a while before returning login failure to user. Such threads cause the shutdown process to pause, making it wait till the end of "ban period".
Currently there is no ability to restart FB instance from fbtest framework.
Though such test can be implemented by using 'sc.exe' and .bat with bulk ISQLs that are launched at the same time (Linux has, of course, similar tools for that task).
Modified by: Sean Leyne (seanleyne)
description: When engine shutdown is already in progress server is still running and listening to incoming packets including possible login requests\. But security database is unavailable, therefore plugins return auth failures\. In some cases \(like all users working with same login\) this may cause banning of logins, i\.e\. worker threads will sleep for a while before replying login failure to user\. Such threads prevent server shutdown making it wait till the end of ban period\. =\> When engine shutdown is already in progress, the server is still running and listening for/processing incoming packets including possible login requests\.
But during shutdown the security database is unavailable, therefore plugins may return auth failures\.
In some cases \(like all db users using same login\) this may cause "banning" of login attempts \(due to multiple login failures \-\- which is designed to manage DDOS attack conditions\)\. This causes the related worker threads to sleep for a while before returning login failure to user\. Such threads cause the shutdown process to pause, making it wait till the end of "ban period"\.
summary: Banned during engine shutdown threads cause unwanted delays when shutting server =\> Login attempts while engine is shutting down caused unnecessary delays in shutdown process
Modified by: @pavel-zotov
status: Resolved \[ 5 \] =\> Resolved \[ 5 \]
QA Status: No test =\> Deferred
Test Details: Currently there is no ability to restart FB instance from fbtest framework\.
Though such test can be implemented by using 'sc\.exe' and \.bat with bulk ISQLs that are launched at the same time \(Linux has, of course, similar tools for that task\)\.
Submitted by: @hvlad
When engine shutdown is already in progress, the server is still running and listening for/processing incoming packets including possible login requests.
But during shutdown the security database is unavailable, therefore plugins may return auth failures.
In some cases (like all db users using same login) this may cause "banning" of login attempts (due to multiple login failures -- which is designed to manage DDOS attack conditions). This causes the related worker threads to sleep for a while before returning login failure to user. Such threads cause the shutdown process to pause, making it wait till the end of "ban period".
Commits: FirebirdSQL/firebird@dfc0259fe432042c8c71cc493c1933a6fadd1364 FirebirdSQL/firebird@fea7c61d9741dc142fa020bf3aa93af7e52e2002 FirebirdSQL/firebird@a74130019af89012cc1e04ba18bbc9c4a69e1a5d FirebirdSQL/firebird@9675ab2ceeee06056b6e60ba5288daa41df1af0d FirebirdSQL/firebird@87c306e966aa038a68afd40d92f5ac800f8b9600
====== Test Details ======
Currently there is no ability to restart FB instance from fbtest framework. Though such test can be implemented by using 'sc.exe' and .bat with bulk ISQLs that are launched at the same time (Linux has, of course, similar tools for that task).