Documentum's Java Based software uses Log4j architecture to manager logging. The different levels of logging provided by log4j architecture are the following:
OFF - The OFF has the highest possible rank and is intended to turn off logging.
FATAL - The FATAL level designates very severe error events that will presumably lead the application to abort.
ERROR - The ERROR level designates error events that might still allow the application to continue running.
WARN - The WARN level designates potentially harmful situations.
INFO - The INFO level designates informational messages that highlight the progress of the application at coarse-grained level.
DEBUG - The DEBUG Level designates fine-grained informational events that are most useful to debug an application.
ALL - The ALL has the lowest possible rank and is intended to turn on all logging.
Thursday, March 27, 2008
Friday, March 21, 2008
Wednesday, March 19, 2008
Thursday, March 13, 2008
UCF Related Threads
- Stuck threads in InitGAIRConnector UCF servlet:
- Customer wants the InitGAIRServlet to timeout after a configurable amount of time if it has not received a request from the application
- Users randomly get java.lang.NullPointerException and java.util.ConcurrentModificationException in Webtop
- Receiving java.lang.NullPointerException when trying to view a document under the following circumstances:
- User has READ permits to the latest version to a doc
- User has NONE permits to CURRENT version of doc
- User tries to view the latest version - Thread: Error while viewing document in webtop
- Thread: UCF and Firewall
- Thread: Operation failed : Failed to obtain UCF session
- Intermitten UCF error
- Webtop 5.3 SP6[5.3.0.613] Importing an XML document hangs and throws 'java.lang.IllegalStateException: Timed out requesting input'
- UcfSessionManager NonBlockingCleanup
- Client failed to handshake with server within 250 seconds.
- UCF Error
- UCFException when importing document: Failed to skip attachment stream
- UCF House Keeping
- Stuck Threads webtop/com/documentum/ucf/server/transport/impl/GAIRConne
- Logs to collect for UCF problems
- UCF Transport error
- Pre-installing UCF
- UCF runtime problem with failed to connect to server error
- UCF thows java.net.SocketException: Connection reset if passing through a load balancer or firewall
- Why do I get java.io.EOFException while doing UCF operation like viewing file
- UCF is not obeying the proxy configuration
- JRE requirements for UCF client deployment.
Wednesday, March 5, 2008
How can I turn off certificate validation on the client?
How can I turn off certificate validation on the client?
The following configuration works only for WDK-based application versions 5.3 SP2 and later.
Configuring non-server validation mode
In non-server validation mode,UCF will override the Java default implementation of Trust Manager to allow
UCF client to automatically trust certificates used for SSL authentication. Modify ucf.installer.config.xml, which is located in /wdk/contentXfer in your installed WDK application.. Add the following option within the <configuration> element:
<option name="https.host.validation" persistent="false">
<value>false</value>
</option>
Note, you can add the above following the line <option name="file.poll.interval" value="60" /> under <configuration> element:
This configuration will tell the browser client to not validate the SSL certificate on the client side. This can be useful for self-signed SSL certificates.
The following configuration works only for WDK-based application versions 5.3 SP2 and later.
Configuring non-server validation mode
In non-server validation mode,UCF will override the Java default implementation of Trust Manager to allow
UCF client to automatically trust certificates used for SSL authentication. Modify ucf.installer.config.xml, which is located in /wdk/contentXfer in your installed WDK application.. Add the following option within the <configuration> element:
<option name="https.host.validation" persistent="false">
<value>false</value>
</option>
Note, you can add the above following the line <option name="file.poll.interval" value="60" /> under <configuration> element:
This configuration will tell the browser client to not validate the SSL certificate on the client side. This can be useful for self-signed SSL certificates.
Performing a content transfer operation is generating the error "failed to skip attachment stream".
Symptoms:
Performing a content transfer operation results in the following exception for specific formats:
An error has occurred. invokeMethod()failed while calling:OnReturnFromProgress Operation failed:com.documentum.ucf.common.contentregistry.RegistryException:failed to skip attachment stream com.documentum.ucf.common.contentregistry.RegistryException:failed to skip attachment stream
Cause:
UCF will compress content files during content transfer for all file types unless they have been explicitly excluded from compression. The above exception can be a sign that content decompression has encountered an error.
Resolution:
For the WDK-based web application, open the file\WEB-INF\classes\ucf.server.config.xml. Locate the
Performing a content transfer operation results in the following exception for specific formats:
An error has occurred. invokeMethod()failed while calling:OnReturnFromProgress Operation failed:com.documentum.ucf.common.contentregistry.RegistryException:failed to skip attachment stream com.documentum.ucf.common.contentregistry.RegistryException:failed to skip attachment stream
Cause:
UCF will compress content files during content transfer for all file types unless they have been explicitly excluded from compression. The above exception can be a sign that content decompression has encountered an error.
Resolution:
For the WDK-based web application, open the file
Logs to collect for UCF problems
Symptoms:
UCF errors prevent users from running content transfer.
Cause:
UCF communication is a very complex process. Since it passes through multiple network devices, there are many reasons that may cause this process to fail. To determine what is the exact cause of the problem, a complete set of logs and the network traffic data is are necessary. Network traffic data reveals complete data and messages between the UCF client and the server, including the network devices that may inject additional data into the communication channel. That information is not revealed by the trace logs.
Resolution:
There are common solutions for the UCF problems: For example, removing the UCF folder in client workstation and cleaning the IE cache and disabling ACS in wdk/app.xml. But sometimes these steps could not fix the problem. The following logs are needed to provide to Engineering for troubleshooting:
On the App Server side:
Open file/WEB-INF/classes/ucf.server.config.xml, change the option "tracing.enabled" from false to true. The App server must be recycled during scheduled maintanence hours for this option to take effect.
On the client side:
- Close all browser windows.
- Open C:\Documents and Settings\\Documentum\ucf\\shared\config\ucf.client.config.xml, change the option "tracing.enabled" from false to true.
- Open C:\Documents and Settings\\Documentum\ucf\\shared\config\ucf.client.logging.properties, change the line ".level=WARNING" to ".level=ALL"
- Under C:\Documentum\Logs, remove files named ucf.*
- Launch a new browser instance.
- Log into Webtop.
- In the browser window, launch Java Console from its Tools menu, and in the console window press key 5.
- In browser window, press ctrl+N to open a new window.
- In the new browser window, access: http://host:port/webtop/wdk/tracing.jsp, and check the following options "HTTP_MANAGER", "UCF_MANAGER", "Tracing is enabled for current session".
- Launch Ethereal or Wireshart (network sniffer) and start to capture all the network traffic between this client workstation and the web server/app server.
- In the first browser window, reproduce the problem.
- Record the time the problem takes to be reproduced and see if there is any time difference between the client workstation's clock and the web server/app server machine's clock.
- Collect the log files under C:\Documentum\Logs
- Collect the traces in Java Console.
- Collect the network traffic data file generated by Ethereal/Wireshark.
Download from http://www.wireshark.org/download.html.
Put the filter as tcp port xxxx or host ipaddress to capture all the traffic.
On the Web Server/App server side:
- Collect the wdk.log* and trace.log* under $DOCUMENTUM_SHARED
- Collect the web server logs.
- Collect the app server logs.
UCF errors prevent users from running content transfer.
Cause:
UCF communication is a very complex process. Since it passes through multiple network devices, there are many reasons that may cause this process to fail. To determine what is the exact cause of the problem, a complete set of logs and the network traffic data is are necessary. Network traffic data reveals complete data and messages between the UCF client and the server, including the network devices that may inject additional data into the communication channel. That information is not revealed by the trace logs.
Resolution:
There are common solutions for the UCF problems: For example, removing the UCF folder in client workstation and cleaning the IE cache and disabling ACS in wdk/app.xml. But sometimes these steps could not fix the problem. The following logs are needed to provide to Engineering for troubleshooting:
On the App Server side:
Open file
On the client side:
- Close all browser windows.
- Open C:\Documents and Settings\
- Open C:\Documents and Settings\
- Under C:\Documentum\Logs, remove files named ucf.*
- Launch a new browser instance.
- Log into Webtop.
- In the browser window, launch Java Console from its Tools menu, and in the console window press key 5.
- In browser window, press ctrl+N to open a new window.
- In the new browser window, access: http://host:port/webtop/wdk/tracing.jsp, and check the following options "HTTP_MANAGER", "UCF_MANAGER", "Tracing is enabled for current session".
- Launch Ethereal or Wireshart (network sniffer) and start to capture all the network traffic between this client workstation and the web server/app server.
- In the first browser window, reproduce the problem.
- Record the time the problem takes to be reproduced and see if there is any time difference between the client workstation's clock and the web server/app server machine's clock.
- Collect the log files under C:\Documentum\Logs
- Collect the traces in Java Console.
- Collect the network traffic data file generated by Ethereal/Wireshark.
Download from http://www.wireshark.org/download.html.
Put the filter as tcp port xxxx or host ipaddress to capture all the traffic.
On the Web Server/App server side:
- Collect the wdk.log* and trace.log* under $DOCUMENTUM_SHARED
- Collect the web server logs.
- Collect the app server logs.
EMC Technical Support Policy regarding third party load balancer vs UCF
UCF-based content transfer activities (import, export, check in/out) breaks when a third party load balancer product is placed between the browser and the application server that hosts the WDK application. However, if the browser is used to connect to the application server directly, bypassing the load balancer, UCF activities go through without a problem.
Cause:
Incompatibility or misconfiguration of the third party load balancer causes UCF activities to fail.
Cause:
Incompatibility or misconfiguration of the third party load balancer causes UCF activities to fail.
Subscribe to:
Posts (Atom)