[vtp-dev] Recent Updates

[Trip Gilman <trip@xxxxxxxxxxxxxxx>]

Title: Recent Updates

Hello Everyone,

    For those of you who missed the commit notice from earlier today, I’d like to point out a significant change to the APIs in the trunk that breaks some backwards compatibility with some custom modules.  The change removes the ability for custom module writers to request the raw DOM objects that make up the module’s configuration within the process.xml document.  Access to these objects was usually acheived by adding a Element parameter to the action’s constructor which would then be populated by the aspect injection system.  This technique will no longer be available.  The action class will not be instantiated if there is an Element parameter present in its constructor.

    The primary reason this change was introduced within the trunk prior to a major update cycle is the critical nature of the defects being resolved.  There has been a memory leak present in the runtime for some time.  It however has not been resolved because it only occurred under heavy loads and even then only randomly.  The root cause of this issue has been found and is related to the use of the DOM APIs within the runtime core system.  The DOM implementation was known to be non thread-safe, but was thought to still be read coherent from multiple threads.  This simply is not the case.  The implementation is fully non thread-safe with both read and write operations requiring secure locking.  The performance ramifications of placing locking on these structures would have been too great.

    The only solution available was to use the DOM api to initially load the xml content, objectize the values, and then discard it.  The only problem with this approach is the removal of access to the raw DOM directly in the action code.  It has been our recommendation for a while now to use the ConfigurationExporter interface on the desktop side and the IConfiguration interface on the runtime side to manage action configuration data.  Module writers who have followed this recommendation will not be affected by this change.  Applications that do not employ custom modules will also not be affected by this change.  Only custom modules that access the DOM information directly.

    The conversion process to the recommended approach is fairly straightforward and should require very little effort to complete.  I suggest using the Script block as an example.  The ScriptConfigurationExporter class offers a nice template to base your exporters off of.  Constructing the IConfiguration objects used on the runtime side should be easy as well.  Anyone that has any questions about or problems while converting their modules are welcome to post on this list or the newsgroup and we’ll help you get up and running as fast as possible.

    The good news about these changes is that we have seen a 6-8x increase in performance and top end port density on all ranges of hardware.  The system now scales correctly with additional computing power and seems to only be limited via available processors.  Another benefit of these changes is the system as a whole will leverage multi-core and multi-processor hardware platforms to much greater extent.

    On another subject, the logging system has also had some major improvements.  All built-in modules and runtime core components now ensure a given logging level is enabled before performing any logging related activities.  The logging level for applications deployed in a WAR file can also be modified with ease.  Simple open a web browser to /war-name/-/logging/.  You will be presented with a web UI that allows the setting of the system log level.  Using a setting of WARN or ERROR will significantly improve system performance on high volume deployments.

Trip Gilman
Voice Tools Project Lead