List Info

Thread: Created: (JGRP-751) ReplicatedHashMap state becomes inconsistent after mer




Created: (JGRP-751) ReplicatedHashMap state becomes inconsistent after mer
country flaguser name
United States
2008-05-06 11:39:39
ReplicatedHashMap state becomes inconsistent after merge
--------------------------------------------------------

                 Key: JGRP-751
                 URL: http://jir
a.jboss.com/jira/browse/JGRP-751
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 2.6.3
            Reporter: Robert Newson
         Assigned To: Bela Ban



ReplicatedHashMap does not correctly handle state transfer
during a merge, leaving members with inconsistent map
entries.

Specifically, on receipt of a MergeView no attempt is made
to reconcile the state of all members. Each member retains
the entries it had while partitioned, though all members
will correctly apply subsequent mutations.

I've attached a unit test that demonstrates the bug and also
a patch that corrects the behavior (specifically, by calling
getState() on the coordinator of each subview on receipt of
a MergeView).


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atl
assian.com/software/jira

        
_______________________________________________
jboss-jira mailing list
jboss-jiralists.jboss.org
h
ttps://lists.jboss.org/mailman/listinfo/jboss-jira

Updated: (JGRP-751) ReplicatedHashMap state becomes inconsistent after mer
country flaguser name
United States
2008-05-06 11:41:20
     [ h
ttp://jira.jboss.com/jira/browse/JGRP-751?page=all ]

Robert Newson updated JGRP-751:
-------------------------------

    Attachment: ReplicatedHashMapMergeTest.java


A test to demonstrate map state divergence during a
partition.

> ReplicatedHashMap state becomes inconsistent after
merge
>
--------------------------------------------------------
>
>                 Key: JGRP-751
>                 URL: http://jir
a.jboss.com/jira/browse/JGRP-751
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3
>            Reporter: Robert Newson
>         Assigned To: Bela Ban
>         Attachments: ReplicatedHashMapMergeTest.java
>
>
> ReplicatedHashMap does not correctly handle state
transfer during a merge, leaving members with inconsistent
map entries.
> Specifically, on receipt of a MergeView no attempt is
made to reconcile the state of all members. Each member
retains the entries it had while partitioned, though all
members will correctly apply subsequent mutations.
> I've attached a unit test that demonstrates the bug and
also a patch that corrects the behavior (specifically, by
calling getState() on the coordinator of each subview on
receipt of a MergeView).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atl
assian.com/software/jira

        
_______________________________________________
jboss-jira mailing list
jboss-jiralists.jboss.org
h
ttps://lists.jboss.org/mailman/listinfo/jboss-jira

Updated: (JGRP-751) ReplicatedHashMap state becomes inconsistent after mer
country flaguser name
United States
2008-05-06 11:45:22
     [ h
ttp://jira.jboss.com/jira/browse/JGRP-751?page=all ]

Robert Newson updated JGRP-751:
-------------------------------

    Attachment: ReplicatedHashMap.patch


On receipt of a MergeView, spin off a new Thread to call
getState() on the coordinator of each subgroup.

Test now passes.

> ReplicatedHashMap state becomes inconsistent after
merge
>
--------------------------------------------------------
>
>                 Key: JGRP-751
>                 URL: http://jir
a.jboss.com/jira/browse/JGRP-751
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3
>            Reporter: Robert Newson
>         Assigned To: Bela Ban
>         Attachments: ReplicatedHashMap.patch,
ReplicatedHashMapMergeTest.java
>
>
> ReplicatedHashMap does not correctly handle state
transfer during a merge, leaving members with inconsistent
map entries.
> Specifically, on receipt of a MergeView no attempt is
made to reconcile the state of all members. Each member
retains the entries it had while partitioned, though all
members will correctly apply subsequent mutations.
> I've attached a unit test that demonstrates the bug and
also a patch that corrects the behavior (specifically, by
calling getState() on the coordinator of each subview on
receipt of a MergeView).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atl
assian.com/software/jira

        
_______________________________________________
jboss-jira mailing list
jboss-jiralists.jboss.org
h
ttps://lists.jboss.org/mailman/listinfo/jboss-jira

Updated: (JGRP-751) ReplicatedHashMap state becomes inconsistent after mer
country flaguser name
United States
2008-05-12 01:41:22
     [ h
ttp://jira.jboss.com/jira/browse/JGRP-751?page=all ]

Bela Ban updated JGRP-751:
--------------------------

    Fix Version/s: 2.6.3
                   2.7
      Description: 
ReplicatedHashMap does not correctly handle state transfer
during a merge, leaving members with inconsistent map
entries.

Specifically, on receipt of a MergeView no attempt is made
to reconcile the state of all members. Each member retains
the entries it had while partitioned, though all members
will correctly apply subsequent mutations.

I've attached a unit test that demonstrates the bug and also
a patch that corrects the behavior (specifically, by calling
getState() on the coordinator of each subview on receipt of
a MergeView).


  was:

ReplicatedHashMap does not correctly handle state transfer
during a merge, leaving members with inconsistent map
entries.

Specifically, on receipt of a MergeView no attempt is made
to reconcile the state of all members. Each member retains
the entries it had while partitioned, though all members
will correctly apply subsequent mutations.

I've attached a unit test that demonstrates the bug and also
a patch that corrects the behavior (specifically, by calling
getState() on the coordinator of each subview on receipt of
a MergeView).


         Priority: Minor  (was: Major)

> ReplicatedHashMap state becomes inconsistent after
merge
>
--------------------------------------------------------
>
>                 Key: JGRP-751
>                 URL: http://jir
a.jboss.com/jira/browse/JGRP-751
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 2.6.3
>            Reporter: Robert Newson
>         Assigned To: Bela Ban
>            Priority: Minor
>             Fix For: 2.6.3, 2.7
>
>         Attachments: ReplicatedHashMap.patch,
ReplicatedHashMapMergeTest.java
>
>
> ReplicatedHashMap does not correctly handle state
transfer during a merge, leaving members with inconsistent
map entries.
> Specifically, on receipt of a MergeView no attempt is
made to reconcile the state of all members. Each member
retains the entries it had while partitioned, though all
members will correctly apply subsequent mutations.
> I've attached a unit test that demonstrates the bug and
also a patch that corrects the behavior (specifically, by
calling getState() on the coordinator of each subview on
receipt of a MergeView).

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the
administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atl
assian.com/software/jira

        
_______________________________________________
jboss-jira mailing list
jboss-jiralists.jboss.org
h
ttps://lists.jboss.org/mailman/listinfo/jboss-jira

[1-4]

about | contact  Other archives ( Real Estate discussion Medical topics )