Commented by: Alice F. Bird (firebirds)

Date: 2006-05-04 18:43
Sender: arnobrinkman
Logged In: YES
user_id=393802

The cause is the procedure request handling, it's currently
under investigation.

Commented by: skaushanskiy (skaushanskiy)

This problem happens in FB 1.5.3 Super Server on WIndows as well,
we have not observed this problem under Linux :

STAN (Server) Thu Jun 15 09:15:42 2006
Database: E:\DATA.FDB
internal gds software consistency check (invalid SEND request (167))

Commented by: @dyemanov

Arno, any status update on this?

Commented by: skaushanskiy (skaushanskiy)

The same problem also happens in FB 2.0 RC2, and FB 2.0 RC3.
The same problem happens with FB 1.5.3 running Windows 2000 Server SP4.

It happens when I am simultaneously inserting large numbers of records into the same tables from 70+ concurrent clients.
these tables have UNIQUE constraints and "failures" to insert are normal.

I tried creating a test-case, but could not reproduce the issue.

This issue has never happened to me under linux.

My assumption is that it is a "threading" issue in the windows-server code.

Commented by: @pcisar

Two questions:

1. Isn't this related to CORE538 ?
2. Are you sure that this is not related to some issue with PHP connectivity library for Firebird/InterBase ? It's well known fact that PHP connectivity to Firebird is still problematic (although it's getting better). A test case that will not use PHP would be great.

Commented by: skaushanskiy (skaushanskiy)

1. No, in this issue, the FB server does not crash, it just throws BUGCHECKS and refuses requests for a few seconds,
then it comes back up and acts like nothing happened.

In CORE538 the FB server crashes but does not log anything, the guardian re-spawns the server, and FB acts like nothing happened.

So yes, they are very similar, but the symtoms are a little different, I actually prefer CORE538 because FB does not drop client connections
when the CORE538 crash occurs.

Commented by: skaushanskiy (skaushanskiy)

About problems with PHP connectivity,

This well known fact is not that well known, by me.

can you give me more details about this?
thanks,

stan

Commented by: skaushanskiy (skaushanskiy)

Ok,

I rewrote my code to use ibase.h and fbclient.dll directly in C/C++. The issue still occurs.
So it is not the PHP library for sure.

I will work on a reproducible test case as time permits.

So far my investigation suggests:

It happens under heavy load (65+ concurrent long-running write transactions from different clients).
It seems to happen when Each client is inserting data into about 8 tables and then updating the data that it just
inserted. The issue happens whether these inserts/updates are in the same or different transactions.

It happends if I use the default transaction parameters and if I specify READ_COMMITED|NO_RECORD_VERSION.

Again, this only happens under Windows.

thanks,

stan

Commented by: skaushanskiy (skaushanskiy)

Reproducible test case uses PHP 5.1.4 and Firebird 1.5.3. also happens under Firebird 2.0 RC 4.
This is also happening when using C++ and linking directly to fbclient.dll so This is not a PHP issue.

Commented by: skaushanskiy (skaushanskiy)

I have a reproducible test case.

It is attached.

let me know if you need anything else.

thanks,

stan

Commented by: skaushanskiy (skaushanskiy)

This seems to be fixed in a "duplicate issue":
CORE1080

this issue can be closed.

Commented by: @pcisar

It's a duplicate of fixed issue.

Commented by: @pcisar

Reopened to update ticket information.