11 Replies Latest reply: Mar 23, 2009 11:59 AM by 791266 RSS

    ConcurrentHashMap

    807588
      Dear all,
      I have this case and need your suggestion.
      We have the big system with many sessions. Each session is 1 user that is now connected to our system. Note, this connection is socket. We identify each session by user account (username). Therefore, when we have 1 session, we put to ConcurrentHashMap. When other session transmits message to a certain session, it will get() from ConcurrentHashMap to get the right session and then call the method from this session.
      For example, when user A wants to send message to user B, session of user A will call get() from ConcurrentHashMap to get the session of user B. Then, in session of user A, we will call sessionOfB.send(message).
      So, my question is, if the number of entries of ConcurrentHashMap is more than 30.000 entries, and there're many and many request to call get() of ConcurrentHashMap in the same time (because the processor of each session will be executed in 1 thread). Could the ConcurrentHashMap is the bottle neck of system and could the ConcurrentHashMap low down the performance of system as well as use very much CPU? I need to you that ConcurrentHashMap is suitable for the system with many many continuous access at the same time to ConcurrentHashMap?
        • 1. Re: ConcurrentHashMap
          791266
          The concurrent hashmap will most likely not be the bottleneck in the system.
          • 2. Re: ConcurrentHashMap
            807588
            Answer: don't guess. Profile your code.
            • 3. Re: ConcurrentHashMap
              807588
              Dear guys,
              It means there's many frequently access to ConcurrentHashMap. I found some information on Tarracota about the latency of frequently access on the Concurrent Data Structure (including ConcurrentHashMap). Note, I just answer in case the system has the high frequently concurrent access to ConcurrentHashMap
              • 4. Re: ConcurrentHashMap
                791266
                Luuminhkhoa wrote:
                Dear guys,
                It means there's many frequently access to ConcurrentHashMap. I found some information on Tarracota about the latency of frequently access on the Concurrent Data Structure (including ConcurrentHashMap). Note, I just answer in case the system has the high frequently concurrent access to ConcurrentHashMap
                So go ahead and give it a try.
                • 5. Re: ConcurrentHashMap
                  791266
                  From the javadoc for ConcurrentHashMap (I guess you have read it?)

                  "Retrieval operations (including get) generally do not block"
                  • 6. Re: ConcurrentHashMap
                    807588
                    This is the article and mentions about the latency of reading frequently ConcurrentHashMap. Actually, the retrieve method in ConcurrentHashMap is still blocking but it is blocking in the bucket that has the updating entry. So, what happen if there're many frequently read and update operations in the same time?
                    http://www.terracotta.org/web/display/docs/Clustered+Data+Structures+Guide
                    • 7. Re: ConcurrentHashMap
                      791266
                      Are you using Terracotta? The documentation isn't valid if you aren't using it, and the documentation for Terracotta says:

                      "Special Characteristics     Read access is fully concurrent. Write access is exclusive of read and write access per segment.
                      ConcurrentHashMap (CHM), unlike a synchronized wrapper around a java.util.HashMap, has very good concurrency characteristics that are exploited by Terracotta in a clustered context."

                      So what's your problem?
                      • 8. Re: ConcurrentHashMap
                        807588
                        This document says about the ConcurrentHashMap and they have to solve the latency by ConcurrentMapString:
                        Latency Characteristics      Slow on full iterations because all segments must be loaded, locked, and traversed. Low-latency if accessing narrow set of values; higher latency if accessing wide set of values.
                        This is the practice of latency of ConcurrentHashMap and why Terracotta has ConcurrentMapString
                        http://forums.terracotta.org/forums/posts/list/1861.page
                        My problem is the same with the pratice above. Because our system has the high frequently accessing to ConcurrentHashMap, I need to know whether it is the cause of latency in our system.
                        • 9. Re: ConcurrentHashMap
                          807588
                          Luuminhkhoa wrote:
                          I need to know whether it is the cause of latency in our system.
                          Reply #2 was spot-on. You should be able to determine the cause with a decent profiler. There isn't any need to guess based on the opinions expressed in a forum.

                          ~
                          • 10. Re: ConcurrentHashMap
                            807588
                            Thanks guys,
                            I just want to share my idea and also want to get from you. I don't want to press our forum by my guess
                            • 11. Re: ConcurrentHashMap
                              791266
                              Luuminhkhoa wrote:
                              This document says about the ConcurrentHashMap and they have to solve the latency by ConcurrentMapString:
                              Latency Characteristics      Slow on full iterations because all segments must be loaded, locked, and traversed. Low-latency if accessing narrow set of values; higher latency if accessing wide set of values.
                              That is only true if you are using Terracotty. Sigh, how hard can that be to understand?