Actually, "netspider", Chisu Ryu, in my team fixed it. Thanks, Chisu.
Chang 2011. 7. 6., 오전 3:04, Patrick Hunt 작성: > Vishal brought up an issue at the ZK post-summit meetup that might > also be (partially?) resolved by this patch. > > Thanks again Chang Song! > > Patrick > > 2011/7/1 Chang Song <tru64...@me.com>: >> >> No problem. >> Glad to contribute. >> >> Thanks a lot. >> >> >> 2011. 7. 2., 오전 1:03, Ted Dunning 작성: >> >>> Thanks for the feedback Jared! >>> >>> (and thanks to Chang as well!) >>> >>> On Fri, Jul 1, 2011 at 8:06 AM, Jared Cantwell >>> <jared.cantw...@gmail.com>wrote: >>> >>>> As a note, I believe we just used this patch to solve a major issue ... >>>> >>>> Thanks Chang! >>>> ~Jared >>>> >>>> On Tue, Apr 19, 2011 at 10:59 AM, Ted Dunning <ted.dunn...@gmail.com> >>>> wrote: >>>> >>>>> Where is this set? >>>>> >>>>> Why does this cause this problem? >>>>> >>>>> 2011/4/19 Chang Song <tru64...@me.com> >>>>> >>>>>> >>>>>> Problem solved. >>>>>> it was socket linger option set to 2 sec timeout. >>>>>> >>>>>> We have verified that the original problem goes away when we turn off >>>>>> linger option. >>>>>> No longer a mystery ;) >>>>>> >>>>>> >>>>>> https://issues.apache.org/jira/browse/ZOOKEEPER-1049 >>>>>> >>>>>> >>>>>> Chang >>>>>> >>>>>> >>>>>> 2011. 4. 19., 오전 3:16, Mahadev Konar 작성: >>>>>> >>>>>>> Camille, Ted, >>>>>>> Can we continue the discussion on >>>>>>> https://issues.apache.org/jira/browse/ZOOKEEPER-1049? >>>>>>> >>>>>>> We should track all the suggestions/issues on the jira. >>>>>>> >>>>>>> thanks >>>>>>> mahadev >>>>>>> >>>>>>> On Mon, Apr 18, 2011 at 9:03 AM, Ted Dunning <ted.dunn...@gmail.com> >>>>>> wrote: >>>>>>>> Interesting. It does seem to suggestion the session expiration is >>>>>>>> expensive. >>>>>>>> >>>>>>>> There is a concurrent table in guava that provides very good >>>>>> multi-threaded >>>>>>>> performance. I think that is achieved by using a number of locks >>>> and >>>>>> then >>>>>>>> distributing threads across the locks according to the hash slot >>>> being >>>>>> used. >>>>>>>> But I would have expected any in memory operation to complete very >>>>>> quickly. >>>>>>>> >>>>>>>> Is it possible that the locks on the session table are held longer >>>>> than >>>>>> they >>>>>>>> should be? >>>>>>>> >>>>>>>> 2011/4/18 Fournier, Camille F. [Tech] <camille.fourn...@gs.com> >>>>>>>> >>>>>>>>> Is it possible this is related to this report back in February? >>>>>>>>> >>>>>>>>> >>>>>> >>>>> >>>> http://mail-archives.apache.org/mod_mbox/zookeeper-user/201102.mbox/%3c6642fc1caf133548aa8fdf497c547f0a23c0c52...@nywexmbx2126.msad.ms.com%3E >>>>>>>>> >>>>>>>>> I theorized that the issue might be due to synchronization on the >>>>>> session >>>>>>>>> table, but never got enough information to finish the >>>> investigation. >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> thanks >>>>>>> mahadev >>>>>>> @mahadevkonar >>>>>> >>>>>> >>>>> >>>> >> >>
