On 2-10-2018 10:12, 'Moebius, Dr. Jonathan' jonathan.moebius@...
[Firebird-Java] wrote:

>> It would be good to know exactly how those copies are made.. It sounds as
>> if the copy process may not have released its file locks before Firebird
>> tries to open the database file.
>>
> There are several possibilities how a database is copied. One is a
> gradle-copy task running several seconds prior to test execution. A
> second and third one uses Java code. The Java code uses FileOutStreams,
> which are properly closed prior to usage of the database. In my opinion,
> this should be sufficient.

That sounds right, yes.

>> Also, check if the Firebird database files (including the security
>> database) are excluded from your virus scanner.
>>
> That's quite an idea. We'll try as soon as possible.
>
>> As Firebird SuperServer requires exclusive access, this may result in an
>> access denied if another process (the copy process or the virus scan)
>> still has a lock on that file.
>>
> One question though: Firebird tells "createFile failed", is this also
> reported when accessing an existing file? Shouldn't the message be
> "accessFile failed" or something similar?

CreateFile is a Windows API function for opening a file. See
https://docs.microsoft.com/en-us/windows/desktop/api/fileapi/nf-fileapi-createfilea
That links to CreateFileA, but CreateFile maps to either CreateFileA or
CreateFileW (char string vs wide char string if I'm not mistaken)
depending on certain application characteristics.

Firebird reports the lowlevel OS error with the function triggering it
(instead of just hiding it behind a generic 'could not open database'
error).

>> > We are using Firebird-Superserver in 2.5.5, the operating System is
>> > Windows Server 2012 und we ware accessing via jaybird 2.2.10. Firebird
>> > is running in its default-configuration. We are aware, that this may be
>> > problematic and are currently trying to establish a suitable
>> > configuration for our needs.. We are rather free with respect to
>> > experiments within the firebird configuration.
>>
>> Consider updating to Firebird 2.5.8; looking at the release notes I
>> don't really see something similar (except maybe CORE-5067), but it may
>> help.
>>
> We will try. We had hoped to avoid this, as this would be a really
> painful process given the amount of devices involved (this would not
> only affect test-servers but also client devices).

I'd suggest that if changing virus scanner config doesn't fix the
problem, to at least check on your Jenkins server if it resolves or
alleviates the problem.

Also be aware that Firebird 2.5.7 fixed a security bug with UDFs on
Linux (see http://tracker.firebirdsql.org/browse/CORE-5474), that might
be exploitable even if you don't use UDFs yourself.

>> > Is SuperServer a suitable architecture for our scenario with several
>> > client processes or would SuperClassic be better suited?
>>
>> I don't think it will make a difference, but you could always try. If
>> you are using (custom) UDFs, it might make sense to use Classic (not
>> SuperClassic), as in that case, things that might actually crash the
>> server (eg bugs in UDFs, or in Firebird itself for that matter), only
>> affect a single connection (usually).
>>
> We are not using any UDFs at all, just plain SQL.
> I have not gotten the point in the distinction between the three
> products. My impression is, that roughly SuperServer saves ressources
> but doesn't scale, Classic scales but soaks up ressources and
> SuperClassic tries to scale with limited ressources. Would that be a
> fair abbreviation?

Not entirely, SuperServer has the advantage of a shared cache, but it
has some limits in scaling. Connections to a single database need to
serialize their I/O access (as far as I understand it), which reduces
scaling. In 2.1 and earlier on Windows, it also had to use a single
core. For Firebird 2.5 this improved if you change the default setting
of CpuAffinity, but that change has more benefits if you use multiple
databases.

Classic is a process per thread, with things like page cache per
connection. The fact it is a single process per connection can improve
scaling, but the IPC for page lock coordination has its overhead, and
the page cache per connection means more memory is necessary (and/or
smaller cache per connection), without the benefit of shared caching
(each connection will need to populate its own cache, and can't benefit
from things cached by a different connection).

SuperClassic is essentially single-process Classic (with threads instead
of processes). It has a page cache per connection, but as it is a single
process, the page lock coordination has less overhead, and it requires a
bit less memory as there is only one process.

See also
https://www.firebirdsql.org/file/documentation/reference_manuals/user_manuals/html/qsg25-classic-or-super.html

--
Mark Rotteveel