An RdbmsCatalogue iterator should return its underlying database connection when the last row has been fetched
The RdbmsCatalogue
gives the caller of its API an iterator object when they need to walk through a large data set. There are currently threes Rdbms
iterator classes:
[itctabuild02] ~ > ls CTA/catalogue/Rdbms*Itor.hpp | cat
CTA/catalogue/RdbmsCatalogueGetArchiveFilesForRepackItor.hpp
CTA/catalogue/RdbmsCatalogueGetArchiveFilesItor.hpp
CTA/catalogue/RdbmsCatalogueGetDeletedArchiveFilesItor.hpp
[itctabuild02] ~ >
All three iterators get a connection the database, execute a select statement and then call "next" on the result set until all rows have been retrieved. The connection is returned to the connection pool when the iterator object is deleted/destroyed.
A long time may pass between the last row being fetched and the iterator object in question being deleted/destroyed. Connection pools by design have a finite size. The connection pool used by the CTA frontend to list archive files has a maximum size of just 2 connections. If for any reason the streaming logic of the cta-admin archivefile ls
or the cta-admin tapefile ls
commands postpone deleting their iterators then future executions of these commands will freeze.
The iterators of the RdbmsCatalogue
should be modified so that they return their database connections to their respective pools as soon as the last row has been fetched from their result sets. The iterators should *NOT wait until they have been deleted.