You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have two hosts:
1) LINUX, IP = 192.168.0.220
2) WINDOWS, IP = 192.168.43.154
Both these machines have instance of FB SuperServer, builds are identical: 32114. So, one may to connect from Windows (as client) to Linux (as server), and vice versa.
It seems that LINUX client 3.x performs DISconnect operation about 10 (ten) seconds instead of some small time (less than 0.1...0.2s as before).
Steps to reproduce:
1. Create new database with name that has been aliased in databases.conf (in my sample this alias is 'e30').
2. Prepare config files for FB 3.0 SuperServer, then restart FB service (daemon) on both hosts.
echo.
echo -------------------------------------------------------------------------
echo.
echo Use WINDOWS client. Connect + disconnect to the database on WINDOWS host:
echo
echo -------------------------------------------------------------------------
echo
echo use LINUX client. Connect + disconnect to the database on WINDOWS host:
use LINUX client. Connect + disconnect to the database on WINDOWS host:
2015-10-24 19:11:34.5226
ISQL Version: LI-V3.0.0.32114 Firebird 3.0 Release Candidate 1
Server version:
WI-V3.0.0.32114 Firebird 3.0 Release Candidate 1
WI-V3.0.0.32114 Firebird 3.0 Release Candidate 1/tcp (csprog)/P13
LI-V3.0.0.32114 Firebird 3.0 Release Candidate 1/tcp (oel64)/P13
2015-10-24 19:11:44.5849
Disconnect time is about 10...11 seconds when use LINUX client (lines with text about client & server version appear instantly; delay is exacty on DISconnect).
Test measures APPROXIMATE time that is required for detaching from database by evaluating number of seconds that passed
from UNIX standard epoch time inside ISQL and writing it to log.
After returning control from ISQL we evaluate again that number by calling Python 'time.time()' - and it will return value upto current UTC time, i.e. it WILL take in account local timezone from OS settings (this is so at least on Windows). Thus we have to add/substract time shift
between UTC and local time - this is done by 'time.timezone' summand.
Tested on WI-V3.0.0.32140 (SS/SC/CC).
NB. Test on LINUX was not done yet, so I've assign platform = 'Windows' yet.
The text was updated successfully, but these errors were encountered:
summary: Detach from database 3.x using linux client 3.x is too long (compared with same operation that uses windows client 3.x) => Detach of 3.x database from 3.x Linux client takes much longer than from 3.x Windows client
Test Details: Test measures APPROXIMATE time that is required for detaching from database by evaluating number of seconds that passed
from UNIX standard epoch time inside ISQL and writing it to log.
After returning control from ISQL we evaluate again that number by calling Python 'time.time()' - and it will return value upto current UTC time, i.e. it WILL take in account local timezone from OS settings (this is so at least on Windows). Thus we have to add/substract time shift
between UTC and local time - this is done by 'time.timezone' summand.
Tested on WI-V3.0.0.32140 (SS/SC/CC).
NB. Test on LINUX was not done yet, so I've assign platform = 'Windows' yet.
Submitted by: @pavel-zotov
I have two hosts:
1) LINUX, IP = 192.168.0.220
2) WINDOWS, IP = 192.168.43.154
Both these machines have instance of FB SuperServer, builds are identical: 32114. So, one may to connect from Windows (as client) to Linux (as server), and vice versa.
It seems that LINUX client 3.x performs DISconnect operation about 10 (ten) seconds instead of some small time (less than 0.1...0.2s as before).
Steps to reproduce:
1. Create new database with name that has been aliased in databases.conf (in my sample this alias is 'e30').
2. Prepare config files for FB 3.0 SuperServer, then restart FB service (daemon) on both hosts.
Config on Windows host:
AuthClient = Legacy_Auth,Srp,Win_Sspi
AuthServer = Legacy_Auth,Srp
DeadlockTimeout = 1
ExternalFileAccess = Restrict C:\MIX\firebird
FileSystemCacheThreshold = 65536K
LockHashSlots = 22111
MaxUnflushedWrites = -1
MaxUnflushedWriteTime = -1
MaxUserTraceLogSize = 99999
RemoteServicePort = 3333
Servermode = Super
TempDirectories = c:\temp
UdfAccess = Restrict UDF;C:\WINNT\system32
UserManager = Legacy_UserManager
WireCrypt = Disabled
Config on LINUX host:
AuthClient = Legacy_Auth,Srp,Win_Sspi
AuthServer = Legacy_Auth,Srp
DefaultDbCachePages = 512K
ExternalFileAccess = Restrict /var/db/fb30
FileSystemCacheThreshold = 65536K
LockHashSlots = 22111
MaxUserTraceLogSize = 99999
RemoteServicePort = 3333
Servermode = Super
TempCacheLimit = 2147483647
TempDirectories = /tmp/firebird
UserManager = Legacy_UserManager
WireCrypt = Disabled
3. Create batch on WINDOWS host:
@echo off
setlocal enabledelayedexpansion enableextensions
echo.
echo Use WINDOWS client. Connect + disconnect to the database on LINUX host:
echo !time!
echo quit; | isql 192.168.0.220/3333:e30 -n -q -z
echo !time!
echo.
echo -------------------------------------------------------------------------
echo.
echo Use WINDOWS client. Connect + disconnect to the database on WINDOWS host:
echo !time!
echo quit; | isql localhost/3333:e30 -n -q -z
echo !time!
4. Create shell script on LINUX host:
echo
echo Use LINUX client. Connect + disconnect to the database on LINUX host:
echo$(echo -n $ (date +'%Y-%m-%d %H:%M:%S.%N')|cut -c1-24)$(echo -n $ (date +'%Y-%m-%d %H:%M:%S.%N')|cut -c1-24)
echo quit\; | /opt/fb30ss/bin/isql localhost/3333:e30 -q -n -z
echo
echo
echo -------------------------------------------------------------------------
echo
echo use LINUX client. Connect + disconnect to the database on WINDOWS host:
echo$(echo -n $ (date +'%Y-%m-%d %H:%M:%S.%N')|cut -c1-24)$(echo -n $ (date +'%Y-%m-%d %H:%M:%S.%N')|cut -c1-24)
echo quit\; | /opt/fb30ss/bin/isql 192.168.43.154/3333:e30 -q -n -z
echo
Results
#######
1. When doing connect using WINDOWS client to LINUX or WINDOWS:
Use WINDOWS client. Connect + disconnect to the database on LINUX host:
18:55:08,16
ISQL Version: WI-V3.0.0.32114 Firebird 3.0 Release Candidate 1
Server version:
LI-V3.0.0.32114 Firebird 3.0 Release Candidate 1
LI-V3.0.0.32114 Firebird 3.0 Release Candidate 1/tcp (oel64)/P13
WI-V3.0.0.32114 Firebird 3.0 Release Candidate 1/tcp (csprog)/P13
18:55:08,82
-------------------------------------------------------------------------
Use WINDOWS client. Connect + disconnect to the database on WINDOWS host:
18:55:08,85
ISQL Version: WI-V3.0.0.32114 Firebird 3.0 Release Candidate 1
Server version:
WI-V3.0.0.32114 Firebird 3.0 Release Candidate 1
WI-V3.0.0.32114 Firebird 3.0 Release Candidate 1/tcp (csprog)/P13
WI-V3.0.0.32114 Firebird 3.0 Release Candidate 1/tcp (csprog)/P13
18:55:09,10
2. When doing connect using LINUX client to LINUX or WINDOWS:
Use LINUX client. Connect + disconnect to the database on LINUX host:
2015-10-24 19:11:23.6561
ISQL Version: LI-V3.0.0.32114 Firebird 3.0 Release Candidate 1
Server version:
LI-V3.0.0.32114 Firebird 3.0 Release Candidate 1
LI-V3.0.0.32114 Firebird 3.0 Release Candidate 1/tcp (oel64)/P13
LI-V3.0.0.32114 Firebird 3.0 Release Candidate 1/tcp (oel64)/P13
2015-10-24 19:11:34.5203
-------------------------------------------------------------------------
use LINUX client. Connect + disconnect to the database on WINDOWS host:
2015-10-24 19:11:34.5226
ISQL Version: LI-V3.0.0.32114 Firebird 3.0 Release Candidate 1
Server version:
WI-V3.0.0.32114 Firebird 3.0 Release Candidate 1
WI-V3.0.0.32114 Firebird 3.0 Release Candidate 1/tcp (csprog)/P13
LI-V3.0.0.32114 Firebird 3.0 Release Candidate 1/tcp (oel64)/P13
2015-10-24 19:11:44.5849
Disconnect time is about 10...11 seconds when use LINUX client (lines with text about client & server version appear instantly; delay is exacty on DISconnect).
Commits: 7f5408d FirebirdSQL/fbt-repository@4056f70
====== Test Details ======
Test measures APPROXIMATE time that is required for detaching from database by evaluating number of seconds that passed
from UNIX standard epoch time inside ISQL and writing it to log.
After returning control from ISQL we evaluate again that number by calling Python 'time.time()' - and it will return value upto current UTC time, i.e. it WILL take in account local timezone from OS settings (this is so at least on Windows). Thus we have to add/substract time shift
between UTC and local time - this is done by 'time.timezone' summand.
Tested on WI-V3.0.0.32140 (SS/SC/CC).
NB. Test on LINUX was not done yet, so I've assign platform = 'Windows' yet.
The text was updated successfully, but these errors were encountered: