Native C++ Components of LiveCycle

LiveCycle is not a pure Java application. It has had C++ components since the first version but some have been re-written in Java (PDFMM, for example). In ES, ES2 and ES2.5, XMLForm is the main C++ component. It is used by both Forms ES2 as well as Output ES2. In JBoss, it is run from the /svcnative/XMLFormService/bin/ folder.

The following properties control its behaviour:

– com.adobe.xmlform.bmc.POOL_MAX
– com.adobe.xmlform.bmc.MAXIMUM_REUSE_COUNT
– com.adobe.xmlform.bmc.REPORT_TIMING_INFORMATION
– com.adobe.xmlform.bmc.CT_ALLOW_SYSTEM_FONTS

The name of each of these properties explain what each does.

The default value for POOL_MAX is 4. However, if your server instance has more than four CPU cores, you will get better throughput by setting its value equal to or about 1.5x to 2x the number of CPU cores.

Even though the default POOL_MAX setting is 4, you will not see all four of the XMLForm processes spawned unless the server was hit at any time with four or more concurrent requests. In fact, you could set it to a high value, run your load test, and figure out the peak concurrent request load by looking at how many XMLForm processes got spawned!

You can verify how many of these processes are running using the following command in Solaris/AIX/Linux:
ps -ef | grep XMLForm | grep -v grep

To get additional details on these processes, you can use the ‘prstat‘ command (Solaris). The output could look something like this:

Each XMLForm process received about 102 MB of memory from the operating system of which between 55 MB to 70 MB is actually resident in RAM (RSS = Resident Set Size). The STATE column indicates what each of the XMLForm processes are doing. This particular Solaris M3000 server had a single quad-core SPARC64 VII+ CPU with each of the 4 cores capable of running 2 threads each. Solaris reports each of these threads as a vCPU numbering it from 0 to 7.

In Windows, you can use Task Manager’s Process tab.

REPORT_TIMING_INFORMATION significantly increases log output. Therefore, it should be set to true only in DEV and TEST environments.

MAXIMUM_REUSE_COUNT determines how many times a particular XMLForm process is allowed to be invoked before it is recycled (to avoid the risk of problems caused by potential memory leaks). The default value is 10,000. In practice, most processes will get recycled once they reach 9,000 invocations. You will see it range between 9,100 and 9,900. When a recycling happens, you will see this reported in the appserver’s log. The log entry will look something like this (JBoss/Solaris 10 example):

INFO [ProcessResource] BMC517: Service XMLFormService: Process ProcessResource@51ec5bba(name=XMLForm.exe,pid=29909) retired after 9505 uses
INFO [ProcessResource] BMC506: Service XMLFormService: Native process ProcessResource@51ec5bba(name=XMLForm.exe,pid=29909) stopping
INFO [ProcessResource] BMC505: Service XMLFormService: Starting native process with command line "/data/JBossUFS/server/lc_oracle/svcnative/XMLFormService/bin/XMLForm.exe" -MyPath /data/JBossUFS/server/lc_oracle/svcnative/XMLFormService -IOR IOR:00000000000000224...<snip>...003 -AppServer jboss
INFO [ProcessResource] BMC508: Service XMLFormService: Native process PID = 3046

If the appserver is running as a non-root user in Solaris/AIX/Linux, you would also see the following which can be ignored:

ERROR [STDERR] omniORB: Warning: ioctl SIOCGICONF failed.
Unable to obtain the list of all interface addresses.

You can configure XMLForm using JVM init arguments. A JBoss/Windows run.bat example is given below:

Here’s a sample snippet from run.bat

rem ———————————————————-
rem Configuration Changes for XMLForm
rem ———————————————————

set JAVA_OPTS=%JAVA_OPTS% -Dcom.adobe.xmlform.bmc.POOL_MAX=8
set JAVA_OPTS=%JAVA_OPTS% -Dcom.adobe.xmlform.bmc.MAXIMUM_REUSE_COUNT=10000
set JAVA_OPTS=%JAVA_OPTS% -Dcom.adobe.xmlform.bmc.REPORT_TIMING_INFORMATION=false
set JAVA_OPTS=%JAVA_OPTS% -Dcom.adobe.xmlform.bmc.CT_ALLOW_SYSTEM_FONTS=true

Here’s a sample snippet from (JBoss on Solaris/Linux)

# ———————————-
# Configuration Changes for XMLForm
# ———————————-

JAVA_OPTS=”$JAVA_OPTS -Dcom.adobe.xmlform.bmc.POOL_MAX=8″
JAVA_OPTS=”$JAVA_OPTS -Dcom.adobe.xmlform.bmc.MAXIMUM_REUSE_COUNT=10000″
JAVA_OPTS=”$JAVA_OPTS -Dcom.adobe.xmlform.bmc.CT_ALLOW_SYSTEM_FONTS=true”

The configuration is reported in the appserver’s log when LiveCycle starts. It should look something like this (JBoss/Solaris example):

INFO [XMLFormService] BMC512: Service XMLFormService: Starting
INFO [XMLFormService] BMC511: Service XMLFormService: Native files expanded in /data/JBossUFS/server/lc_oracle/svcnative/XMLFormService
INFO [XMLFormService] ALC-XTG-100-110: PoolMax: 8
INFO [XMLFormService] ALC-XTG-100-110: MaximumReuseCount: 10000
INFO [XMLFormService] ALC-XTG-100-110: ReportTimingInformation: false
INFO [XMLFormService] ALC-XTG-100-110: CTAllowSystemFonts: true
INFO [XMLFormService] BMC513: Service XMLFormService: Started

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 10.0/10 (5 votes cast)
Native C++ Components of LiveCycle, 10.0 out of 10 based on 5 ratings
This entry was posted in Adobe LiveCycle ES2 (9.0.x), Adobe LiveCycle ES, Adobe LiveCycle 7.x and tagged , , , , . Bookmark the permalink.

One Response to Native C++ Components of LiveCycle

  1. Is it possible to get a version of this that has the debugging enabled? We have a segmentation fault and it’d be great to know what libraries might be causing it.