Unsolved
This post is more than 5 years old
1 Rookie
•
11 Posts
0
7341
January 28th, 2011 11:00
FPPool - is it designed to stay open?
We have an application that uses the Centera API where we open an FPPool, then the Clip, etc, and when we're done uploading a document (or retrieving a doc), we then close all the objects, including the FPPool. That works ok, but if our backup Centera node goes down (power outage for instance), then all calls into this function are ~really~ slow. Someone at EMC who was not familiar with the API (they haven't found us anyone who is yet), said that ~maybe~ the Pool should stay open since the slowness is probably from the Pool trying to open and pinging the backup node which is down. If the pool were already open, it would not do this and would be quicker. That's the theory. Does anyone have experience with this to know for sure if it is correct? And if so, as a side note, when should the Pool be closed then? Or will the GC clean it up once it's been idle long enough?
TIA
-VG
vgmni
1 Rookie
•
11 Posts
0
January 31st, 2011 07:00
Hello Graham. Thank you for your reply. Have you implemented a solution with the FPPool staying open then? When I look at the Centera API documentation, all of their code examples show the pool getting closed right away, and even the FPPool Close method says "Note: Be sure to close all pool connections that are no longer needed in order to avoid performance loss and resource leakage.". So that is why we have been hesitant. Can you tell us what type of architecture you use to keep your FPPool open? Web Service, Windows Service, etc? And if there is a time to close the pool, how do you do that? What we have tried on our test environment is a web service where we never close the pool ever, but I am concerned about a memory leak if the IIS Application Pool recycles and the handle to the FPPool is lost but it is not closed. But from what I can tell, the pool re-creates itself (I log to the db every time it does) approx. every 30 mins if there is no activity (on test), so I'm not sure if the Garbage Collector is cleaning it up and that is sufficient? What are your thoughts on that?
Thanks!
-VG
gstuartemc
2 Intern
•
417 Posts
0
January 31st, 2011 07:00
The sample code demonstrates primitive fundamental operations so should not be viewed as typical production applications (especially as the error handling is very basic).
I have been involved with literally hundreds of integrated applications and there are many ways to handle a single pool connection. The most elegant is to make use of a singleton class, and if you are using an object oriented language then this is most certainly the way to go.
A pool connection is essentially just a collection of sockets and some status information. It will not need to be "recycled" unless there are problems with the connection, and even then it can often "survive" these when the connectivity returns to normal. If the cluster has to be shut down then the connection would certainly need to be re-established when it came back up.
Any form of garbage collection is entirely under the control of the application / OS, the internals of the Centera SDK will cause such objects to be created or deleted.
gstuartemc
2 Intern
•
417 Posts
0
January 31st, 2011 07:00
The pool connectionm should be kept open, reused by all the threads of the application, and closed only when your interaction with the cluster is complete or the application needs to shut down. Opening and closing the pool connection frequently is guaranteed to give poor performance.
The only time a new pool connection should be created is when their has been a communications / network failure that has caused it to become invalid.