Hi Andrew
this seems reasonable
Thanks,
Mikhail
2006/7/14, Andrew Zhang <[EMAIL PROTECTED]>:
> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>:
> > >> >> Andrew Zhang wrote:
> > >> >> > Hello Mikhail,
> > >> >> >
> > >> >> > Please see my comments inline.
> > >> >> >
> > >> >> > Thanks!
> > >> >> >
> > >> >> >
> > >> >> > On 7/12/06, Mikhail Loenko <[EMAIL PROTECTED]> wrote:
> > >> >> >>
> > >> >> >> 2006/7/12, Andrew Zhang <[EMAIL PROTECTED]>:
> > >> >> >> > 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) <[EMAIL PROTECTED]>
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:
> > >> [EMAIL PROTECTED]
> > >> >> >> For additional commands, e-mail:
> > >> [EMAIL PROTECTED]
> > >> >> >>
> > >> >> >>
> > >> >> >
> > >> >> >
> > >> >>
> > >> >>
> > >> >> --
> > >> >>
> > >> >> Best Regards!
> > >> >>
> > >> >> Jimmy, Jing Lv
> > >> >> China Software Development Lab, IBM
> > >> >>
> > >> >>
> >
---------------------------------------------------------------------
> > >> >> Terms of use :
http://incubator.apache.org/harmony/mailing.html
> > >> >> To unsubscribe, e-mail:
[EMAIL PROTECTED]
> > >> >> For additional commands, e-mail:
> > [EMAIL PROTECTED]
> > >> >>
> > >> >>
> > >> >
> > >> >
---------------------------------------------------------------------
> > >> > Terms of use :
http://incubator.apache.org/harmony/mailing.html
> > >> > To unsubscribe, e-mail:
[EMAIL PROTECTED]
> > >> > For additional commands, e-mail:
> > [EMAIL PROTECTED]
> > >> >
> > >> >
> > >> >
> > >>
> > >>
---------------------------------------------------------------------
> > >> Terms of use : http://incubator.apache.org/harmony/mailing.html
> > >> To unsubscribe, e-mail:
[EMAIL PROTECTED]
> > >> For additional commands, e-mail:
[EMAIL PROTECTED]
> > >>
> > >>
> > >
> > >
> >
> > --
> >
> > Tim Ellison ([EMAIL PROTECTED])
> > IBM Java technology centre, UK.
> >
> >
---------------------------------------------------------------------
> > Terms of use : http://incubator.apache.org/harmony/mailing.html
> > To unsubscribe, e-mail:
[EMAIL PROTECTED]
> > For additional commands, e-mail:
[EMAIL PROTECTED]
> >
> >
>
>
> --
> Andrew Zhang
> China Software Development Lab, IBM
>
>
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
