Superserver hangs when multiple clients create tables simultaneously [CORE2184]

[firebird-automations]

Submitted by: Ross Bunker (rbunker.tsi)

Is related to CORE1788
Is related to CORE1963

First found when doing multi-threading work in our application where we spin up multiple simultaneous connections to the same database.
I was able to isolate to a simple repro scenario using isql.

1) Open a command prompt
2) cd to \Program Files\Firebird\Firebird_2_1
3) run the following command line
for /L %i in (1,1,16) do start cmd.exe /c "echo CONNECT examples\empbuild\EMPLOYEE.FDB; CREATE TABLE "#⁠TEST_%i_Connect" ("COL" INTEGER); DROP TABLE "#⁠TEST_%i_Connect"; | bin\isql -u SYSDBA -p masterkey -q"

Commits: 21b9555 dcfa92f 11bdf60 577a3b8 c5961c5

[firebird-automations]

Commented by: Sean Leyne (seanleyne)

Are the separate connections each trying to create the same table?

[firebird-automations]

Commented by: Ross Bunker (rbunker.tsi)

No, they are each creating a unique table name. "#⁠TEST_%i_Connect", the %i is replaced by the number 1-16

:)ross

[firebird-automations]

Commented by: Sean Leyne (seanleyne)

Have you tried adding a "Commit;" after creating and also dropping the tables?

[firebird-automations]

Modified by: @dyemanov

assignee: Dmitry Yemanov [ dimitr ]

[firebird-automations]

Modified by: @dyemanov

Link: This issue is related to CORE1788 [ CORE1788 ]

[firebird-automations]

Commented by: @dyemanov

This particular deadlock is known and fixed in v2.5. It's easy to backport the bugfix into v2.1.2, if required. But, unfortunately, there are other known issues (crashes, other hangs) caused by simultaneous metadata updates and I'm not sure it's technically possible to backport the whole bunch of the related bugfixes.

[firebird-automations]

Commented by: @dyemanov

Moreover, it seems that even v2.5 still don't have all the related bugs fixed, as I can reproduce a rare hang with the provided test case.
So I schedule this ticket for v2.5 with a future consideration about porting back into v2.1.x, if it's going to be doable.

[firebird-automations]

Modified by: @dyemanov

status: Open [ 1 ] => In Progress [ 3 ]

[firebird-automations]

Modified by: @dyemanov

Link: This issue is related to CORE1963 [ CORE1963 ]

[firebird-automations]

Modified by: @dyemanov

priority: Blocker [ 1 ] => Major [ 3 ]

Version: 2.1.0 [ 10041 ]

Component: Engine [ 10000 ]

[firebird-automations]

Modified by: @dyemanov

status: In Progress [ 3 ] => Open [ 1 ]

[firebird-automations]

Commented by: @dyemanov

All the appropriate bugfixes have been backported from v2.5, the test case runs without failures in v2.1.2 now.
One kind of the similar issue still looks being reproducible in HEAD, but it seems being an unrelated one and will be tracked independently.

[firebird-automations]

Modified by: @dyemanov

status: Open [ 1 ] => Resolved [ 5 ]

resolution: Fixed [ 1 ]

Fix Version: 2.1.2 [ 10270 ]

[firebird-automations]

Commented by: Ross Bunker (rbunker.tsi)

Thanks so much! You guys rock! I'll get a snapshot ASAP and test it out.
:)ross

[firebird-automations]

Commented by: Ross Bunker (rbunker.tsi)

Confirmed fixed in 2.1.2.18108

:)ross

[firebird-automations]

Modified by: @pcisar

status: Resolved [ 5 ] => Closed [ 6 ]

[firebird-automations]

Modified by: @pavel-zotov

QA Status: No test