JVM freeze because of DfRegistryIniFile

Hello,

We encounter a major issue in our production environment with our application. This application is deployed on Websphere 7 and use DFC to make operations with Documentum. Sometimes (approx. twice a day), the JVM freeze because of Webcontainers waiting on com.documentum.registry.DfRegistryIniFile. When analysing the stack trace of a Webcontainer during the freeze, we can see that the reset() method of the DfRegistryIniFile is called just after the long wait time.

When it happens, we have to restart the JVM for the application to be available again. Then, everything is working fine until the next time it happens.

Any help would be greatly appreciated.

Regards,

Fabien.

report_2011-10-11_17-19-40.xls

stacktrace.docx

Find more posts tagged with

Comments

Atom

It is public synchronized method.
Probably, some of the threads locks the file ( in dfc.properties ) and does not release. There is a deadlock.You can watch the resources that use java threads and post to support.I think this is a bug of dfc. Do you have a AIX system ?

The file in dfc.properties is

dfc.registry.file = ${dfc.data.user_dir}/documentum.ini

Maybe you can help change the parameter in dfc.properties

dfc.relationship.schema_expiration_interval =

MancinoF

Thank you Atom. Our system is a Windows 2008 64bits server. We tried to change the dfc.registry.mode parameter from "file" to "windows" but it doesn't seem to works on 64bits system

I don't understand how the dfc.relationship.schema_expiration_interval parameter can be helpful regarding my problem. This value is not set in our dfc.properties for the moment.

We tried to change the documentum.ini file while the JVM was freezing and we can do it successfully. It means the file is not locked by another process.

Sometimes, when messages below appear in Websphere log after we restarted the JVM. When it happens, we have to delete the documentum.ini file and restart the JVM again to make the application available:

Caused by: com.emc.documentum.fs.services.core.CoreServiceException: DfException:: THREAD: WebContainer : 7; MSG: Invalid entry format in registry file. Symbol = is absent. String is ?[documentum]; ERRORCODE: 0; NEXT: null

at com.emc.documentum.fs.services.impl.ActionsFacade.performExecution(ActionsFacade.java:208)

at com.emc.documentum.fs.services.impl.ActionsFacade.execute(ActionsFacade.java:55)

at com.emc.documentum.fs.services.core.impl.result.ContentLoader.handle(ContentLoader.java:212)

at com.emc.documentum.fs.services.core.impl.result.ContentLoader.loadPageContent(ContentLoader.java:125)

... 73 more

Caused by: DfException:: THREAD: WebContainer : 7; MSG: Invalid entry format in registry file. Symbol = is absent. String is ?[documentum]; ERRORCODE: 0; NEXT: null

at com.documentum.fc.impl.util.DfRegistryParser.processEntryLine(DfRegistryParser.java:52)

at com.documentum.fc.impl.util.DfRegistryParser.process(DfRegistryParser.java:42)

at com.documentum.registry.DfRegistrySnapshot.<init>(DfRegistrySnapshot.java:38)

at com.documentum.registry.DfRegistryIniFile.reloadSnapshot(DfRegistryIniFile.java:506)

at com.documentum.registry.DfRegistryIniFile.<init>(DfRegistryIniFile.java:58)

Atom

I don't understand how the dfc.relationship.schema_expiration_interval parameter can be helpful regarding my problem. This value is not set in our dfc.properties for the moment.

I'm sorry. I was mistaken.

We tried to change the documentum.ini file while the JVM was freezing and we can do it successfully. It means the file is not locked by another process.

Hm... May be threads are blocked forever ? Then JStack and JConsole help to you.