empty FBTableStatisticsManager.getTableStatistics() return

[EPluribusUnum]

Hi Mark!

getTableStatistics() result is not reliable, it returns empty
TableStatisticsProcessor.process sometimes gets just a single byte array as an input : [2] (isc_info_truncated).
Is this a Jaybird, or a Firebird server issue? Is there a some kind of restriction or prerequisite for getTableStatistics() to work?

Thank you!

[mrotteveel]

A reproducible case would be helpful, including Firebird version and the total number of tables in the database. If you get a isc_info_truncated reply, then either Jaybird calculated the "wrong" size, or it is a server problem, or maybe there are too many tables and too many counts, so they don't fit in the (maximum) info request reply size.

[EPluribusUnum]

Found the issue.
A singel instance of FBTableStatisticsManager must be used during the whole Connection lifetime, can't create new instance for every statistics request.

[mrotteveel]

Using multiple FBStatisticsManager instances on the same connection should work, but would have more overhead than using a single instance (as it will query for a list of all tables for each new instance).

Looking at the code, the only way I can think of using multiple instances could result in a isc_info_truncated reply, is if tables are dropped between the first instance and the second instance, because I guess that Firebird might still retain the statistics of the dropped table. I'm going to see if I can reproduce it and somehow address that (e.g. maybe use some slack for table count, and increase that if a truncated reply is received and query again).

Could your application be actively dropping tables?

[EPluribusUnum]

No table drop. There are 1221 tables in the database (sys tables not included)
Tried with Firebird 3.0.10 and Firebird 4.0.0
Jaybird 5.0.1.java8

[mrotteveel]

I wrote a test, and it does reproduce it if I drop a table that has statistics between the first instance and the second instance, but I'm not yet sure what might cause it; I'll dig deeper.

[mrotteveel]

The problem does not have to do with the table drop.

• The first time statistics are created, it calculates the buffer size as 25, and it reports the data on two tables (at least, in my test case), and then gives isc_info_truncated
• Because the response had one or more tables, it has requested the tables available in the database, so subsequent requests allocate sufficient space.
• For some reason (maybe more statistics items exist for a single table), when a second request is done with buffer size 25, no table data fits in that space, and it will report isc_info_truncated immediately, and given no tables were requested, no tables are queried, and subsequent requests fail as well because insufficient space was requested.

I guess I need to request available tables immediately when the map is empty, instead of lazily doing it later, and maybe add some extra handling if truncation is reported anyway.

[mrotteveel]

Fix is part of Jaybird 5.0.2 (and Jaybird 6). If you want, you can check the snapshots on the Sonatype OSS Maven snapshot repository (https://oss.sonatype.org/content/repositories/snapshots)

[EPluribusUnum]

@mrotteveel : tested, looks fine, thank you!