Error: Failed to retrieve content from ACS/BOCS server(s).

We recently upgraded content server from 5.3 SP5 to SP6. After upgrade operation we are getting following error for view operation:

"Failed to retrieve content from ACS/BOCS server(s). The ACS/BOCS server(s) may be down or your machine may not be able to reach the server(s) due to network connectivity or configuration issues

com.documentum.ucf.common.UCFException: All remote hosts failed "

We want to use ACS server and I have checked that ACS server is running by using ACS URL. We are using SSL (https) for content transfer.

Anybody knows what causes this error? Also how do I know if I am using ACS or regular web server for content transfer?

Find more posts tagged with

Comments

tarh33l

Check the attribute "acs_base_url" in dm_acs_config and make sure it's correct (and that you can browse to that URL from the client which is trying to fetch content). Also, you can enable or disable ACS for your webapp by changing app.xml (details in the link below). By default, ACS is enabled (however, if DFC queries the repository and determines ACS is not enabled, it should fall back to the old method of transferring content through the app server)

Disable ACS

Terence

RaviJha

Hi,

You may want to try out the following:

1. Check if ACS status page is seen when you try to access the “Base URL” from the client machine.

Procedure:
Get the base URL from ACS config object (something like: http://<ACS_server_name>:<port>/ACS/servlet/ACS) and point the browser to that.

The status page may not be displayed because of the following reason:
ACS is not running
ACS machine is not reachable from the client.
You will need to make sure it is fixed.
Many a time, the client and ACS are in different domains.
Please try to specify a fully qualified ACS server name in the ACS URL and see if it resolves the issue.

2. If you get the ACS status page in 1, check the clocks on appserver machine and CS machine. If they are skewed up by more than 6 hours, try to synch them.

3. If both the above fail, please post a dump of ACS config, ACS log from CS, DFC log from the appserver and UCF client logs.

RaviJha

I just realized that I missed to answer the second part of the question.

The settings of "accelerated-read"/"accelerated-write" in app.xml, tell you whether you wish to use ACS for outbound/inbound operations or not.

But the reliable way to find out whether the content transfer is using ACS/BOCS or not is to look into UCF client logs if you are getting a ACS URL (like http://<hostname>:port/ACS/servlet/ACS/...) or not.

To enable UCF client logging go to %USERPROFILE%\Documentum\ucf\<hostname>\shared\config\ucf.client.logging.properties and set the logging level to ALL.

Message was edited by: Ravi Jha

Webster

Just had a similar problem to this and found this thread so I thought I would describe how I fixed it.

In the following we are using D6SP1 on AIX.

<host-name> is the host name of the content server (eg ppcsxx99)

<full-host-name> is the fully resolved hostname of the content server (eg ppcsxx99.proj.unix)

<alias-name> is an alias on the server - this is what we generally use to refer to the content server "host" (eg dmcsprod)

In dm_acs_config, the acs_base_url was set to "http://<alias-name>:9080/ACS/servlet/ACS"

Viewing the URL in a browser gave us an unresolved hostname error

We updated the acs_base_url to "http://<host-name>:9080/ACS/servlet/ACS"

Viewing this URL gave us a page not found error (better!)

We then finally updated the acs_base_url to "http://<full-host-name>:9080/ACS/servlet/ACS"

Viewing this URL gave us the ACS Running message - Fixed!

Hope this helps someone in the future

gordon.freeman

Check if the attribute "acs_base_url" in dm_acs_config has got "http://" in the beginning. I had the same issue because I forgot to put "http://" before hostname.