We are experiencing some issues using the SDK via the Java FPLibary. After around 100,000 documents read from the CAS, all threads become blocked waiting on FPClip_Open requiring us to restart the JVM.
public byte[] readFile(CasConfig.POOL pool, String casId) {
FPPool connection = null;
FPClip clip = null;
FPTag tag = null;
ByteArrayOutputStream outputStream = null;
try {
connection = getConnect(pool);
outputStream = new ByteArrayOutputStream();
clip = openFpClip(connection, casId);
tag = clip.getTopTag();
tag.BlobRead(outputStream);
return outputStream.toByteArray();
} catch (Exception e) {
log.error("Error from CAS. Reading CAS ID {}", casId, e);
try {
connection.Close();
} catch (FPLibraryException e1) {
}
connectionPool.remove(pool);
throw new RuntimeException("Could not read from CAS: " + e.getMessage(), e);
Is there a reason you are invalidating the FPPool instance if you get an error? I'm pretty sure that connection.Close() call will fail if there are any open clips at the point of that call, which may be related to your issue if you are hitting errors with any frequency.
Best choice would be to simply open a single FPPool and leave it open for the complete lifetime of the system; our migration system often sees singleton FPPool lifetimes measured in weeks, with billions of successful SDK transactions across dozens of concurrent threads.
mfh2
208 Posts
1441
0
Posted December 15th, 2017 06:00
Hi Dan -
Is there a reason you are invalidating the FPPool instance if you get an error? I'm pretty sure that connection.Close() call will fail if there are any open clips at the point of that call, which may be related to your issue if you are hitting errors with any frequency.
Best choice would be to simply open a single FPPool and leave it open for the complete lifetime of the system; our migration system often sees singleton FPPool lifetimes measured in weeks, with billions of successful SDK transactions across dozens of concurrent threads.
Keep us posted on your findings.
Best Regards,
Mike Horgan