harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.
Date Wed, 12 Jul 2006 23:52:05 GMT
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


Mime
View raw message