REQUIREMENT engine.persistence.subscription |
Type | NEW |
Priority | HIGH |
Status | CLOSED |
Topic | XmlBlaster supports sessions and subscriptions which persist a server crash. |
Des cription |
Persistent subscriptions will persist a server crash. After such a crash they are
reestablished during the recovery process.
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
A subscription is made persistent explicitly by passing the 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:
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. Exceptions:
|
Example Java |
.... SubscribeQos qos = new SubscribeQos(global); qos.setPersistent(true); .... |
Example XML |
<key queryType="XPATH">//airport</key> <qos><persistent>true</persistent></qos> |
Configure |
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'/> </plugin> ....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
.... 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. |
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