Flamerobin 0.9.14 long wait for connection to the database to complete

[livius2]

Hi,

I've probably upgraded from version 0.9.12, and now FlameRobin takes a long time during the final “Complete” step.

It fetches all the information quickly, but at the “Complete” step it hangs for about one minute.

[arvanus]

If you go back to 0.9.12, it works fine?
Is this a local or remote database, and can you inform approximately how many objects (users, tables, SPs, views, functions....) this database have?

[livius2]

[livius2]

I went back even to 9.9 and it still wait long. So probably something else causing this.
And yes, database is remote. Interesting that it take full CPU core at this "Compleate" step.

[baldeuniversel]

Hello ! @livius2 , are you recently changed the version of your firebird (the service) ? 🧐

[livius2]

@baldeuniversel No, it is the same for years, quite old, but as is stable on production so not changed.

WI-V3.0.5.33187 Firebird 3.0

[baldeuniversel]

@livius2 ! Perhaps, a simulation on the virtual machine can give responses (I recommend you to use the new version of the firebird as tests) 🤔 .

[livius2]

@baldeuniversel
I tested with Firebird 5 and recent fbclient on the same machine and got the same result.

What exactly happens in the “complete” state? Understanding this might shed some light on the issue and help me identify the cause.

All steps prior to the “complete” message run very quickly. Thx.

[baldeuniversel]

@livius2 , what's the version of your operating system (I assume your OS is Windows) ?

[baldeuniversel]

@livius2, several possible hypotheses 🤔.

Could you do the test on a smaller database?

[jobrvfp]

Same example database opening delay (12 seconds) FlameRobin 0.9.14, Windows 10 Pro, Firebird 4

[livius2]

@baldeuniversel
I’m using Windows 11 Pro.
I tested on a fresh database, and the operation finished instantly.
After creating 500 tables, the process now pauses for six seconds at the “complete” state.
Each table is created in exactly the same way:

CREATE TABLE TAB_1
(
  FIELD_1 VARCHAR(20),
  FIELD_2 VARCHAR(20),
  FIELD_3 VARCHAR(20),
  FIELD_4 VARCHAR(20),
  FIELD_5 VARCHAR(20),
  FIELD_6 VARCHAR(20),
  FIELD_7 VARCHAR(20),
  FIELD_8 VARCHAR(20),
  FIELD_9 VARCHAR(20),
  FIELD_10 VARCHAR(20),
  FIELD_11 VARCHAR(20),
  FIELD_12 VARCHAR(20),
  FIELD_13 VARCHAR(20),
  FIELD_14 VARCHAR(20),
  FIELD_15 VARCHAR(20),
  FIELD_16 VARCHAR(20),
  FIELD_17 VARCHAR(20),
  FIELD_18 VARCHAR(20),
  FIELD_19 VARCHAR(20),
  FIELD_20 VARCHAR(20),
  FIELD_21 VARCHAR(20),
  FIELD_22 VARCHAR(20),
  FIELD_23 VARCHAR(20),
  FIELD_24 VARCHAR(20),
  FIELD_25 VARCHAR(20),
  FIELD_26 VARCHAR(20),
  FIELD_27 VARCHAR(20),
  FIELD_28 VARCHAR(20),
  FIELD_29 VARCHAR(20)
);

[baldeuniversel]

@livius2.
Yeah ! I see 🤔. One of the solutions could be to load a set of resources in a deferred way (if it's not already the case). I will try to implement a solution that goes in this direction. You can test it by downloading the build version for Windows via the workflow (git action). If it works well, it could be adopted.

[arvanus]

@baldeuniversel did you were able to reproduce the problem @livius2 have?
created a sample database in a remote server, and got no delay

set term ` ;
execute block 
as
declare variable i integer;
BEGIN
  i =1;
  while (i<=500) do
  BEGIN
    execute statement 'CREATE TABLE TAB_'||i||' 
(
  FIELD_1 VARCHAR(20),
  FIELD_2 VARCHAR(20),
  FIELD_3 VARCHAR(20),
  FIELD_4 VARCHAR(20),
  FIELD_5 VARCHAR(20),
  FIELD_6 VARCHAR(20),
  FIELD_7 VARCHAR(20),
  FIELD_8 VARCHAR(20),
  FIELD_9 VARCHAR(20),
  FIELD_10 VARCHAR(20),
  FIELD_11 VARCHAR(20),
  FIELD_12 VARCHAR(20),
  FIELD_13 VARCHAR(20),
  FIELD_14 VARCHAR(20),
  FIELD_15 VARCHAR(20),
  FIELD_16 VARCHAR(20),
  FIELD_17 VARCHAR(20),
  FIELD_18 VARCHAR(20),
  FIELD_19 VARCHAR(20),
  FIELD_20 VARCHAR(20),
  FIELD_21 VARCHAR(20),
  FIELD_22 VARCHAR(20),
  FIELD_23 VARCHAR(20),
  FIELD_24 VARCHAR(20),
  FIELD_25 VARCHAR(20),
  FIELD_26 VARCHAR(20),
  FIELD_27 VARCHAR(20),
  FIELD_28 VARCHAR(20),
  FIELD_29 VARCHAR(20)
);';
    i=i+1;
  end
end`
set term ; `

But to be fair, in this remote database from the print I got 2 seconds delay

[arvanus]

Flamerobin had a related problem some time ago:
#138
#181
#139

Could you try the previous version just to be 100% sure its not related?

[livius2]

@arvanus which exact tag to try?