Sorry for the long delay. My e-mail application flagged your reply as junk
mail and moved it into the trash, so I only just noticed it. I'm using Mac
OS X which has JDK 1.3.1 on it. Here's the info:
% java -version
java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build
Java HotSpot(TM) Client VM (build 1.3.1, mixed mode)
In case you're interested in the Mac OS version info:
ProductName: Mac OS X
I'll play with it a little more and see if I can figure anything out. I
might have been doing something wrong.
Thanks for the reply!
On 2/14/02 6:24 PM, "Bela Ban" <bela@...> wrote:
> Rob Eden wrote:
> Actually this is a pretty good question for the developers mailing list, =
> I'll cross-post my answer here.
>> 1) I got two clients for the Draw demo up and running. Then I pulled the
>> network plug on one of the clients. I noticed that messages are buffered=
>> because the client I pulled the plug on is updated when I plug it back i=
>> What are the limits on this? When does it stop keeping a log and declare=
>> client "dead"? I'm not sure if this is a function of JavaGroups or the d=
> Assuming the 1.0 properties for Draw, you are using the FD_SOCK protocol =
> failure detection (please check this). This means a member will not be
> dead until it closes its socket (e.g. crashes). Pulling the plug on the N=
> CTRL-Z'ing will *NOT* declare that member dead, therefore not remove it. =
> means that your network buffer at the client will just fill up, until pac=
> are discarded. When you put the plug back in, those messages should be
> delivered, plus the dropped ones should be retransmitted. I haven't tried=
> one out though.
> Actually, one bad side effect of this is that, since your obnoxious membe=
> never be removed from the group, the remaining members will not be able t=
> garbage collect messages seen by all members (since this member never ack=
> messages), so the message tables of all members will grow.
> If you want this member to be removed from the group, what you want to do=
> use FD instead of FD_SOCK, and configure it with a timeout such that the
> will be removed when it doesn't reply to heartbeat for n number of second=
> m tries). You can also use shun=3Dtrue in GMS. This will make the member co=
> suicide when it comes back up (it will be 'shunned' (=3Dexcluded from the g=
> by the other members).
>> 2) The 1.0 release on Sourceforge says it's i386 only while all the othe=
>> releases say platform independent (like I would expect). What's up with
>> that? Is it really Windows only? I did try running a client on Mac OS X =
>> didn't seem to work, so it seems like it's not platform independent.
> No, the reason was that when we put out 1.0, there was no
> 'platform-independent' option on SourceForge, so I chose i386. It *should=
> on Mac: JavaGroups is 100% Java, so there shouldn't be a problem. I know
> are using it on Linux, Solaris, Windows. I haven't heard of any Mac users
> though. Which JDK are you using ? What are the error messages ?
> Bela Ban
> Fujitsu Network Communications
> (408) 895-1732
> =AD=C7=9F=A2=B8=1E=02w=AD=86=DBi=B0=0F=FF=96+-=B0=0B(=BA=B7=1E~=8A=E0x =DE=B7=F9b=B2=DB?=96+-=8Aw=E8=FE6=AFj
Rob Eden E-mail: rob@...
StarLight Systems Web: http://www.starlight-systems.com
"If there is a better solution... find it."
- Thomas Edison