harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jimmy, Jing Lv" <firep...@gmail.com>
Subject Re: Solution on Harmony-815 (was Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
Date Tue, 18 Jul 2006 01:48:38 GMT
David Tanzer wrote:
> 
> On 17.07.2006, at 14:09, Richard Liang wrote:
> 
>>
>>
>> LvJimmy,Jing wrote:
>>> Hi Andrew:
>>>
>>> Sorry for late, but as this solution does not resolve I18N (working
>>> aound for 815 only?) , I guess we may have another way.
>>> If I understand correctly, this solution try to analysis error code in
>>> native code, throws ErrorCodeException; and java code catch this 
>>> exception,
>>> get error code, and throw another exception.
>>> If so, why not just return the error code directly instead? :)
>>>
>> Hello Jimmy,
>>
>> IIRC, It's SocketException that is thrown in native code, not 
>> ErrorCodeException. And we will set the ErrorCodeException as cause of 
>> the SocketException.
> 
> Yes, this is how I remember it too. The idea was to do the equivalent of 
> the
> following code in the native code (correct me if I'm wrong):
> 
> ErrorCodeException ece = new ErrorCodeException(SOME_ERROR_CODE);
> throw new SocketException("Some Message", ece);
> 

Yes, sorry for my mistake :)

> I don't think it is semantically correct to set the ErrorCodeException 
> as the cause
> of the SocketException - the error code provides additional info, it is 
> not the cause
> of the problem. For example, this code:
> 
> try {
>     ErrorCodeException ece = new ErrorCodeException(13);
>     throw new TestException("Something went wrong", ece);
> } catch(TestException e) {
>     e.printStackTrace();
> }
> 
> Yields the following stack trace:
> 
> net.guglhupf.test.TestException: Something went wrong
>     at net.guglhupf.test.ExceptionTest.main(ExceptionTest.java:7)
> Caused by: Error Code 13
>     at net.guglhupf.test.ExceptionTest.main(ExceptionTest.java:6)
> 
> which might be confusing for some application developer so personally
> I like the subclass - approach described by Andrew Zhang [1] better.
> 

In this case, I guess if we set the cause to null when catching the 
SocketException will properly solve the problem. However it seems 
difficult as Throwable.initCause() can be called only once.

If throwing a subclass may also break compatibility guideline, I still 
suggest return value, though it may break the current 
infrastructure(currently, all errors throw exception), it is still easy 
to deal with, only some of operation, read/write, require a little 
change, and we no longer need "try...catch" in Java code

BTW, I find the code shall also deal with InterruptIOException.

> Regards,
> David
> 
> [1] 
> http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200607.mbox/%3c4d0b24970607121958l31cc127y51ff764d58d2b3cd@mail.gmail.com%3e

> 
> 
>> I18N is anther issue, we shall have full discussion in community to 
>> mature our thoughts. :-)
>>
>> Do I miss something?
>>
>> Best regards,
>> Richard.
>>
>>>
>>> 2006/7/14, Mikhail Loenko <mloenko@gmail.com>:
>>>>
>>>> Hi Andrew
>>>>
>>>> this seems reasonable
>>>>
>>>> Thanks,
>>>> Mikhail
>>>>
>>>> 2006/7/14, Andrew Zhang <zhanghuangzhu@gmail.com>:
>>>> > Hi folks,
>>>> >
>>>> > I'd like to adopt Tim's suggestion to solve Harmony-815. It avoids
>>>> message
>>>> > comparison while keeps current luni native architecture.
>>>> >
>>>> > Before I upload a new patch to JIRA, I want to hear more voices from
>>>> > the community. Any better suggestions? Any comments?
>>>> >
>>>> > Mikhail, what's your opnion? Do you think it makes sense?
>>>> >
>>>> > Thanks in advance!
>>>> >
>>>> > Best regards,
>>>> > Andrew
>>>> >
>>>> >
>>>> > On 7/14/06, Tim Ellison <t.p.ellison@gmail.com> wrote:
>>>> > >
>>>> > > Andrew Zhang wrote:
>>>> > > > How about design a subclass which extends from SocketException,
>>>> looks
>>>> > > like:
>>>> > >
>>>> > > If you want to preserve the throwable type you could create a
>>>> > > o.a.h.luni.ErrorCodeException that has a errorCode field set by
the
>>>> > > native, and then make that the cause of the SocketException.
>>>> > >
>>>> > > The calling code would then do something like:
>>>> > > ((ErrorCodeException)ex.getCause()).getErrorCode()
>>>> > >
>>>> > > Just a thought.
>>>> > >
>>>> > > Regards,
>>>> > > Tim
>>>> > >
>>>> > >
>>>> > > > class SocketWithErrorCodeException extends SocketException
{
>>>> > > >
>>>> > > > SocketWithErrorCodeException (String message, int errorCode)
{
>>>> > > > super(message); this.errorCode = errorCode; }
>>>> > > >
>>>> > > > private int errorCode;
>>>> > > >
>>>> > > > public void get/setErrorCode() ;
>>>> > > >
>>>> > > > }
>>>> > > >
>>>> > > > Native code throws SocketWithErrorCodeException instead of
>>>> > > SocketException
>>>> > > > so that java code could process different error by invoking
>>>> > > e.getErrorCode
>>>> > > > ().
>>>> > > >
>>>> > > > Does that make sense?
>>>> > > >
>>>> > > > Thanks!
>>>> > > >
>>>> > > > On 7/13/06, Geir Magnusson Jr <geir@pobox.com> wrote:
>>>> > > >>
>>>> > > >> I agree with the reason why (I think I understand it -
you don't
>>>> want
>>>> > > to
>>>> > > >> rely on the result of getMessage() to determine the problem...)
>>>> > > >>
>>>> > > >> Could you wrap the socket exception to carry a simple
integer 
>>>> error
>>>> > > code?
>>>> > > >>
>>>> > > >> geir
>>>> > > >>
>>>> > > >>
>>>> > > >> Mikhail Loenko wrote:
>>>> > > >> > -1 for applying the patch
>>>> > > >> >
>>>> > > >> > Applying this patch means creating a hidden problem
>>>> > > >> >
>>>> > > >> > Thanks,
>>>> > > >> > Mikhail
>>>> > > >> >
>>>> > > >> > 2006/7/12, Jimmy, Jing Lv <firepure@gmail.com>:
>>>> > > >> >> Andrew Zhang wrote:
>>>> > > >> >> > Hello Mikhail,
>>>> > > >> >> >
>>>> > > >> >> > Please see my comments inline.
>>>> > > >> >> >
>>>> > > >> >> > Thanks!
>>>> > > >> >> >
>>>> > > >> >> >
>>>> > > >> >> > On 7/12/06, Mikhail Loenko <mloenko@gmail.com>
wrote:
>>>> > > >> >> >>
>>>> > > >> >> >> 2006/7/12, Andrew Zhang <zhanghuangzhu@gmail.com>:
>>>> > > >> >> >> > Hi Mikhail,
>>>> > > >> >> >> >
>>>> > > >> >> >> > It's a NON-NLS message.
>>>> > > >> >> >> >
>>>> > > >> >> >> > Native code is designed in this
way. Currently, Harmony
>>>> socket
>>>> > > >> >> native
>>>> > > >> >> >> code
>>>> > > >> >> >> > uses messages in SocketException
to identify error type.
>>>> > > >> >> >> >
>>>> > > >> >> >> > To avoid the confusion, two alternatives
way I could 
>>>> image
>>>> are:
>>>> > > >> >> >> >
>>>> > > >> >> >> > 1. Native code returns platform-independent
error code.
>>>> > > >> >> >> >
>>>> > > >> >> >> > 2. Native code throws different
exceptions, which are 
>>>> all
>>>> > > >> >> extended from
>>>> > > >> >> >> > SocketException.
>>>> > > >> >> >> >
>>>> > > >> >> >> > Anyway, as current Harmony native
design, the message in
>>>> > > >> >> >> SocketException
>>>> > > >> >> >> > thrown by native code is a NON-NLS
string, that is to 
>>>> say,
>>>> like
>>>> > > >> >> >> "GET","POST"
>>>> > > >> >> >> > in http protocol. Unless we take
a big change on native
>>>> code
>>>> > > >> >> design, I
>>>> > > >> >> >> > don't think the code is dangerous.
>>>> > > >> >> >> >
>>>> > > >> >> >> > What's your opnion?
>>>> > > >> >> >>
>>>> > > >> >> >> I like option #2.
>>>> > > >> >> >
>>>> > > >> >> >
>>>> > > >> >> > I also prefer option1 and 2 to current native
solution.
>>>> > > >> >> >
>>>> > > >> >> > I don't think exception messages are the
same as "GET" and
>>>> > > >> "POST", we
>>>> > > >> >> > agreed
>>>> > > >> >> >> that the messages are to be internationalized.
I see that
>>>> > > currently
>>>> > > >> >> not
>>>> > > >> >> >> all
>>>> > > >> >> >> the messages are internationalized but
I think they 
>>>> will in
>>>> the
>>>> > > >> >> future.
>>>> > > >> >> >
>>>> > > >> >> >
>>>> > > >> >> > NO. Currently, exception message thrown
by native code are
>>>> used as
>>>> > > >> >> if error
>>>> > > >> >> > code [1]. Please pay attention to netLookupErrorString
>>>> function.
>>>> > > >> >> >
>>>> > > >> >> > Harmony-815 patch is based on current Harmony
native
>>>> > > implemenation,
>>>> > > >> >> > therefore, it should work well if design
is not changed.
>>>> > > >> >> >
>>>> > > >> >> > If we decide to adopt option 1, or 2, we
have to re-design
>>>> native
>>>> > > >> >> and java
>>>> > > >> >> > interface,
>>>> > > >> >> >
>>>> > > >> >> > and there are lots of native and java code
to be changed.
>>>> > > >> >> >
>>>> > > >> >> > How to design native interface is out of
scope to this 
>>>> patch,
>>>> > > >> >> therefore, I
>>>> > > >> >> > think a seperate JIRA or thread for socket
native interface
>>>> design
>>>> > > >> >> is more
>>>> > > >> >> > suitable.
>>>> > > >> >> >
>>>> > > >> >> > Of course, once decision is made, I'll volunteer
to revise
>>>> native
>>>> > > >> >> and java
>>>> > > >> >> > code.
>>>> > > >> >> >
>>>> > > >> >>
>>>> > > >> >> Yep, I also find this strange style of return
value, I 
>>>> doubt if
>>>> the
>>>> > > >> >> exception thrown in native may be an enhancement
to code
>>>> efficiency?
>>>> > > >> >> However to refactor this may be a heavy work,
as much code
>>>> follows
>>>> > > >> this
>>>> > > >> >> style, affects both luni and nio. I suggest apply
this patch,
>>>> and
>>>> > > >> leave
>>>> > > >> >> this work until Harmony begins i18n.
>>>> > > >> >>
>>>> > > >> >> > Does it make sense?
>>>> > > >> >> >
>>>> > > >> >> > Thanks!
>>>> > > >> >> >
>>>> > > >> >> > [1] native-src (nethelp.c)
>>>> > > >> >> >
>>>> > > >> >> >
>>>> > > >> >> > void
>>>> > > >> >> > throwJavaNetSocketException (JNIEnv * env,
I_32 
>>>> errorNumber)
>>>> > > >> >> > {
>>>> > > >> >> > jclass aClass;
>>>> > > >> >> > /* the error message lookup should be done
before the
>>>> FindClass
>>>> > > >> call,
>>>> > > >> >> > because the FindClass call
>>>> > > >> >> > * may reset the error number that is used
in
>>>> > > hysock_error_message
>>>> > > >> */
>>>> > > >> >> >
>>>> > > >> >> > // !!! Here, error code is mapped to NON-NLS
mesage.
>>>> > > >> >> > char *errorMessage = netLookupErrorString
(env, 
>>>> errorNumber);
>>>> > > >> >> > aClass = (*env)->FindClass (env, 
>>>> "java/net/SocketException");
>>>> > > >> >> > if (0 == aClass)
>>>> > > >> >> > {
>>>> > > >> >> > return;
>>>> > > >> >> > }
>>>> > > >> >> > (*env)->ThrowNew (env, aClass, errorMessage);
>>>> > > >> >> >
>>>> > > >> >> > }
>>>> > > >> >> >
>>>> > > >> >> > char *
>>>> > > >> >> > netLookupErrorString (JNIEnv * env, I_32
anErrorNum)
>>>> > > >> >> > {
>>>> > > >> >> > PORT_ACCESS_FROM_ENV (env);
>>>> > > >> >> > switch (anErrorNum)
>>>> > > >> >> > {
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_BADSOCKET:
>>>> > > >> >> > return "Bad socket";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_NOTINITIALIZED:
>>>> > > >> >> > return "Socket library uninitialized";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_BADAF:
>>>> > > >> >> > return "Bad address family";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_BADPROTO:
>>>> > > >> >> > return "Bad protocol";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_BADTYPE:
>>>> > > >> >> > return "Bad type";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_SYSTEMBUSY:
>>>> > > >> >> > return "System busy handling requests";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_SYSTEMFULL:
>>>> > > >> >> > return "Too many sockets allocated";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_NOTCONNECTED:
>>>> > > >> >> > return "Socket is not connected";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_INTERRUPTED:
>>>> > > >> >> > return "The call was cancelled";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_TIMEOUT:
>>>> > > >> >> > return "The operation timed out";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_CONNRESET:
>>>> > > >> >> > return "The connection was reset";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_WOULDBLOCK:
>>>> > > >> >> > return "The socket is marked as nonblocking
operation
>>>> would
>>>> > > >> >> block";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_ADDRNOTAVAIL:
>>>> > > >> >> > return "The address is not available";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_ADDRINUSE:
>>>> > > >> >> > return "The address is already in use";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_NOTBOUND:
>>>> > > >> >> > return "The socket is not bound";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_UNKNOWNSOCKET:
>>>> > > >> >> > return "Resolution of the FileDescriptor
to socket
>>>> failed";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_INVALIDTIMEOUT:
>>>> > > >> >> > return "The specified timeout is invalid";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_FDSETFULL:
>>>> > > >> >> > return "Unable to create an FDSET";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_TIMEVALFULL:
>>>> > > >> >> > return "Unable to create a TIMEVAL";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_REMSOCKSHUTDOWN:
>>>> > > >> >> > return "The remote socket has shutdown gracefully";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_NOTLISTENING:
>>>> > > >> >> > return "Listen() was not invoked prior to
accept()";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_NOTSTREAMSOCK:
>>>> > > >> >> > return "The socket does not support connection-oriented
>>>> > > >> service";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_ALREADYBOUND:
>>>> > > >> >> > return "The socket is already bound to an
address";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_NBWITHLINGER:
>>>> > > >> >> > return "The socket is marked non-blocking
& SO_LINGER is
>>>> > > >> >> non-zero";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_ISCONNECTED:
>>>> > > >> >> > return "The socket is already connected";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_NOBUFFERS:
>>>> > > >> >> > return "No buffer space is available";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_HOSTNOTFOUND:
>>>> > > >> >> > return "Authoritative Answer Host not found";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_NODATA:
>>>> > > >> >> > return "Valid name, no data record of requested
type";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_BOUNDORCONN:
>>>> > > >> >> > return "The socket has not been bound or
is already
>>>> > > connected";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_OPNOTSUPP:
>>>> > > >> >> > return "The socket does not support the
operation";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_OPTUNSUPP:
>>>> > > >> >> > return "The socket option is not supported";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_OPTARGSINVALID:
>>>> > > >> >> > return "The socket option arguments are
invalid";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_SOCKLEVELINVALID:
>>>> > > >> >> > return "The socket level is invalid";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_TIMEOUTFAILURE:
>>>> > > >> >> > return "The timeout operation failed";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_SOCKADDRALLOCFAIL:
>>>> > > >> >> > return "Failed to allocate address structure";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_FDSET_SIZEBAD:
>>>> > > >> >> > return "The calculated maximum size of the
file
>>>> descriptor
>>>> > > set
>>>> > > >> is
>>>> > > >> >> > bad";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_UNKNOWNFLAG:
>>>> > > >> >> > return "The flag is unknown";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_MSGSIZE:
>>>> > > >> >> > return
>>>> > > >> >> > "The datagram was too big to fit the specified
buffer, so
>>>> > > >> truncated";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_NORECOVERY:
>>>> > > >> >> > return "The operation failed with no recovery
possible";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_ARGSINVALID:
>>>> > > >> >> > return "The arguments are invalid";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_BADDESC:
>>>> > > >> >> > return "The socket argument is not a valid
file
>>>> descriptor";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_NOTSOCK:
>>>> > > >> >> > return "The socket argument is not a socket";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_HOSTENTALLOCFAIL:
>>>> > > >> >> > return "Unable to allocate the hostent structure";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_TIMEVALALLOCFAIL:
>>>> > > >> >> > return "Unable to allocate the timeval structure";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_LINGERALLOCFAIL:
>>>> > > >> >> > return "Unable to allocate the linger structure";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_IPMREQALLOCFAIL:
>>>> > > >> >> > return "Unable to allocate the ipmreq structure";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_FDSETALLOCFAIL:
>>>> > > >> >> > return "Unable to allocate the fdset structure";
>>>> > > >> >> > case HYPORT_ERROR_SOCKET_CONNECTION_REFUSED:
>>>> > > >> >> > return "Connection refused";
>>>> > > >> >> >
>>>> > > >> >> > default:
>>>> > > >> >> > return (char *) hysock_error_message ();
>>>> > > >> >> > }
>>>> > > >> >> > }
>>>> > > >> >> >
>>>> > > >> >> >
>>>> > > >> >> > Thanks,
>>>> > > >> >> >> Mikhail
>>>> > > >> >> >>
>>>> > > >> >> >>
>>>> > > >> >> >> >
>>>> > > >> >> >> > Best regards,
>>>> > > >> >> >> > Andrew
>>>> > > >> >> >> >
>>>> > > >> >> >> >
>>>> > > >> >> >> > On 7/11/06, Mikhail Loenko (JIRA)
<jira@apache.org> 
>>>> wrote:
>>>> > > >> >> >> > >
>>>> > > >> >> >> > > [
>>>> > > >> >> >> > >
>>>> > > >> >> >>
>>>> > > >> >>
>>>> > > >>
>>>> > >
>>>> http://issues.apache.org/jira/browse/HARMONY-815?page=comments#action_12420281

>>>>
>>>> > > >>
>>>> > > >> >>
>>>> > > >> >> >>
>>>> > > >> >> >> ]
>>>> > > >> >> >> > >
>>>> > > >> >> >> > > Mikhail Loenko commented on
HARMONY-815:
>>>> > > >> >> >> > > ----------------------------------------
>>>> > > >> >> >> > >
>>>> > > >> >> >> > > Hi Andrew
>>>> > > >> >> >> > >
>>>> > > >> >> >> > > I think it's rather dangerous:
>>>> > > >> >> >> > >
>>>> > > >> >> >> > > } catch (SocketException e)
{
>>>> > > >> >> >> > > if (ERRMSG_NONBLOKING_OUT.equals(e.getMessage
>>>> ()))
>>>> > > {
>>>> > > >> >> >> > > return sendCount;
>>>> > > >> >> >> > > }
>>>> > > >> >> >> > > throw e;
>>>> > > >> >> >> > >
>>>> > > >> >> >> > > Once we internationilize our
code that won't work
>>>> > > >> >> >> > >
>>>> > > >> >> >> > > > [classlib][nio] Refine

>>>> implConfigureBlocking(boolean)
>>>> > > method
>>>> > > >> of
>>>> > > >> >> >> > > DatagramChannel and SocketChannel.
>>>> > > >> >> >> > > >
>>>> > > >> >> >> > >
>>>> > > >> >> >>
>>>> > > >> >>
>>>> > > >>
>>>> > >
>>>> --------------------------------------------------------------------------------------------------

>>>>
>>>> > > >>
>>>> > > >> >>
>>>> > > >> >> >>
>>>> > > >> >> >> > > >
>>>> > > >> >> >> > > > Key: HARMONY-815
>>>> > > >> >> >> > > > URL:
>>>> > > >> http://issues.apache.org/jira/browse/HARMONY-815
>>>> > > >> >> >> > > > Project: Harmony
>>>> > > >> >> >> > > > Type: Improvement
>>>> > > >> >> >> > >
>>>> > > >> >> >> > > > Components: Classlib
>>>> > > >> >> >> > > > Reporter: Andrew Zhang
>>>> > > >> >> >> > > > Assignee: Mikhail Loenko
>>>> > > >> >> >> > > > Attachments: nio.diff
>>>> > > >> >> >> > > >
>>>> > > >> >> >> > > > Currently, Harmony
>>>> > > >> >> DatagramChannel.implConfigureBlocking(boolean)
>>>> > > >> >> >> does
>>>> > > >> >> >> > > nothing.
>>>> > > >> >> >> > > > It doesn't cause any
problem of read operation 
>>>> because
>>>> > > >> >> Harmony uses
>>>> > > >> >> >> > > select+blocking read to ensure
nonblocking reading.
>>>> > > >> >> >> > > > But it affects write
operations, although it is
>>>> difficult
>>>> > > to
>>>> > > >> >> test
>>>> > > >> >> >> the
>>>> > > >> >> >> > > difference between blocking
write and blocking write.
>>>> > > >> >> >> > > > Another defect is introduced
by portlib bug. As
>>>> discussed
>>>> > > on
>>>> > > >> >> >> mailing
>>>> > > >> >> >> > > list[1], connect_with_timeout
always changes the fd to
>>>> > > blocking
>>>> > > >> >> mode
>>>> > > >> >> >> after
>>>> > > >> >> >> > > invocation.
>>>> > > >> >> >> > > > I'll upload a patch to
fix these problems.
>>>> > > >> >> >> > > > Thanks!
>>>> > > >> >> >> > > > Best regards,
>>>> > > >> >> >> > > > Andrew
>>>> > > >> >> >> > >
>>>> > > >> >> >> > > --
>>>> > > >> >> >> > > This message is automatically
generated by JIRA.
>>>> > > >> >> >> > > -
>>>> > > >> >> >> > > If you think it was sent incorrectly
contact one of 
>>>> the
>>>> > > >> >> >> administrators:
>>>> > > >> >> >> > >
>>>> http://issues.apache.org/jira/secure/Administrators.jspa
>>>> > > >> >> >> > > -
>>>> > > >> >> >> > > For more information on JIRA,
see:
>>>> > > >> >> >> > > http://www.atlassian.com/software/jira
>>>> > > >> >> >> > >
>>>> > > >> >> >> > >
>>>> > > >> >> >> >
>>>> > > >> >> >> >
>>>> > > >> >> >> > --
>>>> > > >> >> >> > Andrew Zhang
>>>> > > >> >> >> > China Software Development Lab,
IBM
>>>> > > >> >> >> >
>>>> > > >> >> >> >
>>>> > > >> >> >>
>>>> > > >> >> >>
>>>> > > >>
>>>> ---------------------------------------------------------------------
>>>> > > >> >> >> Terms of use :
>>>> http://incubator.apache.org/harmony/mailing.html
>>>> > > >> >> >> To unsubscribe, e-mail:
>>>> > > >> harmony-dev-unsubscribe@incubator.apache.org
>>>> > > >> >> >> For additional commands, e-mail:
>>>> > > >> harmony-dev-help@incubator.apache.org
>>>> > > >> >> >>
>>>> > > >> >> >>
>>>> > > >> >> >
>>>> > > >> >> >
>>>> > > >> >>
>>>> > > >> >>
>>>> > > >> >> --
>>>> > > >> >>
>>>> > > >> >> Best Regards!
>>>> > > >> >>
>>>> > > >> >> Jimmy, Jing Lv
>>>> > > >> >> China Software Development Lab, IBM
>>>> > > >> >>
>>>> > > >> >>
>>>> > > 
>>>> ---------------------------------------------------------------------
>>>> > > >> >> Terms of use : 
>>>> http://incubator.apache.org/harmony/mailing.html
>>>> > > >> >> To unsubscribe, e-mail:
>>>> harmony-dev-unsubscribe@incubator.apache.org
>>>> > > >> >> For additional commands, e-mail:
>>>> > > harmony-dev-help@incubator.apache.org
>>>> > > >> >>
>>>> > > >> >>
>>>> > > >> >
>>>> > > >> >
>>>> ---------------------------------------------------------------------
>>>> > > >> > Terms of use : 
>>>> http://incubator.apache.org/harmony/mailing.html
>>>> > > >> > To unsubscribe, e-mail:
>>>> harmony-dev-unsubscribe@incubator.apache.org
>>>> > > >> > For additional commands, e-mail:
>>>> > > harmony-dev-help@incubator.apache.org
>>>> > > >> >
>>>> > > >> >
>>>> > > >> >
>>>> > > >>
>>>> > > >>
>>>> ---------------------------------------------------------------------
>>>> > > >> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>> > > >> To unsubscribe, e-mail:
>>>> harmony-dev-unsubscribe@incubator.apache.org
>>>> > > >> For additional commands, e-mail:
>>>> harmony-dev-help@incubator.apache.org
>>>> > > >>
>>>> > > >>
>>>> > > >
>>>> > > >
>>>> > >
>>>> > > --
>>>> > >
>>>> > > Tim Ellison (t.p.ellison@gmail.com)
>>>> > > IBM Java technology centre, UK.
>>>> > >
>>>> > > 
>>>> ---------------------------------------------------------------------
>>>> > > Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>> > > To unsubscribe, e-mail: 
>>>> harmony-dev-unsubscribe@incubator.apache.org
>>>> > > For additional commands, e-mail: 
>>>> harmony-dev-help@incubator.apache.org
>>>> > >
>>>> > >
>>>> >
>>>> >
>>>> > --
>>>> > Andrew Zhang
>>>> > China Software Development Lab, IBM
>>>> >
>>>> >
>>>>
>>>> ---------------------------------------------------------------------
>>>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>>>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>>>
>>>>
>>>
>>>
>>
>> --Richard Liang
>> China Software Development Lab, IBM
>>
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
> 


-- 

Best Regards!

Jimmy, Jing Lv
China Software Development Lab, IBM

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message