Weird problem with DistributedHasthable

Help
MotorMind
2005-05-09
2012-09-06
  • MotorMind

    MotorMind - 2005-05-09

    Hi there,

    I am trying to use a DistributedHashtable for maintaining state over several JGroup members. The problem I have is this:

    Whenever I let one member fill the DistributedHashtable without any other members in the Channel, all goes fine. New members are able to see all the items in the group and get updates about new ones. Things go wrong when I let one one member fill the table while others are already connected to the channel. Then only the updates get propagated... the original contents of the DistributedHashtable are unknown to new members.

    What could be wrong? I have been looking into this for a while already and don't get it.

    For completeness sake, here are the properties I am using:

    UDP(mcast_addr=228.1.2.3;mcast_port=45566;ip_ttl=32):
    PING(timeout=3000;num_initial_members=6):
    MERGE2(max_interval=10000;min_interval=5000):
    FD(timeout=3000):
    VERIFY_SUSPECT(timeout=1500):
    pbcast.NAKACK(gc_lag=10;retransmit_timeout=600,1200,2400,4800):
    UNICAST(timeout=600,1200,2400,4800):
    pbcast.STABLE(desired_avg_gossip=10000):
    FRAG:
    pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;shun=true;print_local_addr=true):
    pbcast.STATE_TRANSFER

    Thanks in advance for any input...

     
    • MotorMind

      MotorMind - 2005-05-26

      Okay, I narrowed the problem down to this: whenever I look if an item exists before I add a new object, new members don't see updated items in the table. So, it's with code like this:

      if (table.containsKey(object)) {
      table.put(object);
      }

      or

      if (table.get(object) == null) {
      table put(object);
      }

      If I leave out the check, everything is going fine, but it's obviously not what I want. What gives?

       
    • ericson

      ericson - 2005-05-12

      An issue could be that a merge (by MERGE2) takes place after the initial filling of the hashtable.
      The viewchange will notify the application of this by means of a callback. Check if the View is an instance of MergeView and you will know).
      If this is the case, the initial state of the 'other' hashtables will not be the same (probably empty in your case) as the initially filled hashtable. To solve this, you will have to implement the merge of the hashtable yourselve.

      Eric.

       
    • MotorMind

      MotorMind - 2005-05-12

      As far as I can tell, the View is not a MergeView. How can I go about implementing the merge of the hashtable anyway?

       
    • MotorMind

      MotorMind - 2005-05-23

      Does anyone else know what the cause of this problem could be? If any additional information is needed I would be happy to provide it, if only I knew where to look.

       

Log in to post a comment.