Hello,

Documentum proposes the Java method server as a means of improving the performance and scalability of its method architecture, indeed, it is possible to execute custom code on behalf of the Content Server via Documentum methods written in Java or DocBasic.
 
 
Presentation of Java Method Server
The method server itself is a Java-based web application communicating with the Content Server via HTTP calls. Each time a method is invoked, the Content Server makes an HTTP request passing the name of the Java class which implements the method along with any specified arguments to a servlet which knows how to execute the specified method. Methods in documentum are defined via dm_method objects. To indicate that a Java method should execute via the Java method server, set the dm_method.method_type attribute to java, the dm_method.use_method_server attribute to 1, and the dm_method.method_verb attribute to the classname of the method implemenation. When the Content Server sees a method matching this pattern, it opens a HTTP request to the Java method server requesting executing of the method with the specified class. This simple architecture solves the overhead problem and also introduces a convenient mechanism for dramatically improving the scalability of the Content Server. Although it is not configured out-of-the-box to support this, Method servers may be executed on a machine physically separate from the Content Server. It is even possible to run the method server on a platform different from the Content Server (ie. running the Content Server on Solaris and the method server on Windows). This offloads work from the Content Server which might enable the Content Server to handle more users. If the methods are expensive to execute, it is also possible to load-balance method servers using industry standard HTTP load balancers. There is nothing special or complicated about the method server. It simply requires a J2EE-compatible servlet container.

 
 
Starting / State / Stopping of Java Method Server
Sometimes, the “java.lang.Exception: Application Server test failed” error occurs during the starting of JMS. In Windows, there are the standard Windows Services allowing the starting and stopping of JMS. However before any action, it is advised to probe the following URL of the JMS because the Windows services do not reflect the real state of JMS.
 
app_server_uri = http://[DCTM_JBOSS_SERVER]:9080/DmMethods/servlet/DoMethod

 

In DCTM 6.5, there is a known issue concerning the restarting of JMS via the WINDOWS service for which the above support note was written. It states that there is a BATCH dctmServerStatus.bat allowing Content Server to check if the JMS is UP or DOWN via port 9084. Therefore, the error message may be due to a wrong config when using this BATCH tool in the DmMethodServer.xml file.


Symptoms
Java Method Server fails to start while started as a Windows Service but is starting correctly using [DOCUMENTUM]\jboss4.2.0\server\startMethodServer.cmd

The [DOCUMENTUM]\jboss4.2.0\server\serviceConfig\MethodServer\DmMethodServerService.log is showing "java.lang.Exception: Application Server test failed"

Cause
The root cause could be multiple and the purpose of this Support Note is to help investigating where the problem relies by looking at more meaningful logs.

Resolution
The Windows Service relies on 2 files: wrapper.conf and DmMethodServer.xml (both found on [DOCUMENTUM]\jboss4.2.0\server\serviceConfig\MethodServer\conf).
First suggestion is to check those files for any wrong setting (path, hostname).

In order to determine that the Windows Service is started correctly after startup sequence is initiated, the Service Wrapper issues the command described by status node on DmMethodServer.xml: dctmServerStatus.bat vm4425 9084 MethodServer.
This status command generates log files that should be of interest: twiddle.log and [HOSTNAME]_9084_status_output.txt (both found on [DOCUMENTUM]\jboss4.2.0\bin).
Those logs should contain a more explicit Java stack trace that would help understand the current issue ("java.net.UnknownHostException: VM4425: VM4425" for example).


 

For your information, the binding port 9083 is defined in [DOCUMENTUM_FOLDER]\jboss4.2.0\server\DctmServer_MethodServer\conf\jboss-service.xml file:

   <!-- ==================================================================== -->
   <!-- Class Loading                                                        -->
   <!-- ==================================================================== -->

   <!-- A mini webserver used for dynamic and class and resource loading --> 
   <mbean code="org.jboss.web.WebService"
      name="jboss:service=WebService">
      <!-- The Bind address and Port -->
      <attribute name="BindAddress">${jboss.bind.address}</attribute>      
      <attribute name="Port">9083</attribute>
      <!--  The address to use for the host portion of the RMI codebase URL -->
      <attribute name="Host">${java.rmi.server.hostname}</attribute>
      <!-- Should non-EJB .class files be downloadable -->
      <attribute name="DownloadServerClasses">true</attribute>
      <!-- Should resources other than .class files be downloadable. Both
         DownloadServerClasses and DownloadResources must be true for resources
         to be downloadable. This is false by default because its generally a
         bad idea as server configuration files that container security
         information can be accessed.
       -->
      <attribute name="DownloadResources">false</attribute>

      <!-- Use the default thread pool for dynamic classa loading -->
      <depends optional-attribute-name="ThreadPool"
         proxy-type="attribute">jboss.system:service=ThreadPool</depends>
   </mbean>

 
 
More Explanations
In fact in DCTM 6.5, the problem with starting the Java Method Server (JMS) WINDOWS service is that it is unable to map port 9083, because during the shutdown of the Windows service (during the stop), the associated java (java.exe) process has not been stopped, so the port is always used.
 
This problem should be resolved in DCTM 7.2 because the version of the wrapper service – the tool that creates the Windows service associated with the Java Method Server – is no longer the same;
 
More, in addition to use of dctmServerStatus.bat and/or checking of http://[DCTM_JBOSS_SERVER]:9080/DmMethods/servlet/DoMethod, another solution (in sequencing) would be to “kill” of java processes (there are 2) when shutting down the JMS (relatively laborious solution, because it will be necessary to retrieve the PID of the good java processes to avoid killer other java processes that have nothing to do, and under windows it is not as trivial as in Unix environment).
 
 

Test with DCTM 6.5
The DmMethodServer.xml contains:
dctmServerStatus.bat MYSERVERDCTM 9084 MethodServer
http://MYSERVERDCTM:9080

<wrapperService displayName="Documentum Java Method Server" name="DmMethodServer" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="wrapperService.xsd" startsOtherServices="true">
    <component name="Application Server" >
        <start timeout="1200" commandReturns="false" executionDir="C:\Documentum\jboss4.2.0\server">startMethodServer.cmd</start>
        <status timeout="60" executionDir="C:\Documentum\jboss4.2.0\bin">dctmServerStatus.bat MYSERVERDCTM 9084 MethodServer</status>
        <stop timeout="600" executionDir="C:\Documentum\jboss4.2.0\server">stopMethodServer.cmd</stop>
        <heartbeat>
		<url>http://MYSERVERDCTM:9080</url>
        </heartbeat>
    </component>
</wrapperService>     

…execution of dctmServerStatus.bat MYSERVERDCTM 9084 MethodServer command:

…the previous command produces a TXT file containing the result : true or false:

twiddle.log

17:13:05,975 DEBUG [Twiddle] args[0]=--server
17:13:05,975 DEBUG [Twiddle] args[1]=MYSERVER:9084
17:13:05,975 DEBUG [Twiddle] args[2]=-u
17:13:05,975 DEBUG [Twiddle] args[3]=admin
17:13:05,975 DEBUG [Twiddle] args[4]=-p
17:13:05,975 DEBUG [Twiddle] args[5]=admin
17:13:05,975 DEBUG [Twiddle] args[6]=get
17:13:05,975 DEBUG [Twiddle] args[7]=--noprefix
17:13:05,975 DEBUG [Twiddle] args[8]=jboss.system:type=Server
17:13:05,975 DEBUG [Twiddle] args[9]=Started
17:13:05,991 DEBUG [SecurityAssociation] Using ThreadLocal: false
17:13:05,991 DEBUG [Twiddle] Command name: get
17:13:05,991 DEBUG [Twiddle] Command arguments: --noprefix,jboss.system:type=Server,Started
17:13:05,991 DEBUG [Twiddle] command proto type properties: jar:file:/C:/Documentum/jboss4.2.0/bin/twiddle.jar!/org/jboss/console/twiddle/commands.properties
17:13:05,991 DEBUG [Twiddle] Adding command 'jsr77'; proto: org.jboss.console.twiddle.command.JSR77Command@df8f5e
17:13:05,991 DEBUG [Twiddle] Adding command 'xmbean'; proto: org.jboss.console.twiddle.command.XMBeanCommand@1bca5f1
17:13:06,007 DEBUG [Twiddle] Adding command 'info'; proto: org.jboss.console.twiddle.command.InfoCommand@1749757
17:13:06,007 DEBUG [Twiddle] Adding command 'get'; proto: org.jboss.console.twiddle.command.GetCommand@147ee05
17:13:06,007 DEBUG [Twiddle] Adding command 'invoke'; proto: org.jboss.console.twiddle.command.InvokeCommand@1fcf0ce
17:13:06,007 DEBUG [Twiddle] Adding command 'create'; proto: org.jboss.console.twiddle.command.CreateCommand@82701e
17:13:06,007 DEBUG [Twiddle] Adding command 'setattrs'; proto: org.jboss.console.twiddle.command.SetAttrsCommand@19a0c7c
17:13:06,007 DEBUG [Twiddle] Adding command 'unregister'; proto: org.jboss.console.twiddle.command.UnregisterCommand@145e044
17:13:06,007 DEBUG [Twiddle] Adding command 'query'; proto: org.jboss.console.twiddle.command.QueryCommand@17e6a96
17:13:06,007 DEBUG [Twiddle] Adding command 'set'; proto: org.jboss.console.twiddle.command.SetCommand@1960f05
17:13:06,007 DEBUG [Twiddle] Adding command 'serverinfo'; proto: org.jboss.console.twiddle.command.ServerInfoCommand@e5b723
17:13:06,007 DEBUG [GetCommand] processing arguments: --noprefix,jboss.system:type=Server,Started
17:13:06,007 DEBUG [GetCommand] mbean name: jboss.system:type=Server
17:13:06,007 DEBUG [GetCommand] adding attribute name: Started
17:13:06,007 DEBUG [GetCommand] attribute names: [Started]
17:13:06,163 DEBUG [GetCommand] as string[]: Started
17:13:06,225 DEBUG [GetCommand] attribute list: [javax.management.Attribute@19e15c]

…the last URL http://MYSERVERDCTM:9080 is the JBOSS application server hosting the JMS:

 
 
 

Test with DCTM 7.2
The DmMethodServer.xml contains:
dctmServerStatus.bat MYSERVERDCTM2 9084
http://MYSERVERDCTM2:9080

<wrapperService displayName="Documentum Java Method Server" name="DmMethodServer" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="wrapperService.xsd" startsOtherServices="true">
    <component name="Application Server" >
        <start timeout="1200" commandReturns="false" executionDir="D:\Documentum\jboss7.1.1\server">startMethodServer.cmd</start>
        <status timeout="60" executionDir="D:\Documentum\jboss7.1.1\bin">dctmServerStatus.bat MYSERVERDCTM2 9084</status>
        <stop timeout="600" executionDir="D:\Documentum\jboss7.1.1\server">stopMethodServer.cmd</stop>
        <heartbeat>
		<url>http://MYSERVERDCTM2:9080</url>
        </heartbeat>
    </component>
</wrapperService>     

…execution of dctmServerStatus.bat MYSERVERDCTM2 9084 command:

…the previous command produces a TXT file containing the result : true or false:

…the last URL http://MYSERVERDCTM2:9080 is the JBOSS application server hosting the JMS:

 
 
 

Resources:
http://www.bluefishgroup.com/2004/the-documentum-java-method-server/

Best regards,

Huseyin OZVEREN