I have some Java service code in production (not written by me!) that does something similar to:
IDataCursor cursor = pipeline.getCursor();
# do something with cursor
cursor.destroy();
cursor.next();
String key = cursor.getKey();
String value = cursor.getString();
# and so on.
So, it works with an IDataCursor that has been returned to the pool using the destroy() method.
The service works fine on a lightly loaded system, and appears to work most of the time on our production system, but hangs at arbitrary times. That makes sense to me - some other service gets the cursor from the pool, now two services are sharing the same cursor - some very specific timing occurs that causes the service to hang.
To satisfy my management though, I need to reproduce the hang on a development system. It seems to me that the surest way to do this is to reduce the size of the cursor pool, so the destroyed cursor is more likely to get reused.
Does anyone know a way to do this (or have some other suggestion)
I don’t think there is something called Cursor pool. The cursor belongs to the pipeline object. each pipeline should be isolated from each other. there shouldn’t be a chance that the cursor can be reused accross.
Do you have more info on the hanging situation?
The reason I thought there was a pool is this from the API docs:
So hypothetically there’s a CursorFactory that maintains a cache, and pipeline.getCursor() fetches a cursor from the cache, and sets it up with the appropriate IData object. I can’t imagine why a cursor object is heavyweight enough to warrant cacheing though!
Bear in mind that you can have as many independent cursors to the same IData as you like, so it’s not as if an IData “has a” single cursor that you obtain using getCursor().
My managers are no longer asking for a recreation of the problem, and we’ve put in new code that doesn’t use a destroy()ed cursor, so I’m happy.