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 Thu, 13 Jul 2006 16:42:46 GMT
I like this

Tim Ellison 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
>>>
>>>
>>
> 

---------------------------------------------------------------------
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