Attempting to connect too quickly at startup fails

28 views
Skip to first unread message

Eric Himmer

unread,
Feb 17, 2021, 4:27:18 PMFeb 17
to firebird-support
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

unread,
Feb 17, 2021, 4:55:07 PMFeb 17
to firebird...@googlegroups.com
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

unread,
Feb 17, 2021, 5:02:31 PMFeb 17
to firebird-support
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

unread,
Feb 18, 2021, 9:11:29 AMFeb 18
to firebird...@googlegroups.com
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

unread,
Feb 19, 2021, 12:37:12 AMFeb 19
to firebird-support

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

unread,
Feb 19, 2021, 4:10:52 AMFeb 19
to firebird...@googlegroups.com
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

unread,
Feb 19, 2021, 8:02:30 PMFeb 19
to firebird-support
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

unread,
Feb 20, 2021, 2:12:01 AMFeb 20
to firebird...@googlegroups.com
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
Reply all
Reply to author
Forward
0 new messages