|Topic||XmlBlaster supports sessions and subscriptions which persist a server crash.|
Persistent sessions 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 session can either be made persistent explicitly by passing the
The benefit of having persistent sessions is that:
Persistence of sessions 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.
Once you have made a session persistent and you are reconnecting, the new connection will ignore the persistent flag. Once made persistent, the session will remain persistent.
ConnectQos qos = new ConnectQos(global); qos.setSessionName(new SessionName(global, "fritz/1"); /* sets the session to be persistent */ qos.setPersistent(true); /* sets the callback connection to be failsafe */ CallbackAddress cbAddr = new CallbackAddress(global); cbAddr.setRetries(-1); cbAddress.setPingInterval(-1); cbAddress.setDelay(1000L); qos.addCallbackAddress(cbAddress);
<qos> <securityService type="htpasswd" version="1.0"><![CDATA[ <user>happyUser</user> <passwd>secret</passwd> ]]&bt;</securityService> <persistent/> <!-- same as <persistent>true</persistent> --> <session name='yourName/6' /> <queue relating='connection'> <address pingInterval='0' retries='-1' delay='2000' /> </queue> <queue relating='callback' maxEntries='5' maxEntriesCache='2'> <callback pingInterval='0' retries='-1' delay='1000' /> </queue> </qos>
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
The configuration of the size of the storage
.... persistence/session/maxEntriesCache = 10 persistence/session/maxEntries = 200 ....or on the command line when starting xmlBlaster:
java org.xmlBlaster.Main \ -persistence/session/maxEntriesCache 10 \ -persistence/session/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.
A flag to the ConnectQos must be added for the initial status of the DispatcherManager belonging to this session: 'dispatcherActive'. Additionally, everytime an invocation on SessionInfo.setDispatcherActive(boolean) is done, an update on the DB must be done to ensure the status will be correct when reconnecting after a server crash.
This page is generated from the requirement XML file xmlBlaster/doc/requirements/engine.persistence.session.xml
Back to overview