[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster] Updated cluster requirements
Hugues Jerome wrote:
Marcel Ruff (ruff at swand.lake.de):
Hi
after some discussion with Heinrich, here is a
new version.
http://www.xmlblaster.org/xmlBlaster/doc/requirements/cluster.html
comments (in any langauge) are welcome
konichiwa minnasan, daijobu desu ka.
Michele, please translate.
bon, ok j arrete la
Merci.
-----------------------------------------------------------
My two cents regarding this feature (note that I do not know
the internals of xmlBlaster, so I may be sometimes wrong)
*) You speak about discovery and lookup, but not about the internal
configuration. I do understand the lazy login concept to build a tree,
but some other concepts are missing : how do I setup my node as a master,
do you want this caracteristic to be static or not ?
The internal message
<key oid='__sys__cluster.node.master:heron'>
has a list of message domains which define 'heron'
as a master.
Such a __sys__ message with other domains may be re-published by
a client or an administrator or an domainManagerBusinessObject
which reconfigures the master setup dynamically.
see
http://www.xmlblaster.org/xmlBlaster/doc/requirements/cluster.html
(the example section at the very bottom).
how do I set
certain aspects of the topological tree (like 1. scalability ?)
You are right this is missing.
I will address it.
(by static I mean that cannot be changed during runtime)
*) Regarding the features :
if you look at 'connections between xmlblaster instances', my
understanding is that if a node do not have the requested message,
then it subscribes directly to the master node. this is too restrictive
and prevent building a tree structure .. depending how you read 'the'
take diagramm 1., bilbo will directly subscribes to heron(labelled as
master), bypassing frodo (labelled as slave)
hence 'the master' is not precise enough.
Yes, we need some configuration possibility, thanks for
pointing on it!
(it seems you implicitly do that in 'routing published messages', but
stating the obvious is sometimes not bad ;))
Yes again.
this loop back to the first point, and requires the precise definition
of 'master' and 'slave' in your context, the way such a relation is
defined and handled during runtime
(or at least comment the examples, they seem to provide some useful
information I cannot read: __sys__cluster.node.master)
case 1. and 3. are similar to some multicasting problems, this may
be a key to a solution
Could you explain further please?
thanks for your valuable feedback
mer lernt jo immer dazue (- Michele please translate.)
regards,
Marcel
--
Marcel Ruff
mailto:ruff at swand.lake.de
http://www.lake.de/home/lake/swand/
http://www.xmlBlaster.org