Attempting to connect too quickly at startup fails

[Eric Himmer]

I have a few customers that initiate our application immediately on boot up.  Very frequently it will fail to connect to the Firebird server with an "Authentication error, connection shutdown" (from firebird.log).  When that happens, they can never connect again without restarting the service (FirebirdServerDefaultInstance).  Restarting our app does not help.  If they wait a little while before launching our app, it works fine.  I cannot easily duplicate it on my older i5 system, but have on rare occasions.

We use FireDAC (Delphi application) to connect, and the error from FireDAC is:

[FireDAC][Phys][FB]Error occurred during login, please check server firebird.log for details

I've added code to be sure the service is running before I attempt a query.  After confirming it is running, I issue the following query to be sure I can connect:

SELECT current_timestamp from RDB$DATABASE

This is the query that fails and requires a restart of the service.

Using Firebird 3.0.7.33374_1_x64

ServerMode = SuperClassic

Using the default user name and password.

I also use Pooled connections.

The rest of the parameters are just using the defaults.

Is there a better way to determine the service is up and running and fully initialized?  Perhaps I have a setting wrong or missing in my connection parameters?  Or maybe there is a bug that is locking up authorizations if a connection comes in too soon?

[Mark Rotteveel]

On 2021-02-17 21:54, Eric Himmer wrote:
> I have a few customers that initiate our application immediately on
> boot up. Very frequently it will fail to connect to the Firebird
> server with an "Authentication error, connection shutdown" (from
> firebird.log). When that happens, they can never connect again
> without restarting the service (FirebirdServerDefaultInstance).
> Restarting our app does not help. If they wait a little while before
> launching our app, it works fine. I cannot easily duplicate it on my
> older i5 system, but have on rare occasions.
>
> We use FireDAC (Delphi application) to connect, and the error from
> FireDAC is:
> [FireDAC][Phys][FB]Error occurred during login, please check server
> firebird.log for details

Is there anything in the firebird.log?

Mark

[Eric Himmer]

Yes, example from firebird.log (he kept trying after restarting our app)  Restarting the service fixed it:

MARK-T470P Mon Feb 15 17:10:06 2021

Authentication error

connection shutdown

MARK-T470P Mon Feb 15 17:10:18 2021

Authentication error

connection shutdown

MARK-T470P Mon Feb 15 17:10:39 2021

Authentication error

connection shutdown

[Mark Rotteveel]

It sounds like a bug, please report it in the tracker.

That said, exactly how is this application started? Is it also a Windows
service? If so, you might want to consider declaring a dependency on the
Firebird service, or configuring the service of this application to use
*Automatic (Delayed Start)* instead of *Automatic*.

Out of curiosity: what kind of application is this? It sounds like a
'server per user' situation where the Firebird server runs on the same
host as the user application.

As a workaround, try switching the ServerMode to something else, e.g.
SuperServer; or try using Firebird Embedded instead of Firebird server.

Mark
--
Mark Rotteveel

[Peter]

AFAIU Windows, in an attempt to give the illusion of starting up fast presents the desktop at the earliest opportunity and long before all services have started up. Trying to the start a program that relies on certain services is doomed to fail.

One can try to declutter Windows and hope that the startup becomes faster overall. Alternatively give it a minute or two before launching applications.

It is really a Windows problem and not an FB one.

Peter

Technisoft

[Mark Rotteveel]

On 2021-02-19 06:37, Peter wrote:
> AFAIU Windows, in an attempt to give the illusion of starting up fast
> presents the desktop at the earliest opportunity and long before all
> services have started up. Trying to the start a program that relies on
> certain services is doomed to fail.
> One can try to declutter Windows and hope that the startup becomes
> faster overall. Alternatively give it a minute or two before launching
> applications.
> It is really a Windows problem and not an FB one.

The problem appears to be - based on the description in this thread -
that attempts to connect to Firebird when it isn't fully up yet somehow
breaks Firebird, disallowing other connection attempts. That definitely
sounds like a problem in Firebird:

1. It shouldn't accept connections before it is ready,
2. A failure to connect should not prevent later connections from
succeeding.

That Windows might start the desktop too early is just a contributing
factor that exposes the issue. I would guess it can also occur when you
start the service manually and try to connect to quickly.

Mark

[Eric Himmer]

The application is a standard Windows app, both 32 and 64bit versions.  In a typical install, it is a single user on the same machine as the FB Server (the app accesses four separate FB databases).  Multiple instances of the app can be instantiated as well as other potential apps needing access to the same databases on the same machine.  However, I also want users to be able to share the databases over their local network if they are in an office environment, but could be a different install or configuration down the road.  Likewise, it would be nice to offer access to the databases over the WAN, not necessarily over VPN (again, perhaps a different option we can provide separately).

It was my understanding that the specific embedded version went away with v3 (no more fbembed.dll).  I used the embedded version with our older app which uses FB2.  This new version uses FB3 and so I basically guessed at using SuperClassic and runs as a service.  No idea if that was actually the right choice, maybe SuperServer might be better?.  I'll re-read the documentation as it was a bit confusing to me at the time.

[Mark Rotteveel]

On 20-02-2021 02:01, Eric Himmer wrote:
> It was my understanding that the specific embedded version went away
> with v3 (no more fbembed.dll).  I used the embedded version with our
> older app which uses FB2.  This new version uses FB3 and so I basically
> guessed at using SuperClassic and runs as a service.  No idea if that
> was actually the right choice, maybe SuperServer might be better?.  I'll
> re-read the documentation as it was a bit confusing to me at the time.

Firebird Embedded still exists, what changed is that

1) There no longer is a separate binary distribution on Windows, you can
use a normal Firebird installation (or zipkit) as Firebird Embedded by
using the fbclient.dll in its installation directory
2) fbembed.dll no longer exists, Firebird Embedded is now fbclient.dll +
plugins/engine12.dll (and supporting DLLs)

Basically, to get a Firebird Embedded, all you need is to unzip the
zipkit, optionally delete the .exe files, and point you application to
its fbclient.dll.

The choice for server mode probably doesn't matter that much for local
single user use, though - if your application makes more than one
connection - SuperServer might have some benefit due to shared cache.
However, my suggestion to try another server mode was primarily intended
as troubleshooting/potential workaround: maybe the problem you have
doesn't occur with one of the other server modes.

Mark
--
Mark Rotteveel

[aral...@gmail.com]

I have a similar problem and created an issue:

https://github.com/FirebirdSQL/firebird/issues/6865#issue-925444516

Regards,

Ariel

[Eric Himmer]

Thanks, Ariel.  I completely forgot about creating the issue for this after moving to an embedded implementation described by Mark and my re-reading about FB3's embedded setup.