XmlBlaster Logo



XmlBlaster Logo

Type NEW
Priority HIGH
Topic XmlBlaster supports sessions and subscriptions which persist a server crash.

Persistent subscriptions will persist a server crash. After such a crash they are reestablished during the recovery process.
Subscription persistence is handled together with session persistence (subscription persistence would not work without session persistence). The SessionPersistencePlugin takes care of that.

The recovery process must happen before the communication plugins are made available. This to ensure that recovery will be accomplished completely before any client can access xmlBlaster. It also must happen after the TopicHandler is resuscitated. How to ensure this is described in the configuration section below.

A subscription is made persistent explicitly by passing the persistent flag in the subscribeQos. If the session to which it belongs is not persistent at the subscription time, it is implicitly made persistent by the subscrption.

The benefit of having persistent subscriptions is that you as a client don't have to bother about resubscribing after a server crash. Since this is handled before any client is able to connect again (the configurator is responsible for that), gaps between possible publishes and subscriber reconnection are eliminated.

Delivery of all publishes done before the subscriber can reconnect is thereby ensured. Currently there are some requisites which must be fulfilled to allow a subscription to be made persistent. These are:
  • a) The session to which it belongs must be assigned by the client (i.e. he must provide a positive sessionId)
  • b) The callback connection must be configured as failsafe (to avoid disconnection in cases where the client is inaccessible)
Some of the protocols may be less restrictive than others but if you fulfill the mentioned requisites, subscription persistency will work on all communication protocols.

Persistence of subscriptions is ensured by a persistent I_Map implementation. Configuration of the storage (for example storage size or cache size) is done on server side, either by passing parameters on the command line or in the xmlBlaster.properties file.


  • If the persistent subscription is done and the storage is overflown, an exception is thrown back to the client and the subscription is not valid.
  • Making a persistent subscription on a transient session implies that the session is made persistent. If the storage for the persistent sessions is overflown, an exception is thrown back to the client.

SubscribeQos qos = new SubscribeQos(global);
   <key queryType="XPATH">//airport</key>

The configuration of the plugin happens in the xmlBlasterPlugin.xml file.

   <!--========== SubscriptionPersistencePlugin =============-->
   <plugin id='subPersistence' className='org.xmlBlaster.engine.SessionPersistencePlugin'>
      <action do='LOAD' onStartupRunlevel='3' sequence='1' />
      <action do='STOP' onShutdownRunlevel='2' sequence='6'/>
It is important that it is started after runlevel 2 in order to assure that the topics are there when sessions and subscriptions are recovered. The logical place where to do it is on runlevel 3. Since this runlevel is the one on which communication plugins are loaded it is important that subPersistence is loaded before the communication plugins are (by choosing a higher sequence number on load for the communication plugins).
The name subPersitence specified as the plugin id is not important since the plugin registers itself as a listener.

The configuration of the size of the storage
All persistent subscriptions are stored on the same storage which is configurable on server side (the same way as the msgUnitStore and persistent sessions). You can either pass the parameters in the xmlBlaster.properties file:

persistence/subscribe/maxEntriesCache = 10
persistence/subscribe/maxEntries = 200
or on the command line when starting xmlBlaster:
   java org.xmlBlaster.Main \
   -persistence/subscribe/maxEntriesCache 10 \
   -persistence/subscribe/maxEntries 200

NOTE: Configuration parameters are specified on command line (-someValue 17) or in the xmlBlaster.properties file (someValue=17). See requirement "util.property" for details.
Columns named Impl tells you if the feature is implemented.
Columns named Hot tells you if the configuration is changeable in hot operation.

See REQ client.failsafe
See REQ engine.persistence.session
See API org.xmlBlaster.engine.I_SessionPersistencePlugin
See TEST org.xmlBlaster.test.client.TestPersistentSession

This page is generated from the requirement XML file xmlBlaster/doc/requirements/engine.persistence.subscription.xml

Back to overview