At 01:09 13.01.98 GMT, Christos Zoulas wrote:
>In article <XFMail.980112153252.gelbardn@3jane.hurrah.com>
gelbard@ENGR.ORST.EDU writes:
>>
>>On 12-Jan-98 Christoph Badura wrote:
>>>>        java.net.SocketException: Transport endpoint is already connected
>>> 
>>>>        I've tried the exact same classes on a UltraSparc 2 solaris box
>>>>        and it worked fine. I tried again on a win95 machine and it worked
>>>>        fine. I tried on a Linux box running the exact same JDK I'm
running
>>>>        on my NetBSD box and it worked fine. But on my NetBSD box, it
dies.
>>> 
>>> Well, that's not easy to say.  We need more details.  Could you run
>>> ktrace/kdump on that Programm and send us the *relevant* results.
>>
>>Well, the trace is 600k :) I've never dont this before, but heres what
>>I think the problem is:
>>
>>2528 java     CALL  socketcall(0xe,0xefbfd3b8)
>>2528 java     RET   socketcall 0
>>2528 java     CALL  socketcall(0x3,0xefbfd2f4)
>>2528 java     RET   socketcall -1 errno -115 Unknown error: 4294967181
>>
>>Where can I find the error listing for errno -115 and the
>>'uknown error'?
>
>This is EINPROGRESS resulting from a connect to a non blocking fd.


ERR...

Guys, we've been there before. Look in the port-i386 archive for a thread
with the subject "JDK1.1.1 (L*NUX port), was Re: applix" around the end of
June 97.

The patch (against 1.2E sources) I got then which worked for me was

From: daw+@ux4.sp.cs.cmu.edu
Date: Fri, 4 Jul 97 15:02:07 EDT

*** linux_socket.c.orig	Thu Jul  3 20:02:19 1997
--- linux_socket.c	Thu Jul  3 20:10:35 1997
***************
*** 197,203 ****
  	SCARG(&bca, name) = (void *) lca.name;
  	SCARG(&bca, namelen) = lca.namelen;
  
! 	return sys_connect(p, &bca, retval);
  }
  
  int
--- 197,206 ----
  	SCARG(&bca, name) = (void *) lca.name;
  	SCARG(&bca, namelen) = lca.namelen;
  
! 	if ((error = sys_connect(p, &bca, retval)) == EISCONN)
! 		return 0; /* XXX--silently suppress EISCONN for java */
! 	else 
! 		return error;
  }
  
  int

And quoting Todd Vierling...

>X-POP3-Rcpt: hf@meloghost.melog.de
>Return-Path: tv@pobox.com
>Date: Fri, 27 Jun 1997 13:42:15 -0400 (EDT)
>From: Todd Vierling <tv@pobox.com>
>X-Sender: tv@shell
>To: "Nathaniel D. Daw" <daw@panix.com>
>cc: Hauke Fath <hf@melog.de>, port-i386@NetBSD.ORG
>Subject: Re: JDK1.1.1 (L*NUX port), was Re: applix
>Return-Receipt-To: tv@pobox.com
>
>On Fri, 27 Jun 1997, Nathaniel D. Daw wrote:
>
>: It had something to do with attempting a nonblocking connect(), which
>: either works differently under Linux  or is improperly implemented in the
>: JDK. From a ktrace, I think I found the JDK connect()s to the socket,
>: select()s for completion, and then, when the select returns that the
>: connection is complete, calls connect() a second time, getting the EISCONN
>
>Funny; Pine relies on this behavior of a nonblocking connect (the EISCONN
>return of the second call to connect()) to verify that a socket is connected
>on most OSes.  It's therefore very likely that the nb connect() procedure is
>indeed different in Linux.  If this can be verified, I suggest the fix below
>be committed to the tree for completeness's sake.
>
>: It's ugly, but you can patch the linux connect() wrapper code to silently
>: return, supressing the EISCONN, and it works fine. With no access to the
>: jdk source, nor to a real linux system, I was never able to confirm
>: exactly what was wrong.


-- Apparently the "fix" hasn't made it into the tree. Sigh. Should I send-pr?

	hauke


-- 
Hauke Fath                              Melog Software GmbH
                                        D-69115 Heidelberg
hf@Melog.DE                             Ruf +49-6221-1333-0, Fax -33