October 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4910) Document inconsistent behavior of ReadCommitted isolation level in some scenarios

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-4910?page=com.atlassian.jira.plugin.... ] Martin Gencur updated ISPN-4910: -------------------------------- Description: Document the following (inconsistent) behavior which was also described in an email thread http://lists.jboss.org/pipermail/infinispan-dev/2013-September/013769.html: {code:java} public void testSizeWithPreviousRead() throws Exception { tm(0).begin(); cache(0).put(k0, "v0"); cache(0).put(k1, "v1"); assertEquals(2, cache(0).size()); tm(0).commit(); tm(0).begin(); //make sure we read k1 in this transaction assertEquals("v1", cache(0).get(k1)); final Transaction tx1 = tm(0).suspend(); //another tx working on the same keys tm(0).begin(); //remove the key that was previously read in another tx cache(0).remove(k1); cache(0).put(k0, "v2"); tm(0).commit(); tm(0).resume(tx1); //we read k1 earlier but in READ_COMMITTED MODE, the size() method should NOT take the key into account assertEquals(1, cache(0).size()); //^^^^^ the test fails here, cache.size() return 2 instead of expected 1 assertEquals("v2", cache(0).get(k0)); assertNull(cache(0).get(k1)); tm(0).commit(); assertNull(cache(1).get(k1)); } {code} I will add tests as part of ISPN-4820 to show the behavior, we just need to document it. was: Document the following (incorrect and unexpected) behavior which was also described in an email thread http://lists.jboss.org/pipermail/infinispan-dev/2013-September/013769.html: {code:java} public void testSizeWithPreviousRead() throws Exception { tm(0).begin(); cache(0).put(k0, "v0"); cache(0).put(k1, "v1"); assertEquals(2, cache(0).size()); tm(0).commit(); tm(0).begin(); //make sure we read k1 in this transaction assertEquals("v1", cache(0).get(k1)); final Transaction tx1 = tm(0).suspend(); //another tx working on the same keys tm(0).begin(); //remove the key that was previously read in another tx cache(0).remove(k1); cache(0).put(k0, "v2"); tm(0).commit(); tm(0).resume(tx1); //we read k1 earlier but in READ_COMMITTED MODE, the size() method should NOT take the key into account assertEquals(1, cache(0).size()); //^^^^^ the test fails here, cache.size() return 2 instead of expected 1 assertEquals("v2", cache(0).get(k0)); assertNull(cache(0).get(k1)); tm(0).commit(); assertNull(cache(1).get(k1)); } {code} I will add tests as part of ISPN-4820 to show the behavior, we just need to document it. > Document inconsistent behavior of ReadCommitted isolation level in some scenarios > --------------------------------------------------------------------------------- > > Key: ISPN-4910 > URL: https://issues.jboss.org/browse/ISPN-4910 > Project: Infinispan > Issue Type: Task > Components: Documentation-Core > Affects Versions: 7.0.0.CR2 > Reporter: Martin Gencur > > Document the following (inconsistent) behavior which was also described in an email thread http://lists.jboss.org/pipermail/infinispan-dev/2013-September/013769.html: > {code:java} > public void testSizeWithPreviousRead() throws Exception { > tm(0).begin(); > cache(0).put(k0, "v0"); > cache(0).put(k1, "v1"); > assertEquals(2, cache(0).size()); > tm(0).commit(); > tm(0).begin(); > //make sure we read k1 in this transaction > assertEquals("v1", cache(0).get(k1)); > final Transaction tx1 = tm(0).suspend(); > //another tx working on the same keys > tm(0).begin(); > //remove the key that was previously read in another tx > cache(0).remove(k1); > cache(0).put(k0, "v2"); > tm(0).commit(); > tm(0).resume(tx1); > //we read k1 earlier but in READ_COMMITTED MODE, the size() method should NOT take the key into account > assertEquals(1, cache(0).size()); > //^^^^^ the test fails here, cache.size() return 2 instead of expected 1 > assertEquals("v2", cache(0).get(k0)); > assertNull(cache(0).get(k1)); > tm(0).commit(); > assertNull(cache(1).get(k1)); > } > {code} > I will add tests as part of ISPN-4820 to show the behavior, we just need to document it. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4900) Split-brain: cancelled ST results in missing data

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-4900?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-4900: ------------------------------ Attachment: log.txt > Split-brain: cancelled ST results in missing data > ------------------------------------------------- > > Key: ISPN-4900 > URL: https://issues.jboss.org/browse/ISPN-4900 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Reporter: Radim Vansa > Priority: Critical > Attachments: log.txt > > > 1. Cluster [A, B, C, D], in CH 1 segment X owned by [D, C] > 2. Split brain [A, B], [C, D]: A and B detects that D is missing, therefore they get view [A, B, C] and start rebalancing, in CH 2 segment X is owned by [C, B] > 3. A and B get new view [A, B] (C is missing) and state transfer of X is cancelled, nodes enter degraded mode. > 4. Split brain is fixed, all nodes find each other and merge - B starts to be AVAILABLE, but still does not have data for X > 5. Subsequent requests on B return null upon cache.get() -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4910) Document inconsistent behavior of ReadCommitted isolation level in some scenarios

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-4910?page=com.atlassian.jira.plugin.... ] Martin Gencur updated ISPN-4910: -------------------------------- Summary: Document inconsistent behavior of ReadCommitted isolation level in some scenarios (was: Document incorrect behavior of ReadCommitted isolation level in some scenarios) > Document inconsistent behavior of ReadCommitted isolation level in some scenarios > --------------------------------------------------------------------------------- > > Key: ISPN-4910 > URL: https://issues.jboss.org/browse/ISPN-4910 > Project: Infinispan > Issue Type: Task > Components: Documentation-Core > Affects Versions: 7.0.0.CR2 > Reporter: Martin Gencur > > Document the following (incorrect and unexpected) behavior which was also described in an email thread http://lists.jboss.org/pipermail/infinispan-dev/2013-September/013769.html: > {code:java} > public void testSizeWithPreviousRead() throws Exception { > tm(0).begin(); > cache(0).put(k0, "v0"); > cache(0).put(k1, "v1"); > assertEquals(2, cache(0).size()); > tm(0).commit(); > tm(0).begin(); > //make sure we read k1 in this transaction > assertEquals("v1", cache(0).get(k1)); > final Transaction tx1 = tm(0).suspend(); > //another tx working on the same keys > tm(0).begin(); > //remove the key that was previously read in another tx > cache(0).remove(k1); > cache(0).put(k0, "v2"); > tm(0).commit(); > tm(0).resume(tx1); > //we read k1 earlier but in READ_COMMITTED MODE, the size() method should NOT take the key into account > assertEquals(1, cache(0).size()); > //^^^^^ the test fails here, cache.size() return 2 instead of expected 1 > assertEquals("v2", cache(0).get(k0)); > assertNull(cache(0).get(k1)); > tm(0).commit(); > assertNull(cache(1).get(k1)); > } > {code} > I will add tests as part of ISPN-4820 to show the behavior, we just need to document it. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4900) Split-brain: cancelled ST results in missing data

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-4900?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-4900: ------------------------------ Attachment: log.txt This is a log from different run. I think that it's not correct for the partition to become AVAILABLE at 11:54:53,901 > Split-brain: cancelled ST results in missing data > ------------------------------------------------- > > Key: ISPN-4900 > URL: https://issues.jboss.org/browse/ISPN-4900 > Project: Infinispan > Issue Type: Bug > Components: State Transfer > Reporter: Radim Vansa > Priority: Critical > Attachments: log.txt > > > 1. Cluster [A, B, C, D], in CH 1 segment X owned by [D, C] > 2. Split brain [A, B], [C, D]: A and B detects that D is missing, therefore they get view [A, B, C] and start rebalancing, in CH 2 segment X is owned by [C, B] > 3. A and B get new view [A, B] (C is missing) and state transfer of X is cancelled, nodes enter degraded mode. > 4. Split brain is fixed, all nodes find each other and merge - B starts to be AVAILABLE, but still does not have data for X > 5. Subsequent requests on B return null upon cache.get() -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4910) Document incorrect behavior of ReadCommitted isolation level in some scenarios

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4910?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-4910: ------------------------------------ [~mgencur] as discussed on the mailing list, the behaviour is just unexpected, not incorrect :) In READ_COMMITTED isolation, the second read is allowed to return _any_ committed value of {{k1}}, not necessarily the last committed value. > Document incorrect behavior of ReadCommitted isolation level in some scenarios > ------------------------------------------------------------------------------ > > Key: ISPN-4910 > URL: https://issues.jboss.org/browse/ISPN-4910 > Project: Infinispan > Issue Type: Task > Components: Documentation-Core > Affects Versions: 7.0.0.CR2 > Reporter: Martin Gencur > > Document the following (incorrect and unexpected) behavior which was also described in an email thread http://lists.jboss.org/pipermail/infinispan-dev/2013-September/013769.html: > {code:java} > public void testSizeWithPreviousRead() throws Exception { > tm(0).begin(); > cache(0).put(k0, "v0"); > cache(0).put(k1, "v1"); > assertEquals(2, cache(0).size()); > tm(0).commit(); > tm(0).begin(); > //make sure we read k1 in this transaction > assertEquals("v1", cache(0).get(k1)); > final Transaction tx1 = tm(0).suspend(); > //another tx working on the same keys > tm(0).begin(); > //remove the key that was previously read in another tx > cache(0).remove(k1); > cache(0).put(k0, "v2"); > tm(0).commit(); > tm(0).resume(tx1); > //we read k1 earlier but in READ_COMMITTED MODE, the size() method should NOT take the key into account > assertEquals(1, cache(0).size()); > //^^^^^ the test fails here, cache.size() return 2 instead of expected 1 > assertEquals("v2", cache(0).get(k0)); > assertNull(cache(0).get(k1)); > tm(0).commit(); > assertNull(cache(1).get(k1)); > } > {code} > I will add tests as part of ISPN-4820 to show the behavior, we just need to document it. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3718) Select which protobuf fields to index

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3718?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-3718: -------------------------------- Fix Version/s: 7.0.0.Final > Select which protobuf fields to index > ------------------------------------- > > Key: ISPN-3718 > URL: https://issues.jboss.org/browse/ISPN-3718 > Project: Infinispan > Issue Type: Feature Request > Components: Embedded Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 64QueryBlockers > Fix For: 7.0.0.Final > > > Currently we index all fields. An interesting idea is to use a custom protobuf Option (see 'Custom Options' section here https://developers.google.com/protocol-buffers/docs/proto) to indicate which message types and specifically which fields should be indexed, similar to Hibernate Search annotations. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3718) Select which protobuf fields to index

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-3718?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-3718: ------------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Select which protobuf fields to index > ------------------------------------- > > Key: ISPN-3718 > URL: https://issues.jboss.org/browse/ISPN-3718 > Project: Infinispan > Issue Type: Feature Request > Components: Embedded Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 64QueryBlockers > > Currently we index all fields. An interesting idea is to use a custom protobuf Option (see 'Custom Options' section here https://developers.google.com/protocol-buffers/docs/proto) to indicate which message types and specifically which fields should be indexed, similar to Hibernate Search annotations. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4907) Upgrade to protostream-2.0.0.Final

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-4907?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-4907: ------------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Upgrade to protostream-2.0.0.Final > ---------------------------------- > > Key: ISPN-4907 > URL: https://issues.jboss.org/browse/ISPN-4907 > Project: Infinispan > Issue Type: Component Upgrade > Components: Remote Querying > Affects Versions: 7.0.0.CR2 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4910) Document incorrect behavior of ReadCommitted isolation level in some scenarios

by Martin Gencur (JIRA)

Martin Gencur created ISPN-4910: ----------------------------------- Summary: Document incorrect behavior of ReadCommitted isolation level in some scenarios Key: ISPN-4910 URL: https://issues.jboss.org/browse/ISPN-4910 Project: Infinispan Issue Type: Task Components: Documentation-Core Affects Versions: 7.0.0.CR2 Reporter: Martin Gencur Document the following (incorrect and unexpected) behavior which was also described in an email thread http://lists.jboss.org/pipermail/infinispan-dev/2013-September/013769.html: {code:java} public void testSizeWithPreviousRead() throws Exception { tm(0).begin(); cache(0).put(k0, "v0"); cache(0).put(k1, "v1"); assertEquals(2, cache(0).size()); tm(0).commit(); tm(0).begin(); //make sure we read k1 in this transaction assertEquals("v1", cache(0).get(k1)); final Transaction tx1 = tm(0).suspend(); //another tx working on the same keys tm(0).begin(); //remove the key that was previously read in another tx cache(0).remove(k1); cache(0).put(k0, "v2"); tm(0).commit(); tm(0).resume(tx1); //we read k1 earlier but in READ_COMMITTED MODE, the size() method should NOT take the key into account assertEquals(1, cache(0).size()); //^^^^^ the test fails here, cache.size() return 2 instead of expected 1 assertEquals("v2", cache(0).get(k0)); assertNull(cache(0).get(k1)); tm(0).commit(); assertNull(cache(1).get(k1)); } {code} I will add tests as part of ISPN-4820 to show the behavior, we just need to document it. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4859) Make Soft Index File Store configuration more standard

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-4859?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-4859: ------------------------------ Status: Open (was: New) > Make Soft Index File Store configuration more standard > ------------------------------------------------------ > > Key: ISPN-4859 > URL: https://issues.jboss.org/browse/ISPN-4859 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Affects Versions: 7.0.0.CR1 > Reporter: Radim Vansa > Assignee: Radim Vansa > Priority: Minor > > The configuration uses camel-case etc... -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2014