Hi Bongjae,
> Hi, Minoru.
>
> I see..
>
> It's interesting. What is your JDK version?
I tested with 1.5 update 10 and 1.6 update 13.
I checked Sun Bug database but I could't find the issues, which might be
releavent to this.
Minoru
> --
> Bongjae Chang
>
>
> ----- Original Message -----
> From: "Minoru Nitta" <minoru.nitta_at_jp.fujitsu.com>
> To: <dev_at_grizzly.dev.java.net>
> Sent: Monday, June 08, 2009 8:52 AM
> Subject: Re: Strange behavior of Grizzly
>
>
> > Hi Bongjae,
> >
> >
> >> Hi Bongjae,
> >>
> >>
> >> Thank you for your reply.
> >>
> >> I tested my original program
> >> on WindowsXP -> failed
> >> on Liunx -> succeeded
> >>
> >> After I applied your patch, my test program succeeded on both platforms.
> >> On Windows, my program failed because selector.select() returns empty set
> >
> > Actually, java.nio.channels.Selector.selectedKeys().
> > Thanks.
> >
> >> on Windows. So in some circumestances, there might be a problem.
> >>
> >>
> >> Minoru
> >>
> >> > Hi Minoru,
> >> >
> >> > I tested your program on Windows 2003 server.
> >> >
> >> > Your original program failed, too. But when I applied my proposed patch to your program, I could know that it worked well.
> >> >
> >> > Didn't it work well when you tested your program which was modified by my opinion on Windows XP?
> >> >
> >> > --
> >> > Bongjae Chang
> >> >
> >> >
> >> > ----- Original Message -----
> >> > From: "Minoru Nitta" <minoru.nitta_at_jp.fujitsu.com>
> >> > To: <dev_at_grizzly.dev.java.net>
> >> > Sent: Friday, June 05, 2009 1:01 PM
> >> > Subject: Re: Strange behavior of Grizzly
> >> >
> >> >
> >> > > Hi Bongjae, Hi all,
> >> > >
> >> > >
> >> > > I ran my test program on RHEL4 and it worked fine. I ran it on Windows XP,
> >> > > it failed. I debugged it and found out that SelectorHandler.select returned
> >> > > empty set at SelectorHandlerRunner.doSelect even if ready keys have been
> >> > > registered (So, read operation can never be executed). I think this is a
> >> > > bug of JDK (or somewhere else).
> >> > >
> >> > > Did you kindly test my program on Windows?
> >> > >
> >> > > Minoru
> >> > >
> >> > >> Hi Bongjae,
> >> > >>
> >> > >>
> >> > >> Thank you very much for your quick reply and curiosity. I understood
> >> > >> your proposal. Then, I would like to write my opinion.
> >> > >>
> >> > >> In UDP, it should be possible to send packets from a port where
> >> > >> server socket is already bound. For example, after starting my SIP server,
> >> > >> UDP ports status is like
> >> > >>
> >> > >> [root_at_rx200-4 ~]# netstat -a -u
> >> > >> Active Internet connections (servers and established)
> >> > >> Proto Recv-Q Send-Q Local Address Foreign Address State
> >> > >> udp 0 0 *:666 *:*
> >> > >> udp 0 0 *:669 *:*
> >> > >> udp 0 0 *:sunrpc *:*
> >> > >> udp 0 0 *:ipp *:*
> >> > >> udp 0 0 rx200-4:5060 *:*
> >> > >>
> >> > >> where
> >> > >>
> >> > >> udp 0 0 rx200-4:5060 *:*
> >> > >>
> >> > >> is a server socket where my SIP server is listening to from any other
> >> > >> addresses (*:*). Then after sending packets from the same port (i.e. 5060),
> >> > >> the status is like
> >> > >>
> >> > >> [root_at_rx200-4 ~]# netstat -a -u
> >> > >> Active Internet connections (servers and established)
> >> > >> Proto Recv-Q Send-Q Local Address Foreign Address State
> >> > >> udp 0 0 *:666 *:*
> >> > >> udp 0 0 *:669 *:*
> >> > >> udp 0 0 *:sunrpc *:*
> >> > >> udp 0 0 *:ipp *:*
> >> > >> udp 0 0 rx200-4:5060 [UNKNOWN]:6677 ESTABLISHED
> >> > >> udp 0 0 rx200-4:5060 *:*
> >> > >>
> >> > >> where
> >> > >>
> >> > >> udp 0 0 rx200-4:5060 [UNKNOWN]:6677 ESTABLISHED
> >> > >>
> >> > >> is a client socket which receives packets only from [UNKNOWN]:6677.
> >> > >>
> >> > >> So if packets are sent to the port 5060, the client socket is used
> >> > >> if the sender address is [UNKNOWN]:6677 and the server socket is used
> >> > >> if the sender address is not [UNKNOWN]:6677.
> >> > >>
> >> > >> I thought that the following code you mentioned in your reply makes
> >> > >> the
> >> > >>
> >> > >> udp 0 0 rx200-4:5060 [UNKNOWN]:6677 ESTABLISHED
> >> > >>
> >> > >> socket. But, I am not sure.
> >> > >>
> >> > >> Minoru
> >> > >>
> >> > >> > Hi Minoru,
> >> > >> >
> >> > >> > I saw your app curiously and I could reproduce your problem.
> >> > >> >
> >> > >> > When I debugged your program, I could know that your problem was perhaps caused by duplicated socket binding.
> >> > >> >
> >> > >> > I think that it is better that the client controller doesn't use a local address when it connects remote peer.
> >> > >> >
> >> > >> > See the following:
> >> > >> >
> >> > >> > In ConnectionManager.java
> >> > >> > ---
> >> > >> > private ConnectorHandler createHandlerUDP(...) {
> >> > >> > ...
> >> > >> > try {
> >> > >> > //connectorHandler.connect(socketRemote, local, callbackHandler);
> >> > >> > connectorHandler.connect(socketRemote, callbackHandler);
> >> > >> > } ...
> >> > >> > }
> >> > >> > ---
> >> > >> >
> >> > >> > In my opinion, the server controller's socket which was already binded with a local address could have a problem if a client tried to bind own socket with the same address locally.
> >> > >> >
> >> > >> > I could see that your program's server couldn't receive any packets though blocking DatagramSocket(UAC and UAS) sent a packet to the server controller successfully.
> >> > >> >
> >> > >> > So I thought that maybe the server had a problem.
> >> > >> >
> >> > >> > It is not certain. :-)
> >> > >> >
> >> > >> > But, I hope that my proposed patch and my words help you.
> >> > >> >
> >> > >> > Thanks!
> >> > >> >
> >> > >> > --
> >> > >> > Bongjae Chang
> >> > >> >
> >> > >> >
> >> > >> > ----- Original Message -----
> >> > >> > From: "Minoru Nitta" <minoru.nitta_at_jp.fujitsu.com>
> >> > >> > To: <dev_at_grizzly.dev.java.net>
> >> > >> > Sent: Tuesday, June 02, 2009 5:28 PM
> >> > >> > Subject: Strange behavior of Grizzly
> >> > >> >
> >> > >> >
> >> > >> > > Salut,
> >> > >> > >
> >> > >> > >
> >> > >> > >
> >> > >> > > I have been encountering a strange behavior of grizzly, and I need help.
> >> > >> > > I tested the enclosed program and it sometimes worked fine and it sometimes did
> >> > >> > > not work well. When it works, it repeats sending requests and responses,
> >> > >> > > but when it does not work well, it stops repeating.
> >> > >> > >
> >> > >> > > I have no idea where is the problem (my test program or grizzly).
> >> > >> > > I tested it on grizzly version 1.9.12 to 1.9.16 and the result was same.
> >> > >> > >
> >> > >> > > Thanks.
> >> > >> > >
> >> > >> > > Minoru
> >> > >> > >
> >> > >> > >
> >> > >> >
> >> > >> >
> >> > >> > --------------------------------------------------------------------------------
> >> > >> >
> >> > >> >
> >> > >> > > ---------------------------------------------------------------------
> >> > >> > > To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> >> > >> > > For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
> >> > >>
> >> > >>
> >> > >> ---------------------------------------------------------------------
> >> > >> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> >> > >> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
> >> > >
> >> > >
> >> > > ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> >> > > For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
> >> > >
> >> > >
> >> > >
> >> > >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> >> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> > For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
> >
> >
> >
> >