Bela -
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
1.3.1-root-010902-18:51)
Java HotSpot(TM) Client VM (build 1.3.1, mixed mode)
In case you're interested in the Mac OS version info:
% sw_vers
ProductName: Mac OS X
ProductVersion: 10.1.3
BuildVersion: 5Q45
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!
Rob
On 2/14/02 6:24 PM, "Bela Ban" <bela@...> wrote:
>=20
> Rob Eden wrote:
>=20
> Actually this is a pretty good question for the developers mailing list, =
so
> I'll cross-post my answer here.
>=20
>=20
>> 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=
up
>> because the client I pulled the plug on is updated when I plug it back i=
n.
>> What are the limits on this? When does it stop keeping a log and declare=
the
>> client "dead"? I'm not sure if this is a function of JavaGroups or the d=
emo
>> program.
>=20
> Assuming the 1.0 properties for Draw, you are using the FD_SOCK protocol =
for
> failure detection (please check this). This means a member will not be
> declared
> dead until it closes its socket (e.g. crashes). Pulling the plug on the N=
IC,
> or
> CTRL-Z'ing will *NOT* declare that member dead, therefore not remove it. =
This
> means that your network buffer at the client will just fill up, until pac=
kets
> 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=
this
> one out though.
>=20
> Actually, one bad side effect of this is that, since your obnoxious membe=
r
> will
> never be removed from the group, the remaining members will not be able t=
o
> garbage collect messages seen by all members (since this member never ack=
s any
> messages), so the message tables of all members will grow.
>=20
> If you want this member to be removed from the group, what you want to do=
is
> to
> use FD instead of FD_SOCK, and configure it with a timeout such that the
> member
> will be removed when it doesn't reply to heartbeat for n number of second=
s (or
> m tries). You can also use shun=3Dtrue in GMS. This will make the member co=
mmit
> suicide when it comes back up (it will be 'shunned' (=3Dexcluded from the g=
roup)
> by the other members).
>=20
>=20
>=20
>> 2) The 1.0 release on Sourceforge says it's i386 only while all the othe=
r
>> 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 =
that
>> didn't seem to work, so it seems like it's not platform independent.
>=20
> 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=
*
> work
> on Mac: JavaGroups is 100% Java, so there shouldn't be a problem. I know
> people
> 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 ?
>=20
>=20
>=20
> --
> Bela Ban
> Fujitsu Network Communications
> (408) 895-1732
>=20
>=20
> =8D=AB=DA=82=BA.=A6=C0.=B1=EA=EC=02f=A2=96)=E0=02X=AC=B4=08=DA=BD=A8+=A2=EAl=02=EB=1E=AE=C0%=8A=CBl=02=CA.
> =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
=E8=BA=9B=BA=C7=AB
Rob
--=20
Rob Eden E-mail: rob@...
StarLight Systems Web: http://www.starlight-systems.com
"If there is a better solution... find it."
- Thomas Edison
|