1

I'm working with the DFS Java API and was wondering whether anyone knows a simple way to configure a client-side timeout for service-calls that can be configured on the service context, for example?

I have experienced some rare occasions where a Documentum repository was not responding, that's why I am considering a general timeout for all DFS calls.

For testing a hanging service call, I created a dummy TBO implementation that simply blocks the thread for 10 minutes when updating the document:

@Override
 public void saveEx(boolean keepLock, String versionLabels) throws DfException {
  if (isNew() == false) {
    try {
      Thread.sleep(1000*60*10);
    } catch (InterruptedException e) {
      e.printStackTrace();
    }
  }
  super.saveEx(keepLock, versionLabels);
}

I'm not sure if this behaves exactly like a hanging service call, but at least in my tests it worked as expected - my invocations of the update method of the Object Service took about 10minutes.

Is there any configuration I have not yet found, or maybe a runtime-property to pass to the service context to configure the timeout?

I would prefer using existing features of DFS for this instead of implementing my own mechanism.

Florian Patzl
  • 174
  • 1
  • 13

1 Answers1

0

Have you tried editing the value in dfs-runtime.properties? I don't think the timeout can be context-specific, but you should be able to change it for the client as a whole.

Reposted from https://community.emc.com/message/3249#3249

"Please see the Server runtime startup settings section of the Deployment guide.

The following list describes the precedence that dfs-runtime.properties files take depending on their location:

  1. local-dfs‑runtime.properties file in the local classpath
  2. runtime properties file specified with ‑Ddfs.runtime.properties.file
  3. dfs‑runtime.properties packaged with emc‑dfs‑rt.jar

For example, settings in the local-dfs‑runtime.properties file on the local classpath will take precedence of identical settings in the dfs‑runtime.properties file that is located in emc‑dfs‑rt.jar or the one specified with the ‑D parameter. The DFS application must be restarted after any changes to the configuration. As a best practice, use the provided configuration file that is deployed in the emc‑dfs‑rt.jar file for your base settings and use an external file to override settings that you specifically wish to change."

Brendan Hannemann
  • 2,084
  • 1
  • 18
  • 33
  • Which specific value do you mean? I ran a quick test, setting _dfs.crs.cache_expiration_after_x_minutes_ to 4, in combination with setting _dfs.crs.perform_cleanup_every_x_minutes_ to 2, but that didn't change anything. Maybe these are the wrong parameters, or my changes weren't applied properly because of classpath issues, I'll have to check that again. However, your suggestion sounds like general session context timeout to me - is that correct? That would mean, when I run a series of service calls reusing the context, the timeout would apply to the sum of all calls, right? – Florian Patzl Feb 15 '13 at 09:49
  • I found this here: https://community.emc.com/message/367828. Try `dfs.crs.cache_expiration_after_x_minutes=60` and `dfs.crs.perform_cleanup_every_x_minutes=20` Otherwise you may have a classpath issue with your config. – Brendan Hannemann Feb 15 '13 at 17:04
  • Sorry, I never really continued dealing with this topic and now I no longer have access to an appropriate test system. – Florian Patzl Jul 02 '14 at 14:26