[xmlblaster-devel] Experimental CVS main branch

[Marcel Ruff <marcel at marcelruff.info>]

Hi

the cvs main branch is since today very experimental!

I have committed the newest coding which contains an implementation of

 
http://www.xmlblaster.org/xmlBlaster/doc/requirements/engine.message.lifecycle.html

If you don't need to deliver your application the next weeks
feel free to update to the newest, be prepared to experiments though
as the testuite fails at some parts.
Please report any problems (if possible with an example client).

NOTE: Please use the new xmlBlaster.properties:
  cp xmlBlaster/config/xmlBlaster.properties.template 
$HOME/xmlBlaster.properties


1. How to go back to the old code:

 cvs co -P -r BEFORE_HISTORY_EXPIRY xmlBlaster

This is the code before my changes.


2. We now need Postgres or Oracle for persistent queues (both is 
tested), see

 
http://www.xmlblaster.org/xmlBlaster/doc/requirements/queue.jdbc.postgres.html
 http://www.xmlblaster.org/xmlBlaster/doc/requirements/queue.html

describes how to setup Posgresql
Note: On a Linux box there is usually Postgres
     installed and you only need to type:
 initdb /tmp/postgres/data
 (cp /var/lib/pgsql/data/pg_hba.conf /tmp/postgres    (edit host access))
 postmaster -i -N 256 -B 512 -D /tmp/postgres/data
 createdb test

 Probably one day some native persistence plugin follows (reusing
 the code from our recorder persistency).


3. If you don't use a database you can switch to pure RAM based operation

Edit xmlBlaster.properties and change 'CACHE' to 'RAM':

  #msgstore.defaultPlugin=CACHE,1.0
  msgstore.defaultPlugin=RAM,1.0
  #queue.defaultPlugin=CACHE,1.0
  queue.defaultPlugin=RAM,1.0

This avoids ugly errors on console if the database is not found.


4. The next days ...

We work on stabilizing this code base (tomorrow i'm not working :-).
This new framework finally supports tranparently swapping of huge queues and
addresses the 'volatile-message' bugs in the old code base.
Additionally extended message expiry support and one day history
message access is available.

The C++ client library is under heavy development to support fail save
connections and all QoS.

The Java client library will get the persistent queues integrated the
next weeks to support priority based swapping on huge message amounts as 
well.


best regards,

Marcel