Replied: Sat, 29 Mar 2003 20:56:39 -0500 Replied: "alex ho" Return-Path: alexho@anabas.com Delivery-Date: Sat Mar 29 20:46:45 2003 Return-Path: Received: from round.uits.indiana.edu (round.uits.indiana.edu [129.79.1.72]) by grids.ucs.indiana.edu (8.10.2+Sun/8.10.2) with ESMTP id h2U1kjC02055 for ; Sat, 29 Mar 2003 20:46:45 -0500 (EST) Received: from gull.mail.pas.earthlink.net (gull.mail.pas.earthlink.net [207.217.120.84]) by round.uits.indiana.edu (8.12.8/8.12.8/IUPO) with ESMTP id h2U1nwar010855 for ; Sat, 29 Mar 2003 20:49:58 -0500 (EST) Received: from user-38lc0un.dialup.mindspring.com ([209.86.3.215] helo=anabasdellcpx) by gull.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 18zRxO-000654-00; Sat, 29 Mar 2003 17:49:58 -0800 Message-ID: <000c01c2f65f$0f43c1e0$8a00a8c0@anabasdellcpx> Reply-To: "alex ho" From: "alex ho" To: Cc: "alex ho" References: <3E86312B.2040605@grids.ucs.indiana.edu> Subject: Re: FYI Date: Sat, 29 Mar 2003 17:52:44 -0800 Organization: anabas, inc MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C2F61C.0016B300" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Length: 6667 This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C2F61C.0016B300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable is this flow control design in jvm or messaging=20 system problem? does sun jvm behave differently from jview, and does it happen with anabas on sonicmq?=20 ----- Original Message -----=20 From: Geoffrey Fox=20 To: alex ho=20 Sent: Saturday, March 29, 2003 3:50 PM Subject: FYI -------- Original Message -------- Subject: The NB bug/stall=20 Date: Sat, 29 Mar 2003 18:11:39 -0500=20 From: "Shrideep Pallickara" =20 To: =20 The NB/Anabas bug happens when a JVM thinks that a socket is valid, when = in fact it is not. This scenario arises when a network connection is = removed abruptly or reboots (which is what students did which exposed the = problem). Now if you send data on the output stream on this socket, it continues = to work till its buffer size is reached. After that it blocks pending = clearance of this buffer. No operations can proceed beyond this point and any sends/receives are stalled. After 1-2 mins the JVM detects that the socket connection is indeed = lost. After the blocked-method call returns, all data that was stalled is released. This is a slightly difficult problem, and some pinging scheme needs to = be built on top of this to ensure that the block doesn't occur. = Theoretically though this slow down will still take place if the data being sent is = larger than buffer size and if the check returns socket is connected. If the = link is now removed precisely after the check the stalling would still take place. The problem is slightly compounded by the fact that the output stream = Buffer returned on the socket does not provide an estimate of its size but = rather only about the total number of bytes that have been sent over the = socket's output stream. I have been working on fixing this bug, just though I would bring you abreast with the efforts. Will keep you posted. Shrideep --=20 : : Geoffrey Fox gcf@indiana.edu FAX 8128567972 : Phones Cell 315-254-6387 Home 8123239196 Lab 8128567977 CS 8128553788 ------=_NextPart_000_0009_01C2F61C.0016B300 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

is this flow control design in jvm = or=20 messaging

system problem? does sun jvm behave=20 differently

from jview, and does it happen with = anabas on=20 sonicmq?

----- Original Message -----

From:=20 Geoffrey Fox

To: alex ho

Sent: Saturday, March 29, 2003 = 3:50=20 PM

Subject: FYI

--------=20 Original Message --------=20

Subject:	The NB bug/stall
Date:	Sat, 29 Mar 2003 18:11:39 -0500
From:	"Shrideep Pallickara" "><spallick@indiana.edu>
To:	"><gcf@indiana.edu>

The NB/Anabas bug happens when a JVM thinks =
that a socket is valid, when in
fact it is not. This scenario arises when a network connection is =
removed
abruptly or reboots (which is what students did which exposed the =
problem).

Now if you send data on the output stream on this socket, it continues =
to
work till its buffer size is reached. After that it blocks pending =
clearance
of this buffer. No operations can proceed beyond this point and any
sends/receives are stalled.

After 1-2 mins the JVM detects that the socket connection is indeed =
lost.
After the blocked-method call returns, all data that was stalled is
released.

This is a slightly difficult problem, and some pinging scheme needs to =
be
built on top of this to ensure that the block doesn't occur. =
Theoretically
though this slow down will still take place if the data being sent is =
larger
than buffer size and if the check returns socket is connected. If the =
link
is now removed precisely after the check the stalling would still take
place.

The problem is slightly compounded by the fact that the output stream =
Buffer
returned on the socket does not provide an estimate of  its size but =
rather
only about the total number of bytes that have been sent over the =
socket's
output stream.

I have been working on fixing this bug, just though I would bring you
abreast with the efforts. Will keep you posted.


Shrideep

--=20
:
: Geoffrey Fox  gcf@indiana.edu FAX 8128567972
: Phones Cell 315-254-6387 Home 8123239196 Lab 8128567977 CS =
8128553788

------=_NextPart_000_0009_01C2F61C.0016B300--