Salut,
Minoru Nitta wrote:
> 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.
I've escalated the issue to the JDK team as I was also able to reproduce
the issue.
Bongjae, go ahead and commit your workaround. I will reply to that list
once I have the JDK bug issue number or an explanation why it is failing.
Good work!!
-- Jeanfrancois
>
> 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
>>>
>>>
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>