If two or more filters contain the same constraint, then there we only create one instance of the abstract syntax tree (AST) for that constraint in the service. This syntax tree is then shared between the constraints. Since the ASTs can have a large memory footprint, even for the simplest constraint, then sharing the ASTs in this manner can conserve large amounts of memory.
This technique is most useful when many proxies have individual filter objects attached to them containing the same constraint.
However, there will be a performance/memory usage tradeoff since the constraint can only service one request at a time. This may cause memory issues if events are backing up in queues as filter evaluation becomes a bottleneck. This critical point is determined by a number of factors, therefore it may take some testing by a user to see if this feature is of any benefit to them. It would then be a decision on whether to use this feature in conjunction with the "MaxEventsPerConsumer" QoS in order to stop events from backing up in the service.
The advantage of using the feature is that it would allow more room for events before discard actually occurred. The disadvantage is that there is a point at which using the feature becomes the cause of the problem since the single constraint cannot execute quickly enough to service all requests (i.e. when we have a large number of filters sharing the constraint).
To enable the feature, add "-DSharedConstraints=true" to the JVM flags for the service in the Adminstration Manager GUI.
In previous versions of OpenFusion CORBA Services v4, the HSQLDB database plug-in was the default, but for the OpenFusion Notification Service, the event based persistence was implemented using a file based journalling system. In v4.1, the default is still HSQLDB, but this is now used for the event based persistence also. To use the file based journalling system, select File for the Storage Type property.