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 > <[email protected]>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 <[email protected]> >> wrote: >> >>> Where is this set? >>> >>> Why does this cause this problem? >>> >>> 2011/4/19 Chang Song <[email protected]> >>> >>>> >>>> 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 <[email protected]> >>>> 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] <[email protected]> >>>>>> >>>>>>> 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 >>>> >>>> >>> >>
