Return-Path: Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org Received: (qmail 48580 invoked from network); 14 Jul 2006 01:43:44 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 14 Jul 2006 01:43:44 -0000 Received: (qmail 49345 invoked by uid 500); 14 Jul 2006 01:43:42 -0000 Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org Received: (qmail 49295 invoked by uid 500); 14 Jul 2006 01:43:42 -0000 Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: harmony-dev@incubator.apache.org Delivered-To: mailing list harmony-dev@incubator.apache.org Received: (qmail 49284 invoked by uid 99); 14 Jul 2006 01:43:42 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 13 Jul 2006 18:43:42 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of zhanghuangzhu@gmail.com designates 66.249.82.205 as permitted sender) Received: from [66.249.82.205] (HELO wx-out-0102.google.com) (66.249.82.205) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 13 Jul 2006 18:43:41 -0700 Received: by wx-out-0102.google.com with SMTP id t10so180757wxc for ; Thu, 13 Jul 2006 18:43:20 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references; b=uWzVWsmJxL+U59YBBciGZFExbxyCFsf1XPhgHoRwRs72VKvk/5Twm1/+Pmb9tWEi9QBm2VK7KIRF1xgxlfEiQ7aMIT09Agh7iArmPmDULa4MmAg+35QQx0R5sVLfzMHU08UrXhlfSa+1jaKhcsUGo2/ysTRHvSwk47es7G1cIdQ= Received: by 10.70.95.3 with SMTP id s3mr2186602wxb; Thu, 13 Jul 2006 18:43:20 -0700 (PDT) Received: by 10.70.123.6 with HTTP; Thu, 13 Jul 2006 18:43:20 -0700 (PDT) Message-ID: <4d0b24970607131843t778b885cu49f0e438aaab9931@mail.gmail.com> Date: Fri, 14 Jul 2006 09:43:20 +0800 From: "Andrew Zhang" To: harmony-dev@incubator.apache.org Subject: Re: [jira] Commented: (HARMONY-815) [classlib][nio] Refine implConfigureBlocking(boolean) method of DatagramChannel and SocketChannel. In-Reply-To: <44B67499.2050209@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_1098_21643686.1152841400144" References: <21090394.1152534149837.JavaMail.jira@brutus> <21012273.1152616411392.JavaMail.jira@brutus> <4d0b24970607111951l3de701ao13651a58ec87024@mail.gmail.com> <906dd82e0607112254r5d8db168y84d6b238f00e1aad@mail.gmail.com> <4d0b24970607112344s68a0f689p2fc4d81a2ce0afc9@mail.gmail.com> <44B4AEE4.6040404@gmail.com> <906dd82e0607120241o534dcdf3n606ee13c16197325@mail.gmail.com> <44B58B25.9030404@pobox.com> <4d0b24970607121958l31cc127y51ff764d58d2b3cd@mail.gmail.com> <44B67499.2050209@gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_1098_21643686.1152841400144 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 7/14/06, Tim Ellison wrote: > > Andrew Zhang wrote: > > How about design a subclass which extends from SocketException, looks > like: > > If you want to preserve the throwable type you could create a > o.a.h.luni.ErrorCodeException that has a errorCode field set by the > native, and then make that the cause of the SocketException. > > The calling code would then do something like: > ((ErrorCodeException)ex.getCause()).getErrorCode() Tim, I have a new question on your thought. :) If we throw ErrorCodeException in native code, we have to catch the exception in java code, and then get the cause, re-throw it. It will lose the advantange of throwing exception in native code. Or am I wrong? 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 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 : > >> >> Andrew Zhang wrote: > >> >> > Hello Mikhail, > >> >> > > >> >> > Please see my comments inline. > >> >> > > >> >> > Thanks! > >> >> > > >> >> > > >> >> > On 7/12/06, Mikhail Loenko wrote: > >> >> >> > >> >> >> 2006/7/12, Andrew Zhang : > >> >> >> > 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) 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 ------=_Part_1098_21643686.1152841400144--