harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Zhang" <zhanghuang...@gmail.com>
Subject Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.
Date Fri, 14 Jul 2006 02:08:57 GMT
On 7/14/06, Richard Liang <richard.liangyx@gmail.com> wrote:
>
>
>
> 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


Oh... Got it!  Thank you Richard!

I agree it works. :)  But we still have to decide where to i18n the message,
native code or java code. Right?

Thanks!




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


-- 
Andrew Zhang
China Software Development Lab, IBM

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message