Issue Details (XML | Word | Printable)

Key: CORE-6346
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Blocker Blocker
Assignee: Vlad Khorsun
Reporter: Daniel Trubač
Votes: 1
Watchers: 8
Operations

If you were logged in you would be able to see more operations.
Firebird Core

New connection to the server hangs

Created: 29/Jun/20 12:57 PM   Updated: 08/Jul/20 11:00 PM
Component/s: None
Affects Version/s: 3.0.6
Fix Version/s: 4.0 RC 1, 3.0.7

File Attachments: 1. Zip Archive stack.zip (15 kB)

Environment:
Windows Server 2008 R2 Standard SP1 64bit
Xeon X3430 2.4GHz, 8GB RAM
firebird.exe is 3.0.6.33296, snapshot build
original installation was 3.0.5 release, which was updated to snapshot build when this issue first appeared.

QA Status: No test


 Description  « Hide
Hello,

symptoms:
established connections are working without problem, but new connection hangs, tried from .net, ibeexpert.

Please mail me if you would like to have process dump.

Please let me know if there is anything else that i could provide to help with investigation of the issue.
When it happens again, is there anything that i could try to resolve such issue without killing the process?

Thank you
Best regards
Daniel Trubač

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Vlad Khorsun added a comment - 29/Jun/20 01:59 PM
Is it reproducible ? If yes - please, provide steps to reproduce.
If you have dump - please share it with us, but we need also .pdb files of that snapshot build (33296), else dump is useless.

Daniel Trubač added a comment - 29/Jun/20 04:28 PM - edited
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?

Virgo Pärna added a comment - 30/Jun/20 06:33 AM - edited
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).

Vlad Khorsun added a comment - 30/Jun/20 06:45 AM
Stack trace

Vlad Khorsun added a comment - 30/Jun/20 06:48 AM
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.

michalk1 added a comment - 30/Jun/20 06:54 AM
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.

Vlad Khorsun added a comment - 30/Jun/20 07:29 AM
michalk1,

if you have test case - feel free to create new ticket or describe issue in fb-devel if you not sure.

Virgo Pärna added a comment - 30/Jun/20 08:31 AM
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.

michalk1 added a comment - 30/Jun/20 08:57 AM
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.

Slavomir Skopalik added a comment - 30/Jun/20 10:52 AM
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.

Dmitry Yemanov added a comment - 30/Jun/20 10:56 AM
RDB$GET_CONTEXT('SYSTEM', 'CLIENT_PROCESS')
RDB$GET_CONTEXT('SYSTEM', 'CLIENT_ADDRESS')

Slavomir Skopalik added a comment - 30/Jun/20 11:19 AM
RDB$GET_CONTEXT('SYSTEM', 'CLIENT_PROCESS') is not defined in FB2.5 docs but works (on FB2.5).

Dmitry Yemanov added a comment - 30/Jun/20 11:24 AM
It was added to v2.5.3, see CORE-3704.

Slavomir Skopalik added a comment - 30/Jun/20 11:33 AM
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

Sean Leyne added a comment - 30/Jun/20 03:36 PM
This ticket seems related to other connection issues reported related to 3.0.6 [CORE-6346, CORE-6347 and CORE-6348]

Vlad Khorsun added a comment - 02/Jul/20 12:14 PM
The fix is committed into v3, please check next snapshot build

Mark Rotteveel added a comment - 02/Jul/20 08:19 PM
@Vlad will this also be ported to Firebird 4? Because I believe the problem occurs there as well.

Vlad Khorsun added a comment - 02/Jul/20 09:03 PM
Sure