Bela,
Thank you for your response.
Regarding the gossip server: My thinking was that if there were a known
gossip server, then at least for the startup case, a merge should not be
necessary? And likewise, as long as members are able to contact the gossip
server, merges shouldn't occur? Or am I missing the point of the gossip
server?
Regarding pbcast: In reading the pbcast README, it seemed as if pbcast
could be faster, but VS was safer. That was why I was initially thinking of
using VS instead. However, it sounds like pbcast is the recommended
default, so I'll stick with that.
Regarding state transfer paper: Thank you, I'll check it out. FYI, I'm not
sure if other readers are running into this problem, but in Windows XP,
those files are downloaded as .gz files (i.e. state.ps.gz), but they seem to
already be uncompressed.
Thank you again for your help, it is greatly appreciated.
Best Regards,
Lyle
-----Original Message-----
From: Bela Ban [mailto:belaban@xxxxxxxxx]
Sent: Friday, August 15, 2003 5:13 PM
To: Lyle Fong
Cc: javagroups-users@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: [javagroups-users] Some questions
Hi Lyle,
inline
> 1) It seems that most of the building blocks, such as
> DistributedLockManager, DistributedHashtable, NotificationBus, etc..
> do not
> deal with the view merge case.
Right. What we should do is to call the app in such a case, compute a
new state and refresh the hastables/trees.
Shouldn't be difficult, but has to be done for ca. 4 similar building
blocks: DistributedHashtable, ReplicatedHashtable, DistrTree and ReplTree.
> For instance: I start two JVM instances of
> DistributedHashtable at the same time. When they start up, neither see the
> other on the network. After a few seconds, they find each other and do a
> merge, but they do not attempt to sync their states.
Correct. Merging is not supported.
> The situation seems
> worse with the DistributedLockManager, where if both instances acquire a
> lock, then after the merge, neither can release the lock.
Yep
> Is the problem because of the channel properties I'm using?
No.
> Or is it assumed that these
> cases should be dealt with using a gossip server?
No, GossipServer is orthogonal to merging.
> 2) Since the cluster runs in a LAN environment, I initially wanted to
> avoid
> using the pbcast protocols.
Why ? pbcast is just a misnomer, it is only PBCAST that runs best across
a WAN. default.xml for instance is based on pbcast.*
> However, I ran into a problem with
> STATE_TRANSFER: When a member requests a state transfer, all members seem
> to get that request.
Yes, with your stacck below (vsync) this is the case, with
pbcast.STATE_TRANSFER this is not the case. Read my paper on state
transfer to get a deeper understanding of the diffs.
> 3) Within the same JVM, is there an official stance as to whether channels
> and building blocks can be used without external synchronization?
Channel is completely synchronized. Building blocks: some are, some are not.
Bela
-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
|
