You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Andrew Zhang <zh...@gmail.com> on 2006/07/14 04:57:30 UTC
Solution on Harmony-815 (was Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
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....@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 <ge...@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 <fi...@gmail.com>:
> >> >> Andrew Zhang wrote:
> >> >> > Hello Mikhail,
> >> >> >
> >> >> > Please see my comments inline.
> >> >> >
> >> >> > Thanks!
> >> >> >
> >> >> >
> >> >> > On 7/12/06, Mikhail Loenko <ml...@gmail.com> wrote:
> >> >> >>
> >> >> >> 2006/7/12, Andrew Zhang <zh...@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) <ji...@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
Re: Solution on Harmony-815 (was Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
Posted by Andrew Zhang <zh...@gmail.com>.
On 7/17/06, David Tanzer <st...@guglhupf.net> 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);
>
> 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.
David, thank you :)
I don't know whether exception compatibility guideline allows to throw
subclass of SocketException. IIRC, if we can throw exact exception as spec
and RI, then we have no reason to throw its subclass.
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 <ml...@gmail.com>:
> >>>
> >>> Hi Andrew
> >>>
> >>> this seems reasonable
> >>>
> >>> Thanks,
> >>> Mikhail
> >>>
> >>> 2006/7/14, Andrew Zhang <zh...@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....@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 <ge...@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 <fi...@gmail.com>:
> >>> > > >> >> Andrew Zhang wrote:
> >>> > > >> >> > Hello Mikhail,
> >>> > > >> >> >
> >>> > > >> >> > Please see my comments inline.
> >>> > > >> >> >
> >>> > > >> >> > Thanks!
> >>> > > >> >> >
> >>> > > >> >> >
> >>> > > >> >> > On 7/12/06, Mikhail Loenko <ml...@gmail.com> wrote:
> >>> > > >> >> >>
> >>> > > >> >> >> 2006/7/12, Andrew Zhang <zh...@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)
> >>> <ji...@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
> >
>
>
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: Solution on Harmony-815 (was Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
Posted by Andrew Zhang <zh...@gmail.com>.
Hi Mikhail, you have agreed with it before.... :)
On 7/21/06, Mikhail Loenko <ml...@gmail.com> wrote:
>
> I'd prefer not to throw an exception :)
>
> Thanks,
> Mikhail
>
> 2006/7/21, Andrew Zhang <zh...@gmail.com>:
> > Dear all,
> >
> > When I investigated the code, I found there was only one error code
> which
> > needs to be handled.
> >
> > It's HYPORT_ERROR_SOCKET_WOULDBLOCK.
> >
> > The better thing I discovered is that after catching this exception,
> then
> > handle routine looks like:
> >
> > catch( the exception ) {
> > // it should return null if the data is not ready currently.
> > return null;
> > }
> >
> > No exception is re-thrown!
> >
> > I examined the code of luni module carefully, and found it never throws
> > a SocketException by
> > throwJavaNetSocketException(....,HYPORT_ERROR_SOCKET_WOULDBLOCK).
> Please
> > correct me if I'm wrong. :) I have tried my best to examine the luni
> code.
> >
> > Therefore, either using subexception or SocketException with cause is a
> > totally internal thing for NIO module and it doesn't affect luni module.
> >
> > For current situation, which one would everyone prefer to? no confusing
> > stack trace problem, no compatibility problem...
> >
> > Thank you for your suggestions and comments!
> >
> > Best regards,
> > Andrew
> >
> >
> >
> > On 7/21/06, Tim Ellison <t....@gmail.com> wrote:
> > >
> > > Andrew Zhang wrote:
> > > > Hi everyone,
> > > >
> > > > I have one more question:
> > > >
> > > > Which exception should be thrown whose error code is unused?
> > > >
> > > > Let's consider native throwJavaNetSocketException quoted from
> nethelp.c:
> > > > void
> > > > throwJavaNetSocketException (JNIEnv * env, I_32 errorNumber)
> > > > {
> > > > jclass aClass;
> > > > char *errorMessage = netLookupErrorString (env, errorNumber);
> > > > aClass = (*env)-FindClass (env, "java/net/SocketException");
> > > > if (0 == aClass)
> > > > {
> > > > return;
> > > > }
> > > > (*env)-ThrowNew (env, aClass, errorMessage);
> > > > }
> > > >
> > > > There are only several error numbers need to be handled in javal
> > > classlib.
> > > > For most of them, throw java.net.SocketException is enough.
> > > >
> > > > So shall we throw subclass of SocketException for several special
> error
> > > > codes or for all error codes? Suggestions?
> > >
> > > Just the ones that need it.
> > >
> > > > What's the name of subclass of SocketException? Need your
> suggestions.
> > > :)
> > >
> > > I never thought it should be a subclass anyway, so I'm not going to
> > > suggest a name <humpf> :-)
> > >
> > > <sidebar>ever thought about stuffing the errno into a private/default
> > > vis. variable on SocketException?</sidebar>
> > >
> > > Regards,
> > > Tim
> > >
> > > > Thanks!
> > > > Best regards,
> > > >
> > > > On 7/19/06, Andrew Zhang <zh...@gmail.com> wrote:
> > > >>
> > > >> Hi everyone,
> > > >>
> > > >> If no one objects, I'd like to throw subclass of SocketException in
> > > >> native
> > > >> code to fix this problem. Any suggestions, please kindly let me
> know.
> > > >> Thanks!
> > > >>
> > > >>
> > > >> On 7/18/06, Andrew Zhang <zh...@gmail.com> wrote:
> > > >> >
> > > >> > Seems most people prefer subclass to SocketException with
> > > >> > ErrorCodeException cause.
> > > >> >
> > > >> > Does anyone prefer the latter? or both are acceptable?
> > > >> >
> > > >> > I think we'd better made an agreement about this issue.
> > > >> >
> > > >> > Mikhail, how do you think about it? Which one do you prefer? :)
> I'll
> > > >> fix
> > > >> > Harmony-815 once decision is made.
> > > >> >
> > > >> > Thanks!
> > > >> >
> > > >> >
> > > >> > On 7/18/06, Alexey Varlamov < alexey.v.varlamov@gmail.com>
> wrote:
> > > >> > >
> > > >> > > IMHO, throwing a subclass certainly fits to specification and
> can
> > > >> > > hardly break compatibility with RI. I consider this is the
> proper
> > > >> > > workaround for now.
> > > >> > > Just my $0.02 :)
> > > >> > >
> > > >> > > --
> > > >> > > Alexey Varlamov
> > > >> > > >
> > > >> > > > 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.
> > > >> > >
> > > >> > >
> > > ---------------------------------------------------------------------
> > > >> > > 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
> > > >> >
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Andrew Zhang
> > > >> China Software Development Lab, IBM
> > > >>
> > > >
> > > >
> > > >
> > >
> > > --
> > >
> > > 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
>
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: Solution on Harmony-815 (was Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
Posted by Mikhail Loenko <ml...@gmail.com>.
I'd prefer not to throw an exception :)
Thanks,
Mikhail
2006/7/21, Andrew Zhang <zh...@gmail.com>:
> Dear all,
>
> When I investigated the code, I found there was only one error code which
> needs to be handled.
>
> It's HYPORT_ERROR_SOCKET_WOULDBLOCK.
>
> The better thing I discovered is that after catching this exception, then
> handle routine looks like:
>
> catch( the exception ) {
> // it should return null if the data is not ready currently.
> return null;
> }
>
> No exception is re-thrown!
>
> I examined the code of luni module carefully, and found it never throws
> a SocketException by
> throwJavaNetSocketException(....,HYPORT_ERROR_SOCKET_WOULDBLOCK). Please
> correct me if I'm wrong. :) I have tried my best to examine the luni code.
>
> Therefore, either using subexception or SocketException with cause is a
> totally internal thing for NIO module and it doesn't affect luni module.
>
> For current situation, which one would everyone prefer to? no confusing
> stack trace problem, no compatibility problem...
>
> Thank you for your suggestions and comments!
>
> Best regards,
> Andrew
>
>
>
> On 7/21/06, Tim Ellison <t....@gmail.com> wrote:
> >
> > Andrew Zhang wrote:
> > > Hi everyone,
> > >
> > > I have one more question:
> > >
> > > Which exception should be thrown whose error code is unused?
> > >
> > > Let's consider native throwJavaNetSocketException quoted from nethelp.c:
> > > void
> > > throwJavaNetSocketException (JNIEnv * env, I_32 errorNumber)
> > > {
> > > jclass aClass;
> > > char *errorMessage = netLookupErrorString (env, errorNumber);
> > > aClass = (*env)-FindClass (env, "java/net/SocketException");
> > > if (0 == aClass)
> > > {
> > > return;
> > > }
> > > (*env)-ThrowNew (env, aClass, errorMessage);
> > > }
> > >
> > > There are only several error numbers need to be handled in javal
> > classlib.
> > > For most of them, throw java.net.SocketException is enough.
> > >
> > > So shall we throw subclass of SocketException for several special error
> > > codes or for all error codes? Suggestions?
> >
> > Just the ones that need it.
> >
> > > What's the name of subclass of SocketException? Need your suggestions.
> > :)
> >
> > I never thought it should be a subclass anyway, so I'm not going to
> > suggest a name <humpf> :-)
> >
> > <sidebar>ever thought about stuffing the errno into a private/default
> > vis. variable on SocketException?</sidebar>
> >
> > Regards,
> > Tim
> >
> > > Thanks!
> > > Best regards,
> > >
> > > On 7/19/06, Andrew Zhang <zh...@gmail.com> wrote:
> > >>
> > >> Hi everyone,
> > >>
> > >> If no one objects, I'd like to throw subclass of SocketException in
> > >> native
> > >> code to fix this problem. Any suggestions, please kindly let me know.
> > >> Thanks!
> > >>
> > >>
> > >> On 7/18/06, Andrew Zhang <zh...@gmail.com> wrote:
> > >> >
> > >> > Seems most people prefer subclass to SocketException with
> > >> > ErrorCodeException cause.
> > >> >
> > >> > Does anyone prefer the latter? or both are acceptable?
> > >> >
> > >> > I think we'd better made an agreement about this issue.
> > >> >
> > >> > Mikhail, how do you think about it? Which one do you prefer? :) I'll
> > >> fix
> > >> > Harmony-815 once decision is made.
> > >> >
> > >> > Thanks!
> > >> >
> > >> >
> > >> > On 7/18/06, Alexey Varlamov < alexey.v.varlamov@gmail.com> wrote:
> > >> > >
> > >> > > IMHO, throwing a subclass certainly fits to specification and can
> > >> > > hardly break compatibility with RI. I consider this is the proper
> > >> > > workaround for now.
> > >> > > Just my $0.02 :)
> > >> > >
> > >> > > --
> > >> > > Alexey Varlamov
> > >> > > >
> > >> > > > 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.
> > >> > >
> > >> > >
> > ---------------------------------------------------------------------
> > >> > > 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
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> Andrew Zhang
> > >> China Software Development Lab, IBM
> > >>
> > >
> > >
> > >
> >
> > --
> >
> > 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
Re: Solution on Harmony-815 (was Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
Posted by Andrew Zhang <zh...@gmail.com>.
Dear all,
When I investigated the code, I found there was only one error code which
needs to be handled.
It's HYPORT_ERROR_SOCKET_WOULDBLOCK.
The better thing I discovered is that after catching this exception, then
handle routine looks like:
catch( the exception ) {
// it should return null if the data is not ready currently.
return null;
}
No exception is re-thrown!
I examined the code of luni module carefully, and found it never throws
a SocketException by
throwJavaNetSocketException(....,HYPORT_ERROR_SOCKET_WOULDBLOCK). Please
correct me if I'm wrong. :) I have tried my best to examine the luni code.
Therefore, either using subexception or SocketException with cause is a
totally internal thing for NIO module and it doesn't affect luni module.
For current situation, which one would everyone prefer to? no confusing
stack trace problem, no compatibility problem...
Thank you for your suggestions and comments!
Best regards,
Andrew
On 7/21/06, Tim Ellison <t....@gmail.com> wrote:
>
> Andrew Zhang wrote:
> > Hi everyone,
> >
> > I have one more question:
> >
> > Which exception should be thrown whose error code is unused?
> >
> > Let's consider native throwJavaNetSocketException quoted from nethelp.c:
> > void
> > throwJavaNetSocketException (JNIEnv * env, I_32 errorNumber)
> > {
> > jclass aClass;
> > char *errorMessage = netLookupErrorString (env, errorNumber);
> > aClass = (*env)-FindClass (env, "java/net/SocketException");
> > if (0 == aClass)
> > {
> > return;
> > }
> > (*env)-ThrowNew (env, aClass, errorMessage);
> > }
> >
> > There are only several error numbers need to be handled in javal
> classlib.
> > For most of them, throw java.net.SocketException is enough.
> >
> > So shall we throw subclass of SocketException for several special error
> > codes or for all error codes? Suggestions?
>
> Just the ones that need it.
>
> > What's the name of subclass of SocketException? Need your suggestions.
> :)
>
> I never thought it should be a subclass anyway, so I'm not going to
> suggest a name <humpf> :-)
>
> <sidebar>ever thought about stuffing the errno into a private/default
> vis. variable on SocketException?</sidebar>
>
> Regards,
> Tim
>
> > Thanks!
> > Best regards,
> >
> > On 7/19/06, Andrew Zhang <zh...@gmail.com> wrote:
> >>
> >> Hi everyone,
> >>
> >> If no one objects, I'd like to throw subclass of SocketException in
> >> native
> >> code to fix this problem. Any suggestions, please kindly let me know.
> >> Thanks!
> >>
> >>
> >> On 7/18/06, Andrew Zhang <zh...@gmail.com> wrote:
> >> >
> >> > Seems most people prefer subclass to SocketException with
> >> > ErrorCodeException cause.
> >> >
> >> > Does anyone prefer the latter? or both are acceptable?
> >> >
> >> > I think we'd better made an agreement about this issue.
> >> >
> >> > Mikhail, how do you think about it? Which one do you prefer? :) I'll
> >> fix
> >> > Harmony-815 once decision is made.
> >> >
> >> > Thanks!
> >> >
> >> >
> >> > On 7/18/06, Alexey Varlamov < alexey.v.varlamov@gmail.com> wrote:
> >> > >
> >> > > IMHO, throwing a subclass certainly fits to specification and can
> >> > > hardly break compatibility with RI. I consider this is the proper
> >> > > workaround for now.
> >> > > Just my $0.02 :)
> >> > >
> >> > > --
> >> > > Alexey Varlamov
> >> > > >
> >> > > > 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.
> >> > >
> >> > >
> ---------------------------------------------------------------------
> >> > > 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
> >> >
> >>
> >>
> >>
> >> --
> >> Andrew Zhang
> >> China Software Development Lab, IBM
> >>
> >
> >
> >
>
> --
>
> 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
Re: Solution on Harmony-815 (was Re: [jira] Commented: (HARMONY-815)
[classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel
and SocketChannel.)
Posted by Tim Ellison <t....@gmail.com>.
Andrew Zhang wrote:
> Hi everyone,
>
> I have one more question:
>
> Which exception should be thrown whose error code is unused?
>
> Let's consider native throwJavaNetSocketException quoted from nethelp.c:
> void
> throwJavaNetSocketException (JNIEnv * env, I_32 errorNumber)
> {
> jclass aClass;
> char *errorMessage = netLookupErrorString (env, errorNumber);
> aClass = (*env)-FindClass (env, "java/net/SocketException");
> if (0 == aClass)
> {
> return;
> }
> (*env)-ThrowNew (env, aClass, errorMessage);
> }
>
> There are only several error numbers need to be handled in javal classlib.
> For most of them, throw java.net.SocketException is enough.
>
> So shall we throw subclass of SocketException for several special error
> codes or for all error codes? Suggestions?
Just the ones that need it.
> What's the name of subclass of SocketException? Need your suggestions. :)
I never thought it should be a subclass anyway, so I'm not going to
suggest a name <humpf> :-)
<sidebar>ever thought about stuffing the errno into a private/default
vis. variable on SocketException?</sidebar>
Regards,
Tim
> Thanks!
> Best regards,
>
> On 7/19/06, Andrew Zhang <zh...@gmail.com> wrote:
>>
>> Hi everyone,
>>
>> If no one objects, I'd like to throw subclass of SocketException in
>> native
>> code to fix this problem. Any suggestions, please kindly let me know.
>> Thanks!
>>
>>
>> On 7/18/06, Andrew Zhang <zh...@gmail.com> wrote:
>> >
>> > Seems most people prefer subclass to SocketException with
>> > ErrorCodeException cause.
>> >
>> > Does anyone prefer the latter? or both are acceptable?
>> >
>> > I think we'd better made an agreement about this issue.
>> >
>> > Mikhail, how do you think about it? Which one do you prefer? :) I'll
>> fix
>> > Harmony-815 once decision is made.
>> >
>> > Thanks!
>> >
>> >
>> > On 7/18/06, Alexey Varlamov < alexey.v.varlamov@gmail.com> wrote:
>> > >
>> > > IMHO, throwing a subclass certainly fits to specification and can
>> > > hardly break compatibility with RI. I consider this is the proper
>> > > workaround for now.
>> > > Just my $0.02 :)
>> > >
>> > > --
>> > > Alexey Varlamov
>> > > >
>> > > > 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.
>> > >
>> > > ---------------------------------------------------------------------
>> > > 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
>> >
>>
>>
>>
>> --
>> Andrew Zhang
>> China Software Development Lab, IBM
>>
>
>
>
--
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
Re: Solution on Harmony-815 (was Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
Posted by Andrew Zhang <zh...@gmail.com>.
Hi everyone,
I have one more question:
Which exception should be thrown whose error code is unused?
Let's consider native throwJavaNetSocketException quoted from nethelp.c:
void
throwJavaNetSocketException (JNIEnv * env, I_32 errorNumber)
{
jclass aClass;
char *errorMessage = netLookupErrorString (env, errorNumber);
aClass = (*env)-FindClass (env, "java/net/SocketException");
if (0 == aClass)
{
return;
}
(*env)-ThrowNew (env, aClass, errorMessage);
}
There are only several error numbers need to be handled in javal classlib.
For most of them, throw java.net.SocketException is enough.
So shall we throw subclass of SocketException for several special error
codes or for all error codes? Suggestions?
What's the name of subclass of SocketException? Need your suggestions. :)
Thanks!
Best regards,
On 7/19/06, Andrew Zhang <zh...@gmail.com> wrote:
>
> Hi everyone,
>
> If no one objects, I'd like to throw subclass of SocketException in native
> code to fix this problem. Any suggestions, please kindly let me know.
> Thanks!
>
>
> On 7/18/06, Andrew Zhang <zh...@gmail.com> wrote:
> >
> > Seems most people prefer subclass to SocketException with
> > ErrorCodeException cause.
> >
> > Does anyone prefer the latter? or both are acceptable?
> >
> > I think we'd better made an agreement about this issue.
> >
> > Mikhail, how do you think about it? Which one do you prefer? :) I'll fix
> > Harmony-815 once decision is made.
> >
> > Thanks!
> >
> >
> > On 7/18/06, Alexey Varlamov < alexey.v.varlamov@gmail.com> wrote:
> > >
> > > IMHO, throwing a subclass certainly fits to specification and can
> > > hardly break compatibility with RI. I consider this is the proper
> > > workaround for now.
> > > Just my $0.02 :)
> > >
> > > --
> > > Alexey Varlamov
> > > >
> > > > 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.
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
>
>
>
> --
> Andrew Zhang
> China Software Development Lab, IBM
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: Solution on Harmony-815 (was Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
Posted by Andrew Zhang <zh...@gmail.com>.
Hi everyone,
If no one objects, I'd like to throw subclass of SocketException in native
code to fix this problem. Any suggestions, please kindly let me know.
Thanks!
On 7/18/06, Andrew Zhang <zh...@gmail.com> wrote:
>
> Seems most people prefer subclass to SocketException with
> ErrorCodeException cause.
>
> Does anyone prefer the latter? or both are acceptable?
>
> I think we'd better made an agreement about this issue.
>
> Mikhail, how do you think about it? Which one do you prefer? :) I'll fix
> Harmony-815 once decision is made.
>
> Thanks!
>
>
> On 7/18/06, Alexey Varlamov <al...@gmail.com> wrote:
> >
> > IMHO, throwing a subclass certainly fits to specification and can
> > hardly break compatibility with RI. I consider this is the proper
> > workaround for now.
> > Just my $0.02 :)
> >
> > --
> > Alexey Varlamov
> > >
> > > 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.
> >
> > ---------------------------------------------------------------------
> > 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
>
--
Andrew Zhang
China Software Development Lab, IBM
Re: Solution on Harmony-815 (was Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
Posted by Mikhail Loenko <ml...@gmail.com>.
2006/7/18, Andrew Zhang <zh...@gmail.com>:
> Seems most people prefer subclass to SocketException with ErrorCodeException
> cause.
>
> Does anyone prefer the latter? or both are acceptable?
>
> I think we'd better made an agreement about this issue.
>
> Mikhail, how do you think about it? Which one do you prefer? :) I'll fix
> Harmony-815 once decision is made.
both seem ok, no prefs from my side
Thanks,
Mikhail
>
> Thanks!
>
>
> On 7/18/06, Alexey Varlamov <al...@gmail.com> wrote:
> >
> > IMHO, throwing a subclass certainly fits to specification and can
> > hardly break compatibility with RI. I consider this is the proper
> > workaround for now.
> > Just my $0.02 :)
> >
> > --
> > Alexey Varlamov
> > >
> > > 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.
> >
> > ---------------------------------------------------------------------
> > 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
Re: Solution on Harmony-815 (was Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
Posted by Andrew Zhang <zh...@gmail.com>.
Seems most people prefer subclass to SocketException with ErrorCodeException
cause.
Does anyone prefer the latter? or both are acceptable?
I think we'd better made an agreement about this issue.
Mikhail, how do you think about it? Which one do you prefer? :) I'll fix
Harmony-815 once decision is made.
Thanks!
On 7/18/06, Alexey Varlamov <al...@gmail.com> wrote:
>
> IMHO, throwing a subclass certainly fits to specification and can
> hardly break compatibility with RI. I consider this is the proper
> workaround for now.
> Just my $0.02 :)
>
> --
> Alexey Varlamov
> >
> > 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.
>
> ---------------------------------------------------------------------
> 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
Re: Solution on Harmony-815 (was Re: [jira] Commented: (HARMONY-815)
[classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel
and SocketChannel.)
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
Alexey Varlamov wrote:
> IMHO, throwing a subclass certainly fits to specification and can
> hardly break compatibility with RI. I consider this is the proper
> workaround for now.
> Just my $0.02 :)
>
Thanks Alexey, I have no objection if it does not break compatibility
guideline :)
> --
> Alexey Varlamov
>>
>> 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.
>
> ---------------------------------------------------------------------
> 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
Re: Solution on Harmony-815 (was Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
Posted by Alexey Varlamov <al...@gmail.com>.
IMHO, throwing a subclass certainly fits to specification and can
hardly break compatibility with RI. I consider this is the proper
workaround for now.
Just my $0.02 :)
--
Alexey Varlamov
>
> 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.
---------------------------------------------------------------------
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
Re: Solution on Harmony-815 (was Re: [jira] Commented: (HARMONY-815)
[classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel
and SocketChannel.)
Posted by "Jimmy, Jing Lv" <fi...@gmail.com>.
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 <ml...@gmail.com>:
>>>>
>>>> Hi Andrew
>>>>
>>>> this seems reasonable
>>>>
>>>> Thanks,
>>>> Mikhail
>>>>
>>>> 2006/7/14, Andrew Zhang <zh...@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....@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 <ge...@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 <fi...@gmail.com>:
>>>> > > >> >> Andrew Zhang wrote:
>>>> > > >> >> > Hello Mikhail,
>>>> > > >> >> >
>>>> > > >> >> > Please see my comments inline.
>>>> > > >> >> >
>>>> > > >> >> > Thanks!
>>>> > > >> >> >
>>>> > > >> >> >
>>>> > > >> >> > On 7/12/06, Mikhail Loenko <ml...@gmail.com> wrote:
>>>> > > >> >> >>
>>>> > > >> >> >> 2006/7/12, Andrew Zhang <zh...@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) <ji...@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
Re: Solution on Harmony-815 (was Re: [jira] Commented: (HARMONY-815)
[classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel
and SocketChannel.)
Posted by Richard Liang <ri...@gmail.com>.
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);
>
> 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.
>
Hello David,
I also think the subclass-approach is more reasonable ;-) . I'm not sure
if it's regarded as breaking specification. (Spec requires us to throw
SocketExpception). Any comments? Thanks a lot.
Best regards,
Richard.
> 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 <ml...@gmail.com>:
>>>>
>>>> Hi Andrew
>>>>
>>>> this seems reasonable
>>>>
>>>> Thanks,
>>>> Mikhail
>>>>
>>>> 2006/7/14, Andrew Zhang <zh...@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....@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 <ge...@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 <fi...@gmail.com>:
>>>> > > >> >> Andrew Zhang wrote:
>>>> > > >> >> > Hello Mikhail,
>>>> > > >> >> >
>>>> > > >> >> > Please see my comments inline.
>>>> > > >> >> >
>>>> > > >> >> > Thanks!
>>>> > > >> >> >
>>>> > > >> >> >
>>>> > > >> >> > On 7/12/06, Mikhail Loenko <ml...@gmail.com> wrote:
>>>> > > >> >> >>
>>>> > > >> >> >> 2006/7/12, Andrew Zhang <zh...@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) <ji...@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
>>
>
--
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
Re: Solution on Harmony-815 (was Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
Posted by David Tanzer <st...@guglhupf.net>.
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);
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.
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 <ml...@gmail.com>:
>>>
>>> Hi Andrew
>>>
>>> this seems reasonable
>>>
>>> Thanks,
>>> Mikhail
>>>
>>> 2006/7/14, Andrew Zhang <zh...@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....@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 <ge...@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 <fi...@gmail.com>:
>>> > > >> >> Andrew Zhang wrote:
>>> > > >> >> > Hello Mikhail,
>>> > > >> >> >
>>> > > >> >> > Please see my comments inline.
>>> > > >> >> >
>>> > > >> >> > Thanks!
>>> > > >> >> >
>>> > > >> >> >
>>> > > >> >> > On 7/12/06, Mikhail Loenko <ml...@gmail.com> wrote:
>>> > > >> >> >>
>>> > > >> >> >> 2006/7/12, Andrew Zhang <zh...@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)
>>> <ji...@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
>
Re: Solution on Harmony-815 (was Re: [jira] Commented: (HARMONY-815)
[classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel
and SocketChannel.)
Posted by Richard Liang <ri...@gmail.com>.
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. 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 <ml...@gmail.com>:
>>
>> Hi Andrew
>>
>> this seems reasonable
>>
>> Thanks,
>> Mikhail
>>
>> 2006/7/14, Andrew Zhang <zh...@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....@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 <ge...@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 <fi...@gmail.com>:
>> > > >> >> Andrew Zhang wrote:
>> > > >> >> > Hello Mikhail,
>> > > >> >> >
>> > > >> >> > Please see my comments inline.
>> > > >> >> >
>> > > >> >> > Thanks!
>> > > >> >> >
>> > > >> >> >
>> > > >> >> > On 7/12/06, Mikhail Loenko <ml...@gmail.com> wrote:
>> > > >> >> >>
>> > > >> >> >> 2006/7/12, Andrew Zhang <zh...@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) <ji...@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
Re: Solution on Harmony-815 (was Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
Posted by LvJimmy，Jing <fi...@gmail.com>.
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? :)
2006/7/14, Mikhail Loenko <ml...@gmail.com>:
>
> Hi Andrew
>
> this seems reasonable
>
> Thanks,
> Mikhail
>
> 2006/7/14, Andrew Zhang <zh...@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....@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 <ge...@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 <fi...@gmail.com>:
> > > >> >> Andrew Zhang wrote:
> > > >> >> > Hello Mikhail,
> > > >> >> >
> > > >> >> > Please see my comments inline.
> > > >> >> >
> > > >> >> > Thanks!
> > > >> >> >
> > > >> >> >
> > > >> >> > On 7/12/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > > >> >> >>
> > > >> >> >> 2006/7/12, Andrew Zhang <zh...@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) <ji...@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
>
>
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM
Re: Solution on Harmony-815 (was Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel.)
Posted by Mikhail Loenko <ml...@gmail.com>.
Hi Andrew
this seems reasonable
Thanks,
Mikhail
2006/7/14, Andrew Zhang <zh...@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....@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 <ge...@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 <fi...@gmail.com>:
> > >> >> Andrew Zhang wrote:
> > >> >> > Hello Mikhail,
> > >> >> >
> > >> >> > Please see my comments inline.
> > >> >> >
> > >> >> > Thanks!
> > >> >> >
> > >> >> >
> > >> >> > On 7/12/06, Mikhail Loenko <ml...@gmail.com> wrote:
> > >> >> >>
> > >> >> >> 2006/7/12, Andrew Zhang <zh...@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) <ji...@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