FPClip.open() seems to hang never return

Hi,

we are using the centera java sdk for 3 years without any problems. For a few weeks we have the problem that the "new FPClip(pool, clipId, FPLibraryConstants.FP_OPEN_FLAT);" function seems to hang and never return to the caller. We had nothing changed and the last centera update was in the middle of 2009.

Centera Version: Version 4.0.2-3195-1019-20652

SDK-Version: 3.2.P3 (3.2.661)

We have follow request cycle:

1. First we write a Clip with one File (Document). (clip.write())

2. After writing we imediately open the clip (new FPClip(pool, clipId, FPLibraryConstants.FP_OPEN_FLAT);) to check if the data were written successfully but this call will never return and hangs. But other parallel incomming request are processed. Only a restart of the JVM helps.

It is always the same point were the requets hangs. Writing the clip and imediately open the clip without waiting long time (it happens in the same second)

Are there any problems knwon like this. We do not know what happens. But this problem blocks our other process that write the documents to the centera.

Please help.

Responses(3)

mfh2

208 Posts

0

October 13th, 2011 14:00

Hello Carsten -

SInce this is a coding-related question you may get more eyeballs on your question in the Centera SDK forum: https://community.emc.com/community/edn/centera/centerasdk?view=discussions

One thing that springs to mind for me are the CDF 'swap files' that are created in your TEMP directory when CDFs greater than the default buffer size of 16KB are opened. Do your clips have embedded blobs? If so you should increase your CDF BUFFER_SIZE setting to 150KB or so.

Though your code and your CentraStar revisions may be unchanged, the nature of the data your application is seeing may be shifting over time which can cause previously unseen bugs to surface.

Using SDK logging (described in the SDK documentation) may also help track down this problem, although if you have a busy application the logs can quickly grow to large sizes.

Best of Luck,

Mike Horgan

carsten_schulz1

2 Posts

0

October 26th, 2011 01:00

Hi,

thanks for the quick answer. So now I have 3 questions.

How can I set the CDF Buffer Size. I did not found anything in the Programming Guide. Have I to set this at client side?
I activated the API Logging. But per default this file grows until 1GB and then the next file is being created. And 1GB is reached very fast. But we have the problem that this "error" did not occur at every request but our import process runs some time (maybe hours or days) and eventually the process hangs at the described position. Is there a posibility to shrink the size when a new log will be created (e.g. to 100MB). A 1GB Log is difficult to open by the most text editors.
Where can I found the CDF swap files. Are there at client side or have I to look at the server. At server side we have no access.

Thanks.

mfh2

208 Posts

0

October 27th, 2011 13:00

Hi Carsten -

This thread has good info on the CDF buffer option (thanks jblank for pointing this out): https://community.emc.com/thread/2621

FP_LOG_STATE_PATH can give fine-grained control over the logging configuration including log size and rollover behavior. See the 'Logging' section of the SDK 3.2 Programmer's Guide. BTW, you might consider upgrading to the current SDK 3.2 version (3.2.705).

The CDF swap files are created in the TEMP dir defined for the process that is loading the SDK libraries. If you are running on a Windows host it is fairly easy to monitor their creation with Resource Monitor or Sysinternal's Process Monitor.

Good luck with your investigation,

Mike H.

View All

No Events found!