[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):


after some discussion with Heinrich, here is a
new version.


comments (in any langauge) are welcome

konichiwa minnasan, daijobu desu ka.

Michele, please translate.

bon, ok j arrete la


----------------------------------------------------------- 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.

(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.)


Marcel Ruff
mailto:ruff at swand.lake.de