Several common OpenSplice Tuner problems can be resolved by looking through the User Guide, which can be found here:
OpenSplice v6 Guide (pdf | html)
OpenSplice v7 Guide (pdf | html)
When using the OpenSplice Tuner you may run into some of the following errors:
When using the OpenSplice Tuner you may run into some of the following errors:
Could not load JNI library error.
Could not load JNI library ‘cmjni’. Reason: /opt/PrismTech/OpenSpliceDDS/VX.X.X/HDE/x86.linux2.6/lib/libcmjni.so: /opt/PrismTech/OpenSpliceDDS/VX.X.X/HDE/x86.linux2.6/lib/libcmjni.so: wrong ELF class: ELFCLASS32 (Possible cause: architecture word width mismatch)The reason that you are seeing this message is because you are starting the tuner with a 64-bit JVM and using OpenSplice 32-bit libraries. To resolve the problem you need to either to use the 32-bit JVM or install the 64-bit version of OpenSplice
OpenSplice Tuner freezes when running via a remote shell
This a issue common with running any java GUI through a ssh -X terminal. Running a GUI remotely via ssh can cause the application to freeze depending on the network connection, however this would go for any java application being run in this manner. To prevent this from occurring in the future you should run the Tuner GUI locally creating a new OpenSplice node.OpenSplice Tuner “check the Supplied URI/URL is available or the shared memory segment” error.
When configuring OpenSplice you can choose between a shared memory architecture or a single process memory architecture. If you configure OpenSplice to use shared memory, when it starts it allocates a block in memory to use as the shared database. This is used by the DDS related administration and all DDS applications deployed in the current system. The data is only physically present once on any machine and smart administration is used to provide a view of the data for each subscriber. At startup OpenSplice will create a this shared memory region at a virtual address in memory that is common across OpenSplice daemon, any services used by that domain and also the application. In this case it appears that the tuner is having a problem mapping the shared memory into its process space. In the case of this error in Tuner, provided the Opensplice daemon is running without any errors (check for an ospl-error.xml output file) it is possible that the memory location Tuner requests clashes with some of the Java libraries that Tuner has mapped in. With the standard “shmem” ospl.xml file the shared memory size is 10MB and the address where the memory is mapped is 0x40000000 (on windows). You will need to modify the memory address so that it is no longer clashing. You can do this by using the Configurator tool to modify the OpenSplice/Domain/Database/Address within the XML file (it can also be edited manually). There is more information on this in the OpenSplice Configuration and Deployment Guides, this article also has more information on the configurator. This configuration element is used to specify the start address of the location of the shared memory database, where the nodal shared administration is mapped into virtual memory for each process that attaches to the current Domain. The default values are platform dependent. On windows you can use the VMMap utility provided by SysInternals. This shows the process address space and the files mapped into the process, along with the free regions. This should enable you to see if the memory is indeed clashing and allow you to find another free region to map the shared memory to.Error when deleting Domain Participant: The Domain Participant contains one or more Entity objects.
When trying to delete a Domain Participant using the tuner the above error appears along with the following in log file:Report : WARNINGData : Mon Dec 15 11:00:00 2014Description : Delete Participant 0x684df8 failed: Some contained Subscribers still existsNode : testProcess : a_process <5000>Thread : 4792Internals: VX.X.X/3070bd6/2a52f68/_DomainParticipantPrepareDelete/gapi_domainParticipant.c/725/0/1387546234.801343120
In this case the error is pointing to a Subscriber still existing somewhere within the system. To solve this problem inspect your code to ensure that all Subscriber entities are deleted before an attempt is made to delete the Subscriber itself (datareaders etc.). It should be noted that all memory loans used by data readers on the Subscriber Entity must be returned.