Re: Getting it to all work on HPUX

James

I did what you suggested..  Adding sleep didn't help the situation but
commenting out the getsockopt check did.  I can now connect successfully.
It's kind of hack so I would love to figure out the root cause and fix it
but at this point I will take what I can get.. :)



-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of James K. Lowden
Sent: Tuesday, February 03, 2009 6:07 PM
To: FreeTDS Development Group
Subject: Re: [freetds] Getting it to all work on HPUX

Michael Warchut wrote:
> net.c:210:Connecting to 172.16.20.32 port 1433 (TDS version 8.0)
> 
> net.c:264:tds_open_socket: connect(2) returned "Operation now in
> progress"
> 
> net.c:295:getsockopt(2) failed: Invalid argument
> 
> util.c:334:tdserror(6000000000010550, 6000000000038a40, 20009, 22)
> 
> odbc.c:2032:msgno 20009 20003


What's really, really peculiar is this:

	net.c:295:getsockopt(2) failed: Invalid argument

Of course, it's possible to pass an invalid argument, but how to explain
that that message appears *only* for the ODBC call?  The call to
getsockopt(2) isn't on a branch.  For some reason, it worked one time and
failed another.  The code:


	/* check socket error */
	optlen = sizeof(len);
	len = 0;
	if (getsockopt(tds->s, SOL_SOCKET, SO_ERROR, (char *) &len, &optlen)
!=
0) {
		tds->oserr = sock_errno;
		tdsdump_log(TDS_DBG_ERROR, "getsockopt(2) failed: %s\n",
strerror(sock_errno));
		goto not_available;
	}
	if (len != 0) {
		tds->oserr = sock_errno;
		tdsdump_log(TDS_DBG_ERROR, "getsockopt(2) reported: %s\n",
strerror(len));
		goto not_available;
	}

	tdsdump_log(TDS_DBG_ERROR, "tds_open_socket() succeeded\n");
	return TDSEOK;


At this level, the two APIs are identical.  That one connection request
came through ODBC and the other tsql is totally meaningless.  

We need the call to getsockopt.  That's how one discovers if a nonblocking
socket connects.  

According to your getsockopt(2) manual page, is it valid to pass SO_ERROR
to a socket, or not? 

My guess?  My guess is that it's race: if getsockopt is called too soon
after connect(2), it fails.  

You might try inserting a sleep(3) in there, just to see.  You could also
comment out the calls to getsockopt and always return TDSEOK.  That won't
help you when there's a failure, but it will make a big difference when
there's a successful connection!  

HTH.  Let us know how it goes.  

--jkl




_______________________________________________
FreeTDS mailing list
[email protected]
http://lists.ibiblio.org/mailman/listinfo/freetds