|
i have sent download details to you by e-mail.
I do not know how to reproduce the issue. Only thing that seems weird to me, is garbage collector and its transaction, which i noticed might be running for days, can that be related? I think, that I might have had same issue (I downgraded test system back to 3.0.5). It is 32 bit version.
When I upgraded it to 3.0.6, then connecting to database became slow. I was especially bad, because we have software, that in startup checks all possible databases, it can have (current configuration was 36) by connecting them and then making queries to one internal table and RDB$DATABASE and MON$DATABASE. With 3.0.5 it took 6 seconds (with only 1 database existing out of 36), but with 3.0.6 it took ages. It happened with release version (downloaded from homepage). The issue is related with monitoring tables, accessed from ON CONNECT trigger.
While it is not very recommended to do - it is fully legal and should not freeze whole server. We are looking for solution, please wait a bit. Not sure if it is related to this issue, but I also experence serious slowness in FB 3.0.6, when compared with 3.0.5. In my case, the affected operations are
1) large blob inserts, that periodically gets blocked at isc_put_segment calls 2) series of large ddl statements during database creation, that are also periodically blocked. The blocks last for several minutes, during which there is no obvious server activity (minimum CPU/HDD/Network load), so it looks rather like a timeout. The process eventually resumes (no error message), but the problem repeates soon after (on another blob segment or ddl command). Tested on Win 10 and virtual Ubuntu 20.04 (server side) with 64 bit FB 3.0.6, client app at Win 10. Switching back to 3.0.5 solves the issue. michalk1,
if you have test case - feel free to create new ticket or describe issue in fb-devel if you not sure. Ok, mine is also probably different issue, because there are not triggers. But having existing connection to database server is important fact. Wrote powershell script to test connecting databases and it stalls on connecting seventh database, that does not exist.
I just found that my case has something to do with wire compression (I set WireCompression = true at client side). When I turn it off, 3.0.6 is back at full speed of 3.0.5. To reproduce the problem, it should be sufficient to insert a large file (say Firebird installation exe file) into any database binary blob field when wire compression is active. I'll probably open a new ticket for it.
The code that we do in ON CONNECTION trigger:
-- Get connection details SELECT FIRST 1 MON$REMOTE_PROCESS, MON$REMOTE_ADDRESS FROM MON$ATTACHMENTS WHERE MON$ATTACHMENT_ID=current_connection INTO :proc,:address; -- Create record in ApplicationLog BEGIN INSERT INTO UserLogins (application,IP) VALUES (:proc,:address) RETURNING id INTO :id; WHEN ANY DO BEGIN END END May it will help you. PS: Will be good, if there will be a way how to get connection details out of monitoring tables. RDB$GET_CONTEXT('SYSTEM', 'CLIENT_PROCESS')
RDB$GET_CONTEXT('SYSTEM', 'CLIENT_ADDRESS') RDB$GET_CONTEXT('SYSTEM', 'CLIENT_PROCESS') is not defined in FB2.5 docs but works (on FB2.5).
It was added to v2.5.3, see
You are right, but documentation for FB2.5.9 says:
SYSTEM namespace provides read-only access to the following variables. Variable name Value ------------------------------------------------------------------------------ NETWORK_PROTOCOL | The network protocol used by client to connect. Currently | used values: "TCPv4", "WNET", "XNET" and NULL | CLIENT_ADDRESS | The wire protocol address of remote client represented as | string. Value is IP address in form "xxx.xxx.xxx.xxx" for | TCPv4 protocol, local host name for XNET protocol and | NULL for all other protocols | DB_NAME | Canonical name of current database. It is either alias | name if connectivity via file names is not allowed or | fully expanded database file name otherwise. | ISOLATION_LEVEL | Isolation level for current transaction. Returned values | are "READ COMMITTED", "CONSISTENCY", "SNAPSHOT" | TRANSACTION_ID | Numeric ID for current transaction. Returned value is the | same as of CURRENT_TRANSACTION pseudo-variable | SESSION_ID | Numeric ID for current session. Returned value is the | same as of CURRENT_CONNECTION pseudo-variable | CURRENT_USER | Current user for the connection. Returned value is the | same as of CURRENT_USER pseudo-variable | CURRENT_ROLE | Current role for the connection. Returned value is the | same as of CURRENT_ROLE pseudo-variable | ENGINE_VERSION | Engine version number, e.g. "2.1.0" (since V2.1) https://github.com/FirebirdSQL/firebird/blob/B2_5_Release/doc/sql.extensions/README.context_variables2 The fix is committed into v3, please check next snapshot build
@Vlad will this also be ported to Firebird 4? Because I believe the problem occurs there as well.
|
|||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Blocker
New connection to the server hangs
If you have dump - please share it with us, but we need also .pdb files of that snapshot build (33296), else dump is useless.