Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Date: Sun, 31 Oct 2004 19:54:25 -0800
From: Craig Johannsen <cjohan@shaw.ca>
Subject: Re: Weird build errors on SuSE 9.2
In-reply-to: <Pine.LNX.4.58.0410311828200.31956@saturn.opentools.org>
To: dev@geronimo.apache.org
Message-id: <4185B371.1010700@shaw.ca>
MIME-version: 1.0
Content-type: multipart/alternative;
 boundary=------------020804050503020103070509
References: <Pine.LNX.4.58.0410310839070.25578@saturn.opentools.org>
 <418500AD.7060102@gluecode.com>
 <Pine.LNX.4.58.0410311414120.31187@saturn.opentools.org>
 <418568A8.2010400@shaw.ca>
 <Pine.LNX.4.58.0410311718420.31956@saturn.opentools.org>
 <Pine.LNX.4.58.0410311828200.31956@saturn.opentools.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
 Netscape/7.1

This is a multi-part message in MIME format.
--------------020804050503020103070509
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi Aaron,

My environment is Mandrake Linux 9.1, kernel 2.4.2-0.13, libc-2.3.1, 651 
MHz Pentium III (Coppermine), and KDE shell. I tested your code with 
J2SDK 1.4.2_03-b02, mixed mode, and JDK 1.5.0-rc-b63, mixed mode, 
sharing. In each case the socket timeout didn't work using ssc.accept(). 
It would wait indefinately, just as the ServerSocketChannel.accept() API 
documentation says it will: " If this channel is in non-blocking mode 
then this method will immediately return null if there are no pending 
connections. Otherwise it will block indefinitely until a new connection 
is available or an I/O error occurs." The ServerSocket.accept() API 
documentation erroneously says: "Listens for a connection to be made to 
this socket and accepts it. The method blocks until a connection is 
made." However, at least it also says it may throw: 
"SocketTimeoutException 
<http://java.sun.com/j2se/1.4.2/docs/api/java/net/SocketTimeoutException.html> 
- if a timeout was previously set with setSoTimeout and the timeout has 
been reached." So, the behaviour is mostly following the documentation, 
though I would like to see ServerSocketChannel.accept() pay attention to 
the timeout setting. I can't think of any reason it shouldn't. Probably 
it's a bug, but maybe a bug in the spec, assuming the API docs are correct.

Unfortunately, if you use ServerSocket instead of ServerSocketChannel, 
you lose all those nifty ByteBuffer operations. So, maybe it is a big 
change and much less efficient to use input and output streams rather 
than ByteBuffers.

Cheers,
Craig


Aaron Mulder wrote:

>On Sun, 31 Oct 2004, Aaron Mulder wrote:
>  
>
>>	Right.  The question is, are we willing to change our code to 
>>accomodate a bug that, so far, only I am running into?  :)  I sent bug 
>>reports to Sun and SuSE, but I suspect they'll go to the great bit bucket 
>>in the sky, since SuSE 9.2 isn't a supported platform for Sun, and I doubt 
>>SuSE cares that much about JDK problems.
>>
>>	Though, I guess I should ask, how were you able to duplicate the 
>>problem?  Do you also have a SuSE 9.2 machine, or did you do it on some 
>>other platform/kernel?
>>
>>Thanks,
>>	Aaron
>>
>>On Sun, 31 Oct 2004, Craig Johannsen wrote:
>>    
>>
>>>Hi Aaron,
>>>
>>>"ssc.socket().accept()" throws a SocketTimeoutException, while 
>>>"ssc.accept()" does not. One would think that they would have identical 
>>>behaviour, but apparently not. Here's an example where the socket 
>>>timeout works with both JDK 1.4.2_03 and JDK 1.5.
>>>
>>>Cheers,
>>>Craig
>>>
>>>import java.io.IOException;
>>>import java.net.*;
>>>import java.nio.channels.*;
>>>
>>>// This code hangs on some Linux systems.
>>>public class Hang {
>>>public static void main(String[] args) {
>>>try {
>>>ServerSocketChannel ssc = ServerSocketChannel.open();
>>>ssc.configureBlocking(true);
>>>ssc.socket().bind(new InetSocketAddress(InetAddress.getLocalHost(), 
>>>2010),50);
>>>ssc.socket().setSoTimeout(5000);
>>>System.out.println("accepting...");
>>>ssc.socket().accept();
>>>} catch (IOException e) {
>>>e.printStackTrace();
>>>}
>>>System.out.println("Finished");
>>>}
>>>}
>>>
>>>      
>>>
>

--------------020804050503020103070509
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=US-ASCII">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
Hi Aaron,<br>
<br>
My environment is Mandrake Linux 9.1, kernel 2.4.2-0.13, libc-2.3.1,
651 MHz Pentium III (Coppermine), and KDE shell.&nbsp; I tested your code
with J2SDK 1.4.2_03-b02, mixed mode, and JDK 1.5.0-rc-b63, mixed mode,
sharing.&nbsp; In each case the socket timeout didn't work using
ssc.accept().&nbsp; It would wait indefinately, just as the
ServerSocketChannel.accept() API documentation says it will: " If this
channel is in non-blocking mode then this method will immediately
return <tt>null</tt> if there are no pending connections. Otherwise it
will block indefinitely until a new connection is available or an I/O
error occurs."&nbsp; The ServerSocket.accept() API documentation erroneously
says: "Listens for a connection to be made to this socket and accepts
it. The method blocks until a connection is made."&nbsp;&nbsp; However, at least
it also says it may throw: "<code><a
 href="http://java.sun.com/j2se/1.4.2/docs/api/java/net/SocketTimeoutException.html"
 title="class in java.net">SocketTimeoutException</a></code> - if a
timeout was previously set with setSoTimeout and the timeout has been
reached."<code></code>&nbsp; So, the behaviour is mostly following the
documentation, though I would like to see ServerSocketChannel.accept()
pay attention to the timeout setting.&nbsp; I can't think of any reason it
shouldn't.&nbsp; Probably it's a bug, but maybe a bug in the spec, assuming
the API docs are correct.<br>
<br>
Unfortunately, if you use ServerSocket instead of ServerSocketChannel,
you lose all those nifty ByteBuffer operations.&nbsp; So, maybe it is a big
change and much less efficient to use input and output streams rather
than ByteBuffers.<br>
<br>
Cheers,<br>
Craig<br>
<br>
<br>
Aaron Mulder wrote:<br>
<blockquote type="cite"
 cite="midPine.LNX.4.58.0410311828200.31956@saturn.opentools.org">
  <pre wrap="">On Sun, 31 Oct 2004, Aaron Mulder wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">	Right.  The question is, are we willing to change our code to 
accomodate a bug that, so far, only I am running into?  :)  I sent bug 
reports to Sun and SuSE, but I suspect they'll go to the great bit bucket 
in the sky, since SuSE 9.2 isn't a supported platform for Sun, and I doubt 
SuSE cares that much about JDK problems.

	Though, I guess I should ask, how were you able to duplicate the 
problem?  Do you also have a SuSE 9.2 machine, or did you do it on some 
other platform/kernel?

Thanks,
	Aaron

On Sun, 31 Oct 2004, Craig Johannsen wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">Hi Aaron,

"ssc.socket().accept()" throws a SocketTimeoutException, while 
"ssc.accept()" does not. One would think that they would have identical 
behaviour, but apparently not. Here's an example where the socket 
timeout works with both JDK 1.4.2_03 and JDK 1.5.

Cheers,
Craig

import java.io.IOException;
import java.net.*;
import java.nio.channels.*;

// This code hangs on some Linux systems.
public class Hang {
public static void main(String[] args) {
try {
ServerSocketChannel ssc = ServerSocketChannel.open();
ssc.configureBlocking(true);
ssc.socket().bind(new InetSocketAddress(InetAddress.getLocalHost(), 
2010),50);
ssc.socket().setSoTimeout(5000);
System.out.println("accepting...");
ssc.socket().accept();
} catch (IOException e) {
e.printStackTrace();
}
System.out.println("Finished");
}
}

      </pre>
    </blockquote>
  </blockquote>
  <br>
</blockquote>
</body>
</html>

--------------020804050503020103070509--