harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Liang <richard.lian...@gmail.com>
Subject Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.
Date Fri, 14 Jul 2006 01:58:17 GMT


Andrew Zhang wrote:
> 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()
>
>
> Tim, I have a new question on your thought. :) If we throw
> ErrorCodeException in native code, we have to catch the exception in java
> code, and then get the cause, re-throw it.  It will lose the 
> advantange of
> throwing exception in native code. Or am I wrong?
>
Hello Andrew,

You need not to throw ErrorCodeException in native code. You can just 
create an instance of ErrorCodeException, and set the instance as the 
cause of the SocketException which will be thrown in native code.  :-P

Best regards,
Richard
> 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
>>
>>
>
>

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


Mime
View raw message