StorageService

The StorageService is used for temporary storage (within the main memory) or longer-term storage of data by the Integration Server, which can be found using a simple ID.

Persistently storing data requires the use of a PersistentManager (see below).

XML configuration


Important note: The availability of a service depends on the license purchased and whether the service has been registered in the configuration file ./etc/factory.xml of the Service Factory (changes require server restart!). There you will also find the responsible configuration file for a service, otherwise you can also edit the configuration file of the service directly in the GUI of the service (changes require a service restart!).

Setting the standard waiting time


The following XML fragment sets the amount of time between two validity checks of the stored values.


<Set name="waitTime">5000</Set>


The waiting time is specified in milliseconds.

Setting a "PersistentManager"


The following XML fragment sets and activates the DefaultPersistentManager for the StorageService. The argument that is passed during the initialisation of the DefaultPersistentManager represents the directory in which the objects are to be saved.


<Call name="setPersistentManager">
<Arg>
<New class="com.ebd.hub.services.storage.DefaultPersistentManager">
<Arg>./logs/storage</Arg>
</New>
</Arg>
</Call>


The following XML fragment sets and activates the JDOPersistentManager for the StorageService. The argument that is passed during the initialisation of the JDOPersistentManager represents the database alias to be used.


<Call name="setPersistentManager">
<Arg>
<New class="com.ebd.hub.services.storage.JDOPersistentManager">
<Arg>hub</Arg>
<Set name="optimizeTables">true</Set>
</New>
</Arg>
</Call>


Lobster recommends a Redis database in a Load Balancing environment. The following XML fragment sets and activates the RedisPersistentManager for the StorageService


<Call name="setPersistentManager">
<Arg>
<New class="com.ebd.hub.services.storage.RedisPersistentManager">
<Arg>redis://localhost:6379</Arg>
<Arg>my password</Arg>
</New>
</Arg>
</Call>


If you want to migrate existing entries from the JDOPersistentManager, it is sufficient to specify the database alias of the JDO manager.


<Call name="setPersistentManager">
<Arg>
<New class="com.ebd.hub.services.storage.RedisPersistentManager">
<Arg>redis://localhost:6379</Arg>
<Arg>my password</Arg>
<Set name="jDOAlias">hub</Set>
<!-- only needed to migrate from JDOPersistentManager -->
</New>
</Arg>
</Call>


If a Redis cluster is to be addressed (here consisting of 3 machines "node1", "node2" and "node3"), the following XML fragment can be used


<Call name="setPersistentManager">
<Arg>
<New class="com.ebd.hub.services.storage.RedisPersistentManager">
<Arg>
<New class="java.util.HashSet">
<Call name="add">
<Arg>
<New class="redis.clients.jedis.HostAndPort">
<Arg>node1</Arg>
<Arg type="int">6379</Arg>
</New>
</Arg>
</Call>
<Call name="add">
<Arg>
<New class="redis.clients.jedis.HostAndPort">
<Arg>node2</Arg>
<Arg type="int">6379</Arg>
</New>
</Arg>
</Call>
<Call name="add">
<Arg>
<New class="redis.clients.jedis.HostAndPort">
<Arg>node3</Arg>
<Arg type="int">6379</Arg>
</New>
</Arg>
</Call>
</New>
</Arg>
<Arg>my password</Arg>
</New>
</Arg>
</Call>

General settings


images/download/attachments/189460946/Services_11_EN-version-1-modificationdate-1737691367631-api-v2.png


(1) The amount of time between two validity checks of the stored values.

(2) The used PersistenceManager and the directory in which the objects to be stored are to be stored.

Currently managed objects


images/download/attachments/189460946/Services_12_EN-version-1-modificationdate-1737691367626-api-v2.png


(1) The list of currently managed objects. The unique key is displayed, whether the object is stored persistently, the time until the object is removed when it is no longer accessed, and the value of the object if it can be displayed. The context menu can be used to delete an object from memory.

Log level dependencies


Changes to the log level of the LogService have no influence on the logging behaviour of the StorageService.

If the service is set to verbose mode, the keys of all added and removed entries are recorded in the log.