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
_______________________________________________
vtp-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/vtp-dev
