[jira] [Updated] (GEODE-4748) Geode put may result in inconsistent cache if serialization of key or value class fails or network problem occurs
[
https://issues.apache.org/jira/browse/GEODE-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vadim Lotarev updated GEODE-4748:
-
Summary: Geode put may result in inconsistent cache if serialization of key
or value class fails or network problem occurs (was: Geode put may result in
inconsistent cache if serialization of key or value class fails)
> Geode put may result in inconsistent cache if serialization of key or value
> class fails or network problem occurs
> -
>
> Key: GEODE-4748
> URL: https://issues.apache.org/jira/browse/GEODE-4748
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.0.0-incubating, 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1,
> 1.4.0
>Reporter: Vadim Lotarev
>Assignee: Kirk Lund
>Priority: Major
> Attachments: clumsy.jpg, geode-4748.log
>
>
> Geode cache became inconsistent in case if networking and serialization
> problems occur at commit time. How to reproduce:
> # create any simple _replicated_ region
> # run two nodes
> # put some value in the region (within a transaction or not)
> # execute query on both nodes to check that the same value is returned (I
> used JMX for that)
> # emulate somehow temporary -networking- serialization error (I changed the
> code throwing IOException from toData())
> # repeat [#3], exception should occur
> # repeat [#4] - you should see different values on different nodes
> It looks like errors occurred after {{TXState.applyChanges}} produce
> inconsistency - it is impossible to rollback applied local changes what leads
> to the state where local cache contains changed data but other node(s) old
> data (before changes made in transaction).
> To me, consistency is a key property for the systems like Geode so I would
> consider this bug as a critical one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4748) Geode put may result in inconsistent cache if serialization of key or value class fails
[
https://issues.apache.org/jira/browse/GEODE-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vadim Lotarev updated GEODE-4748:
-
Description:
Geode cache became inconsistent in case if networking and serialization
problems occur at commit time. How to reproduce:
# create any simple _replicated_ region
# run two nodes
# put some value in the region (within a transaction or not)
# execute query on both nodes to check that the same value is returned (I used
JMX for that)
# emulate somehow temporary -networking- serialization error (I changed the
code throwing IOException from toData())
# repeat [#3], exception should occur
# repeat [#4] - you should see different values on different nodes
It looks like errors occurred after {{TXState.applyChanges}} produce
inconsistency - it is impossible to rollback applied local changes what leads
to the state where local cache contains changed data but other node(s) old
data (before changes made in transaction).
To me, consistency is a key property for the systems like Geode so I would
consider this bug as a critical one.
was:
Geode cache became inconsistent in case if -networking- serialization problems
occur at commit time. How to reproduce:
# create any simple _replicated_ region
# run two nodes
# put some value in the region (within a transaction or not)
# execute query on both nodes to check that the same value is returned (I used
JMX for that)
# emulate somehow temporary -networking- serialization error (I changed the
code throwing IOException from toData())
# repeat [#3], exception should occur
# repeat [#4] - you should see different values on different nodes
It looks like errors occurred after {{TXState.applyChanges}} produce
inconsistency - it is impossible to rollback applied local changes what leads
to the state where local cache contains changed data but other node(s) old
data (before changes made in transaction).
To me, consistency is a key property for the systems like Geode so I would
consider this bug as a critical one.
> Geode put may result in inconsistent cache if serialization of key or value
> class fails
> ---
>
> Key: GEODE-4748
> URL: https://issues.apache.org/jira/browse/GEODE-4748
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.0.0-incubating, 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1,
> 1.4.0
>Reporter: Vadim Lotarev
>Assignee: Kirk Lund
>Priority: Major
> Attachments: clumsy.jpg, geode-4748.log
>
>
> Geode cache became inconsistent in case if networking and serialization
> problems occur at commit time. How to reproduce:
> # create any simple _replicated_ region
> # run two nodes
> # put some value in the region (within a transaction or not)
> # execute query on both nodes to check that the same value is returned (I
> used JMX for that)
> # emulate somehow temporary -networking- serialization error (I changed the
> code throwing IOException from toData())
> # repeat [#3], exception should occur
> # repeat [#4] - you should see different values on different nodes
> It looks like errors occurred after {{TXState.applyChanges}} produce
> inconsistency - it is impossible to rollback applied local changes what leads
> to the state where local cache contains changed data but other node(s) old
> data (before changes made in transaction).
> To me, consistency is a key property for the systems like Geode so I would
> consider this bug as a critical one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4748) Geode put may result in inconsistent cache if serialization of key or value class fails
[
https://issues.apache.org/jira/browse/GEODE-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eugene Nedzvetsky updated GEODE-4748:
-
Attachment: (was: geode-4748.log)
> Geode put may result in inconsistent cache if serialization of key or value
> class fails
> ---
>
> Key: GEODE-4748
> URL: https://issues.apache.org/jira/browse/GEODE-4748
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.0.0-incubating, 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1,
> 1.4.0
>Reporter: Vadim Lotarev
>Assignee: Kirk Lund
>Priority: Major
> Attachments: clumsy.jpg, geode-4748.log
>
>
> Geode cache became inconsistent in case if -networking- serialization
> problems occur at commit time. How to reproduce:
> # create any simple _replicated_ region
> # run two nodes
> # put some value in the region (within a transaction or not)
> # execute query on both nodes to check that the same value is returned (I
> used JMX for that)
> # emulate somehow temporary -networking- serialization error (I changed the
> code throwing IOException from toData())
> # repeat [#3], exception should occur
> # repeat [#4] - you should see different values on different nodes
> It looks like errors occurred after {{TXState.applyChanges}} produce
> inconsistency - it is impossible to rollback applied local changes what leads
> to the state where local cache contains changed data but other node(s) old
> data (before changes made in transaction).
> To me, consistency is a key property for the systems like Geode so I would
> consider this bug as a critical one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4748) Geode put may result in inconsistent cache if serialization of key or value class fails
[
https://issues.apache.org/jira/browse/GEODE-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eugene Nedzvetsky updated GEODE-4748:
-
Attachment: geode-4748.log
> Geode put may result in inconsistent cache if serialization of key or value
> class fails
> ---
>
> Key: GEODE-4748
> URL: https://issues.apache.org/jira/browse/GEODE-4748
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.0.0-incubating, 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1,
> 1.4.0
>Reporter: Vadim Lotarev
>Assignee: Kirk Lund
>Priority: Major
> Attachments: clumsy.jpg, geode-4748.log
>
>
> Geode cache became inconsistent in case if -networking- serialization
> problems occur at commit time. How to reproduce:
> # create any simple _replicated_ region
> # run two nodes
> # put some value in the region (within a transaction or not)
> # execute query on both nodes to check that the same value is returned (I
> used JMX for that)
> # emulate somehow temporary -networking- serialization error (I changed the
> code throwing IOException from toData())
> # repeat [#3], exception should occur
> # repeat [#4] - you should see different values on different nodes
> It looks like errors occurred after {{TXState.applyChanges}} produce
> inconsistency - it is impossible to rollback applied local changes what leads
> to the state where local cache contains changed data but other node(s) old
> data (before changes made in transaction).
> To me, consistency is a key property for the systems like Geode so I would
> consider this bug as a critical one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4748) Geode put may result in inconsistent cache if serialization of key or value class fails
[
https://issues.apache.org/jira/browse/GEODE-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eugene Nedzvetsky updated GEODE-4748:
-
Attachment: geode-4748.log
> Geode put may result in inconsistent cache if serialization of key or value
> class fails
> ---
>
> Key: GEODE-4748
> URL: https://issues.apache.org/jira/browse/GEODE-4748
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.0.0-incubating, 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1,
> 1.4.0
>Reporter: Vadim Lotarev
>Assignee: Kirk Lund
>Priority: Major
> Attachments: clumsy.jpg, geode-4748.log
>
>
> Geode cache became inconsistent in case if -networking- serialization
> problems occur at commit time. How to reproduce:
> # create any simple _replicated_ region
> # run two nodes
> # put some value in the region (within a transaction or not)
> # execute query on both nodes to check that the same value is returned (I
> used JMX for that)
> # emulate somehow temporary -networking- serialization error (I changed the
> code throwing IOException from toData())
> # repeat [#3], exception should occur
> # repeat [#4] - you should see different values on different nodes
> It looks like errors occurred after {{TXState.applyChanges}} produce
> inconsistency - it is impossible to rollback applied local changes what leads
> to the state where local cache contains changed data but other node(s) old
> data (before changes made in transaction).
> To me, consistency is a key property for the systems like Geode so I would
> consider this bug as a critical one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4748) Geode put may result in inconsistent cache if serialization of key or value class fails
[
https://issues.apache.org/jira/browse/GEODE-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eugene Nedzvetsky updated GEODE-4748:
-
Attachment: clumsy.jpg
> Geode put may result in inconsistent cache if serialization of key or value
> class fails
> ---
>
> Key: GEODE-4748
> URL: https://issues.apache.org/jira/browse/GEODE-4748
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.0.0-incubating, 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1,
> 1.4.0
>Reporter: Vadim Lotarev
>Assignee: Kirk Lund
>Priority: Major
> Attachments: clumsy.jpg
>
>
> Geode cache became inconsistent in case if -networking- serialization
> problems occur at commit time. How to reproduce:
> # create any simple _replicated_ region
> # run two nodes
> # put some value in the region (within a transaction or not)
> # execute query on both nodes to check that the same value is returned (I
> used JMX for that)
> # emulate somehow temporary -networking- serialization error (I changed the
> code throwing IOException from toData())
> # repeat [#3], exception should occur
> # repeat [#4] - you should see different values on different nodes
> It looks like errors occurred after {{TXState.applyChanges}} produce
> inconsistency - it is impossible to rollback applied local changes what leads
> to the state where local cache contains changed data but other node(s) old
> data (before changes made in transaction).
> To me, consistency is a key property for the systems like Geode so I would
> consider this bug as a critical one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4748) Geode put may result in inconsistent cache if serialization of key or value class fails
[
https://issues.apache.org/jira/browse/GEODE-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-4748:
-
Description:
Geode cache became inconsistent in case if -networking- serialization problems
occur at commit time. How to reproduce:
# create any simple _replicated_ region
# run two nodes
# put some value in the region (within a transaction or not)
# execute query on both nodes to check that the same value is returned (I used
JMX for that)
# emulate somehow temporary -networking- serialization error (I changed the
code throwing IOException from toData())
# repeat [#3], exception should occur
# repeat [#4] - you should see different values on different nodes
It looks like errors occurred after {{TXState.applyChanges}} produce
inconsistency - it is impossible to rollback applied local changes what leads
to the state where local cache contains changed data but other node(s) old
data (before changes made in transaction).
To me, consistency is a key property for the systems like Geode so I would
consider this bug as a critical one.
was:
Geode cache became inconsistent in case if -networking- serialization problems
occur at commit time. How to reproduce:
# create any simple _replicated_ region
# run two nodes
# put some value in the region (within a transaction or not)
# execute query on both nodes to check that the same value is returned (I used
JMX for that)
# emulate somehow -temporary networking- serialization error (I changed the
code throwing IOException from toData())
# repeat [#3], exception should occur
# repeat [#4] - you should see different values on different nodes
It looks like errors occurred after {{TXState.applyChanges}} produce
inconsistency - it is impossible to rollback applied local changes what leads
to the state where local cache contains changed data but other node(s) old
data (before changes made in transaction).
To me, consistency is a key property for the systems like Geode so I would
consider this bug as a critical one.
> Geode put may result in inconsistent cache if serialization of key or value
> class fails
> ---
>
> Key: GEODE-4748
> URL: https://issues.apache.org/jira/browse/GEODE-4748
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.0.0-incubating, 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1,
> 1.4.0
>Reporter: Vadim Lotarev
>Assignee: Kirk Lund
>Priority: Major
>
> Geode cache became inconsistent in case if -networking- serialization
> problems occur at commit time. How to reproduce:
> # create any simple _replicated_ region
> # run two nodes
> # put some value in the region (within a transaction or not)
> # execute query on both nodes to check that the same value is returned (I
> used JMX for that)
> # emulate somehow temporary -networking- serialization error (I changed the
> code throwing IOException from toData())
> # repeat [#3], exception should occur
> # repeat [#4] - you should see different values on different nodes
> It looks like errors occurred after {{TXState.applyChanges}} produce
> inconsistency - it is impossible to rollback applied local changes what leads
> to the state where local cache contains changed data but other node(s) old
> data (before changes made in transaction).
> To me, consistency is a key property for the systems like Geode so I would
> consider this bug as a critical one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4748) Geode put may result in inconsistent cache if serialization of key or value class fails
[
https://issues.apache.org/jira/browse/GEODE-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-4748:
-
Description:
Geode cache became inconsistent in case if -networking- serialization problems
occur at commit time. How to reproduce:
# create any simple _replicated_ region
# run two nodes
# put some value in the region (within a transaction or not)
# execute query on both nodes to check that the same value is returned (I used
JMX for that)
# emulate somehow -temporary networking- serialization error (I changed the
code throwing IOException from toData())
# repeat [#3], exception should occur
# repeat [#4] - you should see different values on different nodes
It looks like errors occurred after {{TXState.applyChanges}} produce
inconsistency - it is impossible to rollback applied local changes what leads
to the state where local cache contains changed data but other node(s) old
data (before changes made in transaction).
To me, consistency is a key property for the systems like Geode so I would
consider this bug as a critical one.
was:
Geode cache became inconsistent in case if networking problems occur at commit
time. How to reproduce:
# create any simple _replicated_ region
# run two nodes
# put some value in the region within a transaction
# execute query on both nodes to check that the same value is returned (I used
JMX for that)
# emulate somehow temporary networking error (I changed the code throwing
IOException from toData())
# repeat [#3], exception should occur
# repeat [#4] - you should see different values on different nodes
It looks like errors occurred after {{TXState.applyChanges}} produce
inconsistency - it is impossible to rollback applied local changes what leads
to the state where local cache contains changed data but other node(s) old
data (before changes made in transaction).
To me, consistency is a key property for the systems like Geode so I would
consider this bug as a critical one.
> Geode put may result in inconsistent cache if serialization of key or value
> class fails
> ---
>
> Key: GEODE-4748
> URL: https://issues.apache.org/jira/browse/GEODE-4748
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.0.0-incubating, 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1,
> 1.4.0
>Reporter: Vadim Lotarev
>Assignee: Kirk Lund
>Priority: Major
>
> Geode cache became inconsistent in case if -networking- serialization
> problems occur at commit time. How to reproduce:
> # create any simple _replicated_ region
> # run two nodes
> # put some value in the region (within a transaction or not)
> # execute query on both nodes to check that the same value is returned (I
> used JMX for that)
> # emulate somehow -temporary networking- serialization error (I changed the
> code throwing IOException from toData())
> # repeat [#3], exception should occur
> # repeat [#4] - you should see different values on different nodes
> It looks like errors occurred after {{TXState.applyChanges}} produce
> inconsistency - it is impossible to rollback applied local changes what leads
> to the state where local cache contains changed data but other node(s) old
> data (before changes made in transaction).
> To me, consistency is a key property for the systems like Geode so I would
> consider this bug as a critical one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4748) Geode put may result in inconsistent cache if serialization of key or value class fails
[
https://issues.apache.org/jira/browse/GEODE-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-4748:
-
Labels: 1.5 (was: )
> Geode put may result in inconsistent cache if serialization of key or value
> class fails
> ---
>
> Key: GEODE-4748
> URL: https://issues.apache.org/jira/browse/GEODE-4748
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.0.0-incubating, 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1,
> 1.4.0
>Reporter: Vadim Lotarev
>Priority: Major
>
> Geode cache became inconsistent in case if networking problems occur at
> commit time. How to reproduce:
> # create any simple _replicated_ region
> # run two nodes
> # put some value in the region within a transaction
> # execute query on both nodes to check that the same value is returned (I
> used JMX for that)
> # emulate somehow temporary networking error (I changed the code throwing
> IOException from toData())
> # repeat [#3], exception should occur
> # repeat [#4] - you should see different values on different nodes
> It looks like errors occurred after {{TXState.applyChanges}} produce
> inconsistency - it is impossible to rollback applied local changes what leads
> to the state where local cache contains changed data but other node(s) old
> data (before changes made in transaction).
> To me, consistency is a key property for the systems like Geode so I would
> consider this bug as a critical one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4748) Geode put may result in inconsistent cache if serialization of key or value class fails
[
https://issues.apache.org/jira/browse/GEODE-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-4748:
-
Labels: (was: 1.5)
> Geode put may result in inconsistent cache if serialization of key or value
> class fails
> ---
>
> Key: GEODE-4748
> URL: https://issues.apache.org/jira/browse/GEODE-4748
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.0.0-incubating, 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1,
> 1.4.0
>Reporter: Vadim Lotarev
>Priority: Major
>
> Geode cache became inconsistent in case if networking problems occur at
> commit time. How to reproduce:
> # create any simple _replicated_ region
> # run two nodes
> # put some value in the region within a transaction
> # execute query on both nodes to check that the same value is returned (I
> used JMX for that)
> # emulate somehow temporary networking error (I changed the code throwing
> IOException from toData())
> # repeat [#3], exception should occur
> # repeat [#4] - you should see different values on different nodes
> It looks like errors occurred after {{TXState.applyChanges}} produce
> inconsistency - it is impossible to rollback applied local changes what leads
> to the state where local cache contains changed data but other node(s) old
> data (before changes made in transaction).
> To me, consistency is a key property for the systems like Geode so I would
> consider this bug as a critical one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4748) Geode put may result in inconsistent cache if serialization of key or value class fails
[
https://issues.apache.org/jira/browse/GEODE-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-4748:
-
Affects Version/s: 1.0.0-incubating
1.1.0
1.1.1
1.2.0
1.3.0
1.2.1
1.4.0
> Geode put may result in inconsistent cache if serialization of key or value
> class fails
> ---
>
> Key: GEODE-4748
> URL: https://issues.apache.org/jira/browse/GEODE-4748
> Project: Geode
> Issue Type: Bug
> Components: regions
>Affects Versions: 1.0.0-incubating, 1.1.0, 1.1.1, 1.2.0, 1.3.0, 1.2.1,
> 1.4.0
>Reporter: Vadim Lotarev
>Priority: Major
>
> Geode cache became inconsistent in case if networking problems occur at
> commit time. How to reproduce:
> # create any simple _replicated_ region
> # run two nodes
> # put some value in the region within a transaction
> # execute query on both nodes to check that the same value is returned (I
> used JMX for that)
> # emulate somehow temporary networking error (I changed the code throwing
> IOException from toData())
> # repeat [#3], exception should occur
> # repeat [#4] - you should see different values on different nodes
> It looks like errors occurred after {{TXState.applyChanges}} produce
> inconsistency - it is impossible to rollback applied local changes what leads
> to the state where local cache contains changed data but other node(s) old
> data (before changes made in transaction).
> To me, consistency is a key property for the systems like Geode so I would
> consider this bug as a critical one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4748) Geode put may result in inconsistent cache if serialization of key or value class fails
[
https://issues.apache.org/jira/browse/GEODE-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-4748:
-
Component/s: (was: transactions)
regions
> Geode put may result in inconsistent cache if serialization of key or value
> class fails
> ---
>
> Key: GEODE-4748
> URL: https://issues.apache.org/jira/browse/GEODE-4748
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Vadim Lotarev
>Priority: Major
>
> Geode cache became inconsistent in case if networking problems occur at
> commit time. How to reproduce:
> # create any simple _replicated_ region
> # run two nodes
> # put some value in the region within a transaction
> # execute query on both nodes to check that the same value is returned (I
> used JMX for that)
> # emulate somehow temporary networking error (I changed the code throwing
> IOException from toData())
> # repeat [#3], exception should occur
> # repeat [#4] - you should see different values on different nodes
> It looks like errors occurred after {{TXState.applyChanges}} produce
> inconsistency - it is impossible to rollback applied local changes what leads
> to the state where local cache contains changed data but other node(s) old
> data (before changes made in transaction).
> To me, consistency is a key property for the systems like Geode so I would
> consider this bug as a critical one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4748) Geode put may result in inconsistent cache if serialization of key or value class fails
[
https://issues.apache.org/jira/browse/GEODE-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-4748:
-
Priority: Major (was: Critical)
> Geode put may result in inconsistent cache if serialization of key or value
> class fails
> ---
>
> Key: GEODE-4748
> URL: https://issues.apache.org/jira/browse/GEODE-4748
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Vadim Lotarev
>Priority: Major
>
> Geode cache became inconsistent in case if networking problems occur at
> commit time. How to reproduce:
> # create any simple _replicated_ region
> # run two nodes
> # put some value in the region within a transaction
> # execute query on both nodes to check that the same value is returned (I
> used JMX for that)
> # emulate somehow temporary networking error (I changed the code throwing
> IOException from toData())
> # repeat [#3], exception should occur
> # repeat [#4] - you should see different values on different nodes
> It looks like errors occurred after {{TXState.applyChanges}} produce
> inconsistency - it is impossible to rollback applied local changes what leads
> to the state where local cache contains changed data but other node(s) old
> data (before changes made in transaction).
> To me, consistency is a key property for the systems like Geode so I would
> consider this bug as a critical one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (GEODE-4748) Geode put may result in inconsistent cache if serialization of key or value class fails
[
https://issues.apache.org/jira/browse/GEODE-4748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirk Lund updated GEODE-4748:
-
Summary: Geode put may result in inconsistent cache if serialization of key
or value class fails (was: Geode transaction is not consistent in case of
networking problems)
> Geode put may result in inconsistent cache if serialization of key or value
> class fails
> ---
>
> Key: GEODE-4748
> URL: https://issues.apache.org/jira/browse/GEODE-4748
> Project: Geode
> Issue Type: Bug
> Components: regions
>Reporter: Vadim Lotarev
>Priority: Critical
>
> Geode cache became inconsistent in case if networking problems occur at
> commit time. How to reproduce:
> # create any simple _replicated_ region
> # run two nodes
> # put some value in the region within a transaction
> # execute query on both nodes to check that the same value is returned (I
> used JMX for that)
> # emulate somehow temporary networking error (I changed the code throwing
> IOException from toData())
> # repeat [#3], exception should occur
> # repeat [#4] - you should see different values on different nodes
> It looks like errors occurred after {{TXState.applyChanges}} produce
> inconsistency - it is impossible to rollback applied local changes what leads
> to the state where local cache contains changed data but other node(s) old
> data (before changes made in transaction).
> To me, consistency is a key property for the systems like Geode so I would
> consider this bug as a critical one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
