Re: [Vrs-development] CMM Messages

[Bill Lance]

--- Chris Smith <address@hidden> wrote:
> Just a few quick points, I'll do more later.....
 It's a configuration parameter.  If you've got lots
> of
> memory, then you can allocate more (without
> incurring
> hideous paging!)
> 

This brings a question to mind.  How does GW get
configured in the first place?  It faces the same
configuration issues that the VRS does.  It starts
with only one, other nodes are added, and the original
one may drop off line.  A new instance of GW must
start each time a LDS comes online and sync with the
other GW components to other LDS's.  If GW
configuration data is not carried in the CI, you will
still have to accomplish similar mirroring tasks.


> > > So an LDS would contact another LDS (I was
> thinking
> > > via
> > > the webService access port because that's the
> public
> > > bit)
> > > and 'subscribe' to the VRS.  If accepted, it's
> > > GWDomain
> > > details would be added to Goldwaters runtime
> config.
> >
> > It sounds like there are certainly going to be
> > overlaps in the data GW needs and the Cluster
> Image.
> > Can we move those GW tables into the CI?
> 
> GW will handle all the communication and message
> routing
> between LDSs.  As such it needs to know about each
> LDS
> (that GW is told about dynamically by the CI
> manager).
> GW takes care of whether LDSs (as they are
> GWDomains) are
> up/down etc.
> Knowledge of an GWDomain (LDS) will persist until GW
> is
> rebooted 

But again, GW is PART of an LDS.  It can't be rebooted
without bringing the whole LDS down and up.  And
that's still only a particular node.

or the CI manager tells GW that it has
> unsubscribed.
> 
> So the overlap is just that an LDS needs to know
> about
> all the other LDSs, and so does GW.
> ie:
> GW   sees them as GWDomains,
> LDSs see them as other LDSs.
> 
> The only way for one LDS to send msgs to another LDS
> is
> via GW:
> 
> Here the CIM on LDS A sends a message to CIM on LDS
> B.
> It gets there by dropping into the Goldwater layer
> where
> it gets routed and sent.
> 
>          LDS A                           LDS B
> 
>     -----------------            
> -------------------
> CIM     msg -->--+                   +-->-- msg     
>     -------------|---            
> ---|---------------
> GW               +------>------>-----+
>     -----------------            
> -------------------
> 
> 
> - What LDSs comprise the Cluster is a CI issue, and
> so that
>    information is held in the CI.
> - Where LDSs are and whether they are available etc
> is a 
>    Goldwater issue, as GW handles all network comms
> and 
>    routing.
> 
> The CI may look at GW's tables to see if an LDS is
> available
> before sending a message.  Even if GW says that it
> is available,
> the message may fail to be sent, and so GW will
> update its
> tables to reflect this and provide feedback to the
> CI.
> 
> So I wouldn't say it's an overlap - more of common
> data.
> This common data cannot reside in an application
> built on top
> of Goldwater because GW knows nothing about the
> application.
> 
> Applications however know everything about
> Goldwater, and can
> thus freely access any data/tables that Goldwater
> exposes.
> 
> Besides, without GW knowing about ip/port and
> availability
> of other GWDomains, then it's not going to be able
> to do
> anything is it???? :o)
> 
> 


In the LDS block diagram in the Docs, would it make
sense to place the GW component bwwteen the port
manager and the others?  Like this?


______________________
|      Port Mang      |
-----------------------
|          GW         |
-----------------------
| RM    |  CM    | SM |
|       |        |    |




__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com