Product: OpenFusion CORBA Services

Version: ALL

Description:

What is stored in the files in the etc/data directory tree?

Resolution:

The etc/data directory contains the persistent state for all of the CORBA objects when file based persistence has been selected.

The Notification Service also stores persistent events as files below this directory. The file names have the following format:

db53f3d0-9149-11d5-82cf-d35d3f05a644

Is there any way to identify an object or service with one data file?

The file names are based on Universal Unique Identifiers UUID to ensure unique file names. All implementation states associated with a service are stored under a directory that is named after a Process ID , another UUID, that is unique to that service instance.

The easiest way to tell which directory is associated with which server is to assign an explicit UUID for the Process ID using the Configuration Manager. Selecting the Process ID field under the Server tab will generate a new UUID. This must be done before the service is first started.

Alternatively the File Repository Directory under the persistence tab can be changed from the default to a directory name appropriate for the service. Again this must be done before the service is first started. The object state files are gziped serialized state and there is no tool provided to indicate the which object maps to a particular file.

However, since no administration can be done directly on the persistence files this should not be needed. All administration should be performed via the GUI or via the Notification API. Basically if the file ends in a .34 or similar number it is an event. If you were getting lots of these files appearing it would indicate you had event reliability set to persistent somewhere and the events were not reaching the consumer.

The other files are the persistent object eg. proxy_push_suppliers etc.

A simple way of determining the types of object stored for which state, is the following:

for i in *; do gunzip < $i | strings; done | grep com.prismt.*Impl

This is will roughly extract the class names. A more accurate way to do this is to do the following:

gunzip < THE_FILE > out emacs out (or use some other editor to view the file) ... and to look at the bottom of the file for the POA Tie class name. You don't find out the class of the persistent object directly, but you do know the interface that it implements.

For instance, for one of the files, the POA Tie class is ProxyPushSupplierPOATie. This means the object that was saved to that file implements the ProxyPushSupplierOperations interface. With regards to the Notification Service, persistent events are stored in the File Repository Directory with a file named id.number where id is the UUID associated with an internal queue in the Notification Service.

If you are running multiple Notification services then the id will be found in the sub-directory corresponding to the service. For example, if the event file 6a8dcc30-a124-11d5-9568-d56fced00ba7.1580 is found then the command ls /6a8dcc30-a124-11d5-9568-d56fced00ba7 will show which service PID is associated with that event.

Assuming that the clients destroy/disconnect all used objects, could we expect the persistent data to be cleaned up?

Yes, persistent data is cleaned up when an object is destroyed and when events have been delivered.

Note that most services have some objects that exist for the life time of the service e.g. the Notification Service will have about 6 objects corresponding to factories, bridges and service process object.

Can you suggest any configuration parameter or recommended usage practices for handling the persistent storage?

General Solaris advice applies: ensure that the file system is locally mounted i.e. not over NFS otherwise performance will degrade badly. Mounting UFS file systems with the loggingoption should improve performance since large numbers of small files may be created and destroyed.