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. XML AppletTo 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 applicationsTo 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 ServerTo 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 KernelTo 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:
MX_ADK_TRACEALL=true
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 ExceptionsThe 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 OutputMX_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: |