About the Studio Customization Toolkit Origin Trace Facility

You can enable the generation of a stacktrace to be passed as a parameter whenever a call from the ENOVIA Studio Customization Toolkit client is made into the ENOVIA Live Collaboration kernel. This means that log output enabled by MX_VERBOSE_TRACE can include the ENOVIA Studio Customization Toolkit/client-side class (that is, the application, applet, servlet, bean, jsp page, or JPO) of any call, so that the origin of problematic ENOVIA Studio Customization Toolkit calls can be identified and fixed. In addition, when ENOVIA Studio Customization Toolkit origin tracing is enabled, its output is added to the output of the MQL server monitor command. (Refer to the MQL Guide for details.) ENOVIA Studio Customization Toolkit origin tracing can be enabled on the ENOVIA Studio Modeling Platform Rich Clients, XML client, ENOVIA Live Collaboration Server, and JNI (RIP) architectures.

Related Topics
Enabling the Studio Customization Toolkit Client
ENOVIA Live Collaboration Memory Management
Example of Studio Customization Toolkit Origin Trace Ouput

Tracing must be enabled on the ENOVIA Studio Customization Toolkit client (or ENOVIA Studio Modeling Platform Rich Clients) as well as the Web Server and ENOVIA Live Collaboration Server layers. When enabled on the ENOVIA Studio Customization Toolkit client, the stacktrace information is created; when enabled on the ENOVIA Live Collaboration Server, this information is printed to the server's log file (for the ENOVIA Studio Modeling Platform Rich Clients, it is created and printed to the local log file) and available for adding to the server monitor command output. The added information may result in greatly increased network traffic, slower performance, and consumption of server disk space, and therefore is not on by default, and should only be enabled when troubleshooting.

ENOVIA Studio Customization Toolkit origin tracing should not be enabled during production use, since additional machine resources are required.

When a problematic ENOVIA Studio Customization Toolkit call (such as a dangling transaction or a wildcard query) is identified, implementors should look at the verbose trace file for the stack trace string of that problematic call. This string will show the ENOVIA Studio Customization Toolkit origin page, bean, servlet, jsp page or application class.

Enabling the Studio Customization Toolkit Client

XML Applet

To enable the Web version of the ENOVIA Live Collaboration to generate a stacktrace for all calls, uncomment the following to the jsp that is used to start Matrix:

props.put("ADKTrace", "TRUE"); 

The default setting is "FALSE."

You must also enable the platform and web servers to print the stack traces in a log file.

Custom Studio Customization Toolkit applications

To enable this level of tracing in the ENOVIA Studio Customization Toolkit client application, use one of the following methods in the matrix.db.Context class. For global tracing on all Context objects created use:

    public static void setOriginTraceAll(boolean set) 
    public static boolean getOriginTraceAll() 

For tracing on a single Context object, jsp, or JPO use:

    public void setOriginTrace(boolean set)
    public boolean getOriginTrace() 

You must also enable the platform and web servers to print the stack traces in a log file.

Enabling the Web or Application Server

To trace all servlets and jsps executed on the server, uncomment the following in your framework.properties file:

ematrix.origin.trace=true 

This enables tracing globally for all context objects created.

Alternatively, you can add this setting to web.xml (either by modifying the file in a blown out war file, or using the application server's administration console to modify an already deployed webapp).

When tracing jsps, it is helpful to configure the web server to "keep generated" java code for jsps. Consult your web server documentation for instructions.

Enabling the Live Collaboration Kernel

To enable the ENOVIA Live Collaboration Server or ENOVIA Studio Modeling Platform Rich Clients to print the stack traces into a file called matrixserver.log add the following to the .ini file or emxEnv.sh:

MX_VERBOSE_TRACE=matrixserver.log

Also include the appropriate setting(s) to indicate which ENOVIA Studio Customization Toolkit calls to trace:


  • To trace all ENOVIA Studio Customization Toolkit calls, use:

MX_ADK_TRACEALL=true


  • To trace only specific ENOVIA Studio Customization Toolkit calls, each jdl call can be enabled individually, using it's name as the keyword. Do not include MX_ADK_TRACEALL. For example:
executeCmd_bosMQLCommand=true
evaluate_bosQuery=true
start_bosContext=true

On Windows, a file named adkTrace.ini is installed in the ENOVIA_INSTALL directory when the ENOVIA Studio Modeling Platform Rich Clients or the ENOVIA Live Collaboration Server is installed. This file contains samples of all possible per-ENOVIA Studio Customization Toolkit call trace settings. Administrators can use this file to copy settings to their enovia.ini files for the ENOVIA Studio Modeling Platform Rich Clients or ENOVIA Live Collaboration Server (previously matrix.ini or ematrix.ini) when they wish to enable tracing on a particular ENOVIA Studio Customization Toolkit call.

On Unix, a file called adkTrace.sh is installed in the SERVERHOME directory when the ENOVIA Studio Modeling Platform Rich Clients or the ENOVIA Live Collaboration Server is installed. The ENOVIA Studio Modeling Platform Rich Clients as well as the ENOVIA Live Collaboration Server's shell scripts call this auxiliary shell script, which contains commented out/disabled samples of all possible per-ADK call trace settings (as well as the traceall setting). Administrators can uncomment those they wish to have traced.

Studio Customization Toolkit Exceptions

The freeContext.bosInterface call does not include a stack trace; it is called by the java garbage collector.

The allocExternalContext.bosInterface stack trace is supplied as a parameter to the call in verbose logging if ENOVIA Studio Customization Toolkit origin tracing is enabled on the client side (regardless of MX_ADK_TRACEALL setting). If client side tracing is disabled, a blank stack trace is generated. To prevent unwanted network traffic, ensure the stack trace for allocExternalContext.bosInterface is blank, thus ensuring the feature is disabled on the client side (JPO, applet or web server).

Studio Customization Toolkit Origin Trace Output

MX_VERBOSE_TRACE processing prints the session ID and stack trace string. Here is sample output from a jsp page - note the Weblogic classes in the stacktrace.

18:31:20.403 VERB t@3888 stateless dispatch for allocExternalContext.bosInterface
18:31:20.403 VERB t@3888   input params: 
sessionId=EjkwM6TREKL5aMad2wqsGH8tYghLNO3vXE2JZJzRRUpOZrKkpuZg!-1522304197!11557530722
77:mx28136748f556a9de:(__emxnavigator.java:959), stackTrace=
    at matrix.db.Context.getContext(Context.java:923)
    at matrix.db.Context.CloneContext(Context.java:332)
    at matrix.db.Context.<init>(Context.java:263)
    at 
com.matrixone.servlet.FrameworkServlet.getFrameContext(FrameworkServlet.java:535)
    at 
com.matrixone.servlet.FrameworkServlet.getFrameContext(FrameworkServlet.java:527)
    at com.matrixone.servlet.Framework.getFrameContext(Framework.java:365)
    at jsp_servlet._common.__emxnavigator._jspService(__emxnavigator.java:959)
    at weblogic.servlet.jsp.JspBase.service(JspBase.java:33)
18:31:20.403 VERB t@3888 dispatch complete since 18:31:20.403, 0.000 secs (0.000 direct 
0.000 nested)
...
19:32:19.625 VERB t@2048 allocate context for session 
EjkwM6TREKL5aMad2wqsGH8tYghLNO3vXE2JZJzRRUpOZrKkpuZg!-1522304197!1155753072277:mx10032
2343aaee3:(__emxnavigatortoolbar.java:1165)
19:32:19.625 VERB t@2048   input params: className=emxPropertyUtil, construct length=0, 
methodName=cacheSymbolicNames, params length=1
19:32:19.625 VERB t@2048   input stacktrace: 
    at com.matrixone.jdl.bosInterfaceShim.invokeClass(bosInterfaceShim.java:957)
    at matrix.db.JPO.invokePrivate(JPO.java:213)
    at matrix.db.JPO.invoke(JPO.java:132)
    at 
com.matrixone.apps.domain.util.PropertyUtil.loadSymbolicNamesCache(PropertyUtil.java:4 
03)
    at 
com.matrixone.apps.domain.util.PropertyUtil.checkSymbolicNamesCache(PropertyUtil.java: 
379)
    at jsp_servlet._ematrix._emxhome._jspService(_emxhome.java:506)
    at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)

Here is sample output from a JPO - note there are no Weblogic classes in the stacktrace:

15:52:49.109 VERB t@2544 allocate context for session 
EvcL6qZfvtlNMKrC2q3O33lKBmevRTQtNa5MSmBWb0Kps2IdbX2j!1231146595!1156521163062:mx435012
3950b68a7:(__emxnavigator.java:959)
15:52:49.109 VERB t@2544   input params: 
className=emxPropertyUtil_mxJPOzXZnZQAAAAEAAAAB
15:52:49.109 VERB t@2544     stacktrace: 
    at com.matrixone.jdl.bosInterfaceShim.classLoader(Unknown Source)
    at matrix.db.MatrixClassLoader.getBytes(MatrixClassLoader.java:67)
    at matrix.db.MatrixClassLoader.findClass(MatrixClassLoader.java:86)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:294)
    at matrix.db.MatrixClassLoader.newClass(MatrixClassLoader.java:167)
    at matrix.db.MatrixClassLoader.newInstance(MatrixClassLoader.java:197)
    at matrix.db.MatrixClassLoader.newInstance(MatrixClassLoader.java:292)
    at com.matrixone.jni.MatrixKernel.statelessDispatch(Native Method)
    at com.matrixone.jdl.rmi.bosInterfaceImpl.invokeClass(Unknown Source)
    at java.lang.reflect.Method.invoke(Native Method)
    at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:236)
    at sun.rmi.transport.Transport$1.run(Transport.java:147)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.rmi.transport.Transport.serviceCall(Transport.java:143)
    at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
    at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
    at java.lang.Thread.run(Thread.java:479)
15:52:49.140 VERB t@2544   output params: returnVal length=365
15:52:49.140 VERB t@2544 dispatch complete since 15:52:49.109, 0.031 secs (0.031 direct 
0.000 nested)

Verbose tracing output can include the caller information appended to the context session id generated by Framework.getFrameContext(). Following is an example illustrating this- note that the caller information emxteamsearchcontentresult.java follows the string: B1yyHxgoYeuyPHpaAPAH2qLIBGplw42XKR5B228B2Oki2UJNLuKH!-682390697!16 7842110!7001!7002!1102426802906:mx1102427172562633055.

13:46:13.390 VERB t@1776 stateless dispatch for evaluateSelect.bosQuery
13:46:13.390 VERB t@1776 allocate context for session 
B1yyHxgoYeuyPHpaAPAH2qLIBGplw42XKR5B228B2Oki2UJNLuKH!-682390697!167842110!7001!7002!11 
02426802906:mx1102427172562633055:(__emxteamsearchcontentresult.java:3628)
13:46:13.390 VERB t@1776   input params: name=, query type=Document, name=*, 
revision=*, lattice=eService Production, owner=*, where=(revision == last) && 
(("to[Vaulted Objects].from.id" !~~ "zz")) && (current.access[read] == TRUE), limit=0, 
expandTypes=true
, objectSelect length=2
13:46:13.437 VERB t@1776   output params: