[Red5] SharedObject Replication
jwamicha at gmail.com
Thu Jan 11 07:07:51 EST 2007
I haven't gone through the JBoss Cache doc too well as well as Red5 sources
(haven't had enough time yet to go through it well!) so please correct me if
createSharedObject seems a good place ; you could probably add a new
createSharedObject method to red5 with another extra parameter called
ie scope.createSharedObject(IScope scope, String name, Boolean persistent,
Also maybe add a new red5 getSharedObject function with an added boolean
field again for replicable
ie getSharedObject(IScope scope, String name, Boolean persistent, Boolean
The new methods could go to the file
Add these 2 methods to the ISharedObjectService interface which
If replicable true then create object using JBoss Cache so that on
setAttribute function, you can grab the JBoss Cache shared object whether
persistent or transient.
i require SO replication as RED5 will be running in JBoss Cluster.
So far i have got most of it working using JBossCache. However there
needs to be a cleaner encapsulation of the replication model to allow
various replication subsystem to be plugged in.
The persistant model is also handled by JBossCache with the CacheLoader.
Any suggestions of appropiate encapsulation into the existing code base
is most appreciated.
A quick look would seem to identify the following
1) create sub classes of SharedObject ( SharedObjectReplication )
2) configure the SharedObjectService.createSharedObject as an appropiate
point to load the replicated version.
3) Hide all the replication crap inside the SharedObjectReplication.
4) The replication notification listener ( used to identify changes to
SharedObject in other nodes) can be part of the Application and call the
neccessary setAttribute/removeAttribute as neccessary.
any ideas are most appreciated.
C is forever.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Red5