CORBA Services Known Issues

See the OpenFusion CORBA Services Fixed Bugs page for the list of bugs which have been fixed.

For information about installing and configuring the OpenFusion CORBA Services, please refer to the Installation section of the Product Guide.

Known Issues

COS#430 - when using JDK 1.5 or JDK 1.6, issuing a kill -quit command on the Notification Service process does not log the thread dump to the Notification Service log file, whereas a thread dump is logged to the Notification Service log file when using JDK 1.4. This is due to a change in JVM behaviour, documented here:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6415151.
However, with JDK 1.5 or JDK 1.6, when an application is started with the options
-XX:+UnlockDiagnosticVMOptions -XX:+LogVMOutput -XX:LogFile=<file>
the thread dump is logged to <file>. This is fixed in JDK 7 - see
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4960438.
When using VisiBroker 7, the manager and run scripts require the -x option to be used. Thus, to start the Administration Manger, type manager -x. When using the run script, for example when running the examples, type run -x <classname>.
When configuring security using the GUI, start the manager with the -x option (e.g. manager -x).
Use of the uninstall.bat script on windows to uninstall OpenFusion will not delete the root directory and index.html file. To complete uninstallation, delete the directory where OpenFusion was installed.
There is a minor problem with the GUI control for the HSQLDB checkpoint interval property. If you select any database other than HSQLDB, the HSQLDB checkpoint interval will be disabled. When the changes are saved and the manager restarted the property will be enabled. However, setting of the property will not have any affect unless HSQLDB is selected.
If a problem is experienced during the export of information for the CORBA Services, then ensure Object Purging is not enabled on the service. Object purging may initiate during the export process causing an org.omg.CORBA.OBJECT_NOT_EXIST exception to be reported.
It is not recommended that file based persistence be used in production environments with the OpenFusion Log Service due to scalability and performance issues with large amounts of data.

Notification Service

When using File as the persistence mechanism, persistent events are not always removed from the disk correctly.
The AutoSequenceBatchSize QOS should be set to 0 when using persistent events.
When using the auto-sequencing functionality, be aware that events are batched in the client for a period until the auto-sequencing determines they are 'sent' to the Notification Service. During this 'batching' time, if a user's application changes an event, this will be affect the event that is batched.
If JacORB is configured to use the compactTypecodes property then names, member types and member names are removed when marshalling type code information over the wire which can save bandwidth. However this can adversely affect filtering in the Notification service which requires such information. Workarounds include disabling the property or using filtering with the positional notational.
If a large number of events are persisted and not delivered, then restarting the service may be slow. The GUI may exceed its timeout value for starting the service and indicate it has failed to start, when it is still in the process of starting.
Since VisiBroker-52, VisiBroker will not allow clients to resolve the OpenFusion Notification Service with a resolve name of NotificationService. On installation of CORBA Services for VisiBroker, the resolve name for the OpenFusion Notification Service is defaulted to OFNotificationService.
The Notification Service requires the Xalan TransformerFactory implementation to be the default TransformerFactory instantiated by the JAXP API at runtime. It is possible that third party jar files may prefer a different TransformerFactory implementation and override the default via the JAXP services API. The existence of such jar files on the CLASSPATH can cause problems when starting the Notification Service. However, it is still possible to start the Notification Service in this situation. It is possible that the default TransformerFactory implementation has been overridden if:
- the Notification Service fails to start
- a NullPointerException is observed in the service log
- the NullPointerException is at the point where the service is trying to initialise the component handler
In order to resolve this issue and start the Notification Service:
- click on the NotificationService node in the Administration Manager GUI
- select the "Java" tab
- add -Djavax.xml.transform.TransformerFactory=org.apache.xalan.processor.TransformerFactoryImpl to the "JVM Flags" field
- save the new configuration and start the service
When using filters with the Notification Service, you may receive an UnsupportedFilterableData exception whilst trying to perform a filter match against an event where fully qualified property names are not used in the constraint expression. If this occurs, please use the fully qualified name in the expression.
Object Purging should never be used with the Notification Service. The Administration Manager currently does not have the capability to disable generic service options based on a specific service.
Due to the way CORBA objects are handled within version 4 of the Notification Service, the OBJECT_NOT_EXIST exception can be thrown in different circumstances than in versions 2.5 and 3. Instead of the exception being thrown when a reference to the the non-existent object is obtained, it will be thrown when the first call is made to the object.
For example: consider the case of a channel that has been destroyed, but the client code has a reference to it via an IOR. In versions 2.5 and 3, the act of obtaining the channel reference by performing a narrow would cause OBJECT_NOT_EXIST to be thrown. In version 4 the narrow operation will complete without error; the OBJECT_NOT_EXIST will be thrown when the channel is used (i.e. a call is made to it, such as default_supplier_admin()).
The Channel Configurator may give out warning messages when loading xml files. These can be ignored and this will be corrected in a future release.
To allow timeout properties to be set in the CORBA Services for all supported versions of VISIBROKER, the following system properties (e.g. in the "JVM Flags" property) are required:

VB_REL_CONN_TIMEOUT
Sets the value for com.inprise.vbroker.QoSExt.RELATIVE_CONN_TIMEOUT_POLICY_TYPE

VB_REL_REQ_TIMEOUT
Sets the value for org.omg.Messaging.RELATIVE_REQ_TIMEOUT_POLICY_TYPE

VB_REL_RT_TIMEOUT
Sets the value for org.omg.Messaging.RELATIVE_RT_TIMEOUT_POLICY_TYPE

All values are to be specified in seconds: the code handles the conversion to the 100ns units.

If you have logging at the info level, the service log will have information on each individual timeout property being handled plus the total number that are being applied to the ORB. For example:

JVM Flags = "-DVB_REL_CONN_TIMEOUT=10 -DVB_REL_RT_TIMEOUT=15 -DVB_REL_REQ_TIMEOUT=20"

Log extract:
INFO - Policy 'com.inprise.vbroker.QoSExt.RELATIVE_CONN_TIMEOUT_POLICY_TYPE' being set to 100000000
INFO - Policy 'org.omg.Messaging.RELATIVE_REQ_TIMEOUT_POLICY_TYPE' being set to 200000000
INFO - Policy 'org.omg.Messaging.RELATIVE_RT_TIMEOUT_POLICY_TYPE' being set to 150000000
INFO - Applying 3 timeout(s) to the ORB

Top