[JBoss JIRA] (ISPN-3431) Lost version info state transfer causes overwtite of newer data that joining node has read from store
by Nikolay Martynov (JIRA)
[ https://issues.jboss.org/browse/ISPN-3431?page=com.atlassian.jira.plugin.... ]
Nikolay Martynov updated ISPN-3431:
-----------------------------------
Environment:
uname -s ; cat /etc/redhat-release ; java -version
Linux
Red Hat Enterprise Linux Server release 5.9 (Tikanga)
java version "1.6.0_30"
Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode)
was:
{noformat}
uname -s ; cat /etc/redhat-release ; java -version
Linux
Red Hat Enterprise Linux Server release 5.9 (Tikanga)
java version "1.6.0_30"
Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode)
{noformat}
> Lost version info state transfer causes overwtite of newer data that joining node has read from store
> -----------------------------------------------------------------------------------------------------
>
> Key: ISPN-3431
> URL: https://issues.jboss.org/browse/ISPN-3431
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 6.0.0.Alpha3
> Environment: uname -s ; cat /etc/redhat-release ; java -version
> Linux
> Red Hat Enterprise Linux Server release 5.9 (Tikanga)
> java version "1.6.0_30"
> Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode)
> Reporter: Nikolay Martynov
> Assignee: Mircea Markus
>
> When state transfer sends data to newly joining node no version information is provided despite the fact that this information is available to the cluster (for example, loaded from store). When newly joining node has loaded from its store newer version of data than cluster has then this newer version of data is overwritten because no version information is provided during state transfer.
> Scenario:
> {noformat}
> 1. Start node1, node2, node3
> 2. Put {A=>A1} from node1
> 3. Put {B=>B1} from node2
> 4. Put {C=>C1} from node3
> 5. Gracefully shutdown node1 saving the data
> 6. Gracefully shutdown node2 saving the data
> 7. Put {C=>C2} from node3
> 8. Gracefully shutdown node3 saving the data
> 9. Start node1 loading the data
> 10. Start node2 loading the data
> 11. Start node3 loading the data
> {noformat}
> Loaded from store on node3 - version information shows its newer than nodes 1 and 2 have:
> {noformat}
> org.infinispan.interceptors.CallInterceptor
> Executing command: PutKeyValueCommand{key=C, value=C2, flags=[CACHE_MODE_LOCAL, SKIP_LOCKING, SKIP_CACHE_STORE, SKIP_INDEXING, SKIP_OWNERSHIP_CHECK, IGNORE_RETURN_VALUES], putIfAbsent=false, metadata=EmbeddedMetadata{version=SimpleClusteredVersion{topologyId=8, version=2}}, successful=true, ignorePreviousValue=false}.
> {noformat}
> During state transfer older value C1 is received with version information being null:
> {noformat}
> org.infinispan.statetransfer.StateTransferInterceptor
> handleNonTxWriteCommand for command PutKeyValueCommand{key=C, value=C1, flags=[CACHE_MODE_LOCAL, SKIP_REMOTE_LOOKUP, PUT_FOR_STATE_TRANSFER, SKIP_SHARED_CACHE_STORE, SKIP_OWNERSHIP_CHECK, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, metadata=EmbeddedMetadata{version=null}, successful=true, ignorePreviousValue=false}
> {noformat}
> As a result newer value is replaced with older:
> {noformat}
> org.infinispan.interceptors.EntryWrappingInterceptor
> About to commit entry ClusteredRepeatableReadEntry(323f265b){key=C, value=C1, oldValue=C2, isCreated=false, isChanged=true, isRemoved=false, isValid=true, skipRemoteGet=true, metadata=EmbeddedMetadata{version=SimpleClusteredVersion{topologyId=8, version=2}}}
> {noformat}
> As far as i can see, any key on any node that it didnt written but has received during resync has version=null after loading from store.
> Config:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <!--
> This is just a very simplistic example configuration file. For more information, please see
> http://docs.jboss.org/infinispan/5.3/configdocs/infinispan-config-5.3.html
> -->
> <infinispan
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="urn:infinispan:config:6.0 http://docs.jboss.org/infinispan/schemas/infinispan-config-6.0.xsd"
> xmlns="urn:infinispan:config:6.0">
> <global>
> <globalJmxStatistics enabled="true" jmxDomain="Infinispan" />
> <transport>
> <properties>
> <property name="configurationFile" value="jgroups.xml" />
> </properties>
> </transport>
> </global>
> <namedCache name="routing_table">
> <clustering mode="REPL">
> <stateTransfer awaitInitialTransfer="true" fetchInMemoryState="true"/>
> <sync replTimeout="1000"/>
> <!--async useReplQueue="true" replQueueMaxElements="100" /-->
> </clustering>
> <loaders passivation="false" shared="false" preload="true">
> <singleFileStore
> location="target/routing_table${infinispan.store_name:not_specified}/">
> </singleFileStore>
> </loaders>
> <versioning enabled="true" versioningScheme="SIMPLE"/>
> <transaction
> transactionMode="TRANSACTIONAL"
> autoCommit="true"
> transactionManagerLookupClass="org.infinispan.transaction.lookup.GenericTransactionManagerLookup"
> lockingMode="OPTIMISTIC"
> />
> <locking
> writeSkewCheck="true"
> isolationLevel="REPEATABLE_READ"/>
> </namedCache>
> </infinispan>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (ISPN-3431) Lost version info state transfer causes overwtite of newer data that joining node has read from store
by Nikolay Martynov (JIRA)
[ https://issues.jboss.org/browse/ISPN-3431?page=com.atlassian.jira.plugin.... ]
Nikolay Martynov updated ISPN-3431:
-----------------------------------
Environment:
{noformat}
uname -s ; cat /etc/redhat-release ; java -version
Linux
Red Hat Enterprise Linux Server release 5.9 (Tikanga)
java version "1.6.0_30"
Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode)
{noformat}
was:
uname -s ; cat /etc/redhat-release ; java -version
Linux
Red Hat Enterprise Linux Server release 5.9 (Tikanga)
java version "1.6.0_30"
Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode)
> Lost version info state transfer causes overwtite of newer data that joining node has read from store
> -----------------------------------------------------------------------------------------------------
>
> Key: ISPN-3431
> URL: https://issues.jboss.org/browse/ISPN-3431
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 6.0.0.Alpha3
> Environment: {noformat}
> uname -s ; cat /etc/redhat-release ; java -version
> Linux
> Red Hat Enterprise Linux Server release 5.9 (Tikanga)
> java version "1.6.0_30"
> Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode)
> {noformat}
> Reporter: Nikolay Martynov
> Assignee: Mircea Markus
>
> When state transfer sends data to newly joining node no version information is provided despite the fact that this information is available to the cluster (for example, loaded from store). When newly joining node has loaded from its store newer version of data than cluster has then this newer version of data is overwritten because no version information is provided during state transfer.
> Scenario:
> {noformat}
> 1. Start node1, node2, node3
> 2. Put {A=>A1} from node1
> 3. Put {B=>B1} from node2
> 4. Put {C=>C1} from node3
> 5. Gracefully shutdown node1 saving the data
> 6. Gracefully shutdown node2 saving the data
> 7. Put {C=>C2} from node3
> 8. Gracefully shutdown node3 saving the data
> 9. Start node1 loading the data
> 10. Start node2 loading the data
> 11. Start node3 loading the data
> {noformat}
> Loaded from store on node3 - version information shows its newer than nodes 1 and 2 have:
> {noformat}
> org.infinispan.interceptors.CallInterceptor
> Executing command: PutKeyValueCommand{key=C, value=C2, flags=[CACHE_MODE_LOCAL, SKIP_LOCKING, SKIP_CACHE_STORE, SKIP_INDEXING, SKIP_OWNERSHIP_CHECK, IGNORE_RETURN_VALUES], putIfAbsent=false, metadata=EmbeddedMetadata{version=SimpleClusteredVersion{topologyId=8, version=2}}, successful=true, ignorePreviousValue=false}.
> {noformat}
> During state transfer older value C1 is received with version information being null:
> {noformat}
> org.infinispan.statetransfer.StateTransferInterceptor
> handleNonTxWriteCommand for command PutKeyValueCommand{key=C, value=C1, flags=[CACHE_MODE_LOCAL, SKIP_REMOTE_LOOKUP, PUT_FOR_STATE_TRANSFER, SKIP_SHARED_CACHE_STORE, SKIP_OWNERSHIP_CHECK, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, metadata=EmbeddedMetadata{version=null}, successful=true, ignorePreviousValue=false}
> {noformat}
> As a result newer value is replaced with older:
> {noformat}
> org.infinispan.interceptors.EntryWrappingInterceptor
> About to commit entry ClusteredRepeatableReadEntry(323f265b){key=C, value=C1, oldValue=C2, isCreated=false, isChanged=true, isRemoved=false, isValid=true, skipRemoteGet=true, metadata=EmbeddedMetadata{version=SimpleClusteredVersion{topologyId=8, version=2}}}
> {noformat}
> As far as i can see, any key on any node that it didnt written but has received during resync has version=null after loading from store.
> Config:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <!--
> This is just a very simplistic example configuration file. For more information, please see
> http://docs.jboss.org/infinispan/5.3/configdocs/infinispan-config-5.3.html
> -->
> <infinispan
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="urn:infinispan:config:6.0 http://docs.jboss.org/infinispan/schemas/infinispan-config-6.0.xsd"
> xmlns="urn:infinispan:config:6.0">
> <global>
> <globalJmxStatistics enabled="true" jmxDomain="Infinispan" />
> <transport>
> <properties>
> <property name="configurationFile" value="jgroups.xml" />
> </properties>
> </transport>
> </global>
> <namedCache name="routing_table">
> <clustering mode="REPL">
> <stateTransfer awaitInitialTransfer="true" fetchInMemoryState="true"/>
> <sync replTimeout="1000"/>
> <!--async useReplQueue="true" replQueueMaxElements="100" /-->
> </clustering>
> <loaders passivation="false" shared="false" preload="true">
> <singleFileStore
> location="target/routing_table${infinispan.store_name:not_specified}/">
> </singleFileStore>
> </loaders>
> <versioning enabled="true" versioningScheme="SIMPLE"/>
> <transaction
> transactionMode="TRANSACTIONAL"
> autoCommit="true"
> transactionManagerLookupClass="org.infinispan.transaction.lookup.GenericTransactionManagerLookup"
> lockingMode="OPTIMISTIC"
> />
> <locking
> writeSkewCheck="true"
> isolationLevel="REPEATABLE_READ"/>
> </namedCache>
> </infinispan>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (ISPN-3431) Lost version info state transfer causes overwtite of newer data that joining node has read from store
by Nikolay Martynov (JIRA)
[ https://issues.jboss.org/browse/ISPN-3431?page=com.atlassian.jira.plugin.... ]
Nikolay Martynov updated ISPN-3431:
-----------------------------------
Description:
When state transfer sends data to newly joining node no version information is provided despite the fact that this information is available to the cluster (for example, loaded from store). When newly joining node has loaded from its store newer version of data than cluster has then this newer version of data is overwritten because no version information is provided during state transfer.
Scenario:
{noformat}
1. Start node1, node2, node3
2. Put {A=>A1} from node1
3. Put {B=>B1} from node2
4. Put {C=>C1} from node3
5. Gracefully shutdown node1 saving the data
6. Gracefully shutdown node2 saving the data
7. Put {C=>C2} from node3
8. Gracefully shutdown node3 saving the data
9. Start node1 loading the data
10. Start node2 loading the data
11. Start node3 loading the data
{noformat}
Loaded from store on node3 - version information shows its newer than nodes 1 and 2 have:
{noformat}
org.infinispan.interceptors.CallInterceptor
Executing command: PutKeyValueCommand{key=C, value=C2, flags=[CACHE_MODE_LOCAL, SKIP_LOCKING, SKIP_CACHE_STORE, SKIP_INDEXING, SKIP_OWNERSHIP_CHECK, IGNORE_RETURN_VALUES], putIfAbsent=false, metadata=EmbeddedMetadata{version=SimpleClusteredVersion{topologyId=8, version=2}}, successful=true, ignorePreviousValue=false}.
{noformat}
During state transfer older value C1 is received with version information being null:
{noformat}
org.infinispan.statetransfer.StateTransferInterceptor
handleNonTxWriteCommand for command PutKeyValueCommand{key=C, value=C1, flags=[CACHE_MODE_LOCAL, SKIP_REMOTE_LOOKUP, PUT_FOR_STATE_TRANSFER, SKIP_SHARED_CACHE_STORE, SKIP_OWNERSHIP_CHECK, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, metadata=EmbeddedMetadata{version=null}, successful=true, ignorePreviousValue=false}
{noformat}
As a result newer value is replaced with older:
{noformat}
org.infinispan.interceptors.EntryWrappingInterceptor
About to commit entry ClusteredRepeatableReadEntry(323f265b){key=C, value=C1, oldValue=C2, isCreated=false, isChanged=true, isRemoved=false, isValid=true, skipRemoteGet=true, metadata=EmbeddedMetadata{version=SimpleClusteredVersion{topologyId=8, version=2}}}
{noformat}
As far as i can see, any key on any node that it didnt written but has received during resync has version=null after loading from store.
Config:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<!--
This is just a very simplistic example configuration file. For more information, please see
http://docs.jboss.org/infinispan/5.3/configdocs/infinispan-config-5.3.html
-->
<infinispan
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:infinispan:config:6.0 http://docs.jboss.org/infinispan/schemas/infinispan-config-6.0.xsd"
xmlns="urn:infinispan:config:6.0">
<global>
<globalJmxStatistics enabled="true" jmxDomain="Infinispan" />
<transport>
<properties>
<property name="configurationFile" value="jgroups.xml" />
</properties>
</transport>
</global>
<namedCache name="routing_table">
<clustering mode="REPL">
<stateTransfer awaitInitialTransfer="true" fetchInMemoryState="true"/>
<sync replTimeout="1000"/>
<!--async useReplQueue="true" replQueueMaxElements="100" /-->
</clustering>
<loaders passivation="false" shared="false" preload="true">
<singleFileStore
location="target/routing_table${infinispan.store_name:not_specified}/">
</singleFileStore>
</loaders>
<versioning enabled="true" versioningScheme="SIMPLE"/>
<transaction
transactionMode="TRANSACTIONAL"
autoCommit="true"
transactionManagerLookupClass="org.infinispan.transaction.lookup.GenericTransactionManagerLookup"
lockingMode="OPTIMISTIC"
/>
<locking
writeSkewCheck="true"
isolationLevel="REPEATABLE_READ"/>
</namedCache>
</infinispan>
{code}
was:
When state transfer sends data to newly joining node no version information is provided despite the fact that this information is available to the cluster (for example, loaded from store). When newly joining node has loaded from its store newer version of data than cluster has then this newer version of data is overwritten because no version information is provided during state transfer.
Scenario:
1. Start node1, node2, node3
2. Put {A=>A1} from node1
3. Put {B=>B1} from node2
4. Put {C=>C1} from node3
5. Gracefully shutdown node1 saving the data
6. Gracefully shutdown node2 saving the data
7. Put {C=>C2} from node3
8. Gracefully shutdown node3 saving the data
9. Start node1 loading the data
10. Start node2 loading the data
11. Start node3 loading the data
Loaded from store on node3 - version information shows its newer than nodes 1 and 2 have:
org.infinispan.interceptors.CallInterceptor
Executing command: PutKeyValueCommand{key=C, value=C2, flags=[CACHE_MODE_LOCAL, SKIP_LOCKING, SKIP_CACHE_STORE, SKIP_INDEXING, SKIP_OWNERSHIP_CHECK, IGNORE_RETURN_VALUES], putIfAbsent=false, metadata=EmbeddedMetadata{version=SimpleClusteredVersion{topologyId=8, version=2}}, successful=true, ignorePreviousValue=false}.
During state transfer older value C1 is received with version information being null:
org.infinispan.statetransfer.StateTransferInterceptor
handleNonTxWriteCommand for command PutKeyValueCommand{key=C, value=C1, flags=[CACHE_MODE_LOCAL, SKIP_REMOTE_LOOKUP, PUT_FOR_STATE_TRANSFER, SKIP_SHARED_CACHE_STORE, SKIP_OWNERSHIP_CHECK, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, metadata=EmbeddedMetadata{version=null}, successful=true, ignorePreviousValue=false}
As a result newer value is replaced with older:
org.infinispan.interceptors.EntryWrappingInterceptor
About to commit entry ClusteredRepeatableReadEntry(323f265b){key=C, value=C1, oldValue=C2, isCreated=false, isChanged=true, isRemoved=false, isValid=true, skipRemoteGet=true, metadata=EmbeddedMetadata{version=SimpleClusteredVersion{topologyId=8, version=2}}}
As far as i can see, any key on any node that it didnt written but has received during resync has version=null after loading from store.
Config:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<!--
This is just a very simplistic example configuration file. For more information, please see
http://docs.jboss.org/infinispan/5.3/configdocs/infinispan-config-5.3.html
-->
<infinispan
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:infinispan:config:6.0 http://docs.jboss.org/infinispan/schemas/infinispan-config-6.0.xsd"
xmlns="urn:infinispan:config:6.0">
<global>
<globalJmxStatistics enabled="true" jmxDomain="Infinispan" />
<transport>
<properties>
<property name="configurationFile" value="jgroups.xml" />
</properties>
</transport>
</global>
<namedCache name="routing_table">
<clustering mode="REPL">
<stateTransfer awaitInitialTransfer="true" fetchInMemoryState="true"/>
<sync replTimeout="1000"/>
<!--async useReplQueue="true" replQueueMaxElements="100" /-->
</clustering>
<loaders passivation="false" shared="false" preload="true">
<singleFileStore
location="target/routing_table${infinispan.store_name:not_specified}/">
</singleFileStore>
</loaders>
<versioning enabled="true" versioningScheme="SIMPLE"/>
<transaction
transactionMode="TRANSACTIONAL"
autoCommit="true"
transactionManagerLookupClass="org.infinispan.transaction.lookup.GenericTransactionManagerLookup"
lockingMode="OPTIMISTIC"
/>
<locking
writeSkewCheck="true"
isolationLevel="REPEATABLE_READ"/>
</namedCache>
</infinispan>
{code}
> Lost version info state transfer causes overwtite of newer data that joining node has read from store
> -----------------------------------------------------------------------------------------------------
>
> Key: ISPN-3431
> URL: https://issues.jboss.org/browse/ISPN-3431
> Project: Infinispan
> Issue Type: Bug
> Components: State transfer
> Affects Versions: 6.0.0.Alpha3
> Environment: uname -s ; cat /etc/redhat-release ; java -version
> Linux
> Red Hat Enterprise Linux Server release 5.9 (Tikanga)
> java version "1.6.0_30"
> Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode)
> Reporter: Nikolay Martynov
> Assignee: Mircea Markus
>
> When state transfer sends data to newly joining node no version information is provided despite the fact that this information is available to the cluster (for example, loaded from store). When newly joining node has loaded from its store newer version of data than cluster has then this newer version of data is overwritten because no version information is provided during state transfer.
> Scenario:
> {noformat}
> 1. Start node1, node2, node3
> 2. Put {A=>A1} from node1
> 3. Put {B=>B1} from node2
> 4. Put {C=>C1} from node3
> 5. Gracefully shutdown node1 saving the data
> 6. Gracefully shutdown node2 saving the data
> 7. Put {C=>C2} from node3
> 8. Gracefully shutdown node3 saving the data
> 9. Start node1 loading the data
> 10. Start node2 loading the data
> 11. Start node3 loading the data
> {noformat}
> Loaded from store on node3 - version information shows its newer than nodes 1 and 2 have:
> {noformat}
> org.infinispan.interceptors.CallInterceptor
> Executing command: PutKeyValueCommand{key=C, value=C2, flags=[CACHE_MODE_LOCAL, SKIP_LOCKING, SKIP_CACHE_STORE, SKIP_INDEXING, SKIP_OWNERSHIP_CHECK, IGNORE_RETURN_VALUES], putIfAbsent=false, metadata=EmbeddedMetadata{version=SimpleClusteredVersion{topologyId=8, version=2}}, successful=true, ignorePreviousValue=false}.
> {noformat}
> During state transfer older value C1 is received with version information being null:
> {noformat}
> org.infinispan.statetransfer.StateTransferInterceptor
> handleNonTxWriteCommand for command PutKeyValueCommand{key=C, value=C1, flags=[CACHE_MODE_LOCAL, SKIP_REMOTE_LOOKUP, PUT_FOR_STATE_TRANSFER, SKIP_SHARED_CACHE_STORE, SKIP_OWNERSHIP_CHECK, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, metadata=EmbeddedMetadata{version=null}, successful=true, ignorePreviousValue=false}
> {noformat}
> As a result newer value is replaced with older:
> {noformat}
> org.infinispan.interceptors.EntryWrappingInterceptor
> About to commit entry ClusteredRepeatableReadEntry(323f265b){key=C, value=C1, oldValue=C2, isCreated=false, isChanged=true, isRemoved=false, isValid=true, skipRemoteGet=true, metadata=EmbeddedMetadata{version=SimpleClusteredVersion{topologyId=8, version=2}}}
> {noformat}
> As far as i can see, any key on any node that it didnt written but has received during resync has version=null after loading from store.
> Config:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <!--
> This is just a very simplistic example configuration file. For more information, please see
> http://docs.jboss.org/infinispan/5.3/configdocs/infinispan-config-5.3.html
> -->
> <infinispan
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="urn:infinispan:config:6.0 http://docs.jboss.org/infinispan/schemas/infinispan-config-6.0.xsd"
> xmlns="urn:infinispan:config:6.0">
> <global>
> <globalJmxStatistics enabled="true" jmxDomain="Infinispan" />
> <transport>
> <properties>
> <property name="configurationFile" value="jgroups.xml" />
> </properties>
> </transport>
> </global>
> <namedCache name="routing_table">
> <clustering mode="REPL">
> <stateTransfer awaitInitialTransfer="true" fetchInMemoryState="true"/>
> <sync replTimeout="1000"/>
> <!--async useReplQueue="true" replQueueMaxElements="100" /-->
> </clustering>
> <loaders passivation="false" shared="false" preload="true">
> <singleFileStore
> location="target/routing_table${infinispan.store_name:not_specified}/">
> </singleFileStore>
> </loaders>
> <versioning enabled="true" versioningScheme="SIMPLE"/>
> <transaction
> transactionMode="TRANSACTIONAL"
> autoCommit="true"
> transactionManagerLookupClass="org.infinispan.transaction.lookup.GenericTransactionManagerLookup"
> lockingMode="OPTIMISTIC"
> />
> <locking
> writeSkewCheck="true"
> isolationLevel="REPEATABLE_READ"/>
> </namedCache>
> </infinispan>
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (ISPN-3431) Lost version info state transfer causes overwtite of newer data that joining node has read from store
by Nikolay Martynov (JIRA)
Nikolay Martynov created ISPN-3431:
--------------------------------------
Summary: Lost version info state transfer causes overwtite of newer data that joining node has read from store
Key: ISPN-3431
URL: https://issues.jboss.org/browse/ISPN-3431
Project: Infinispan
Issue Type: Bug
Components: State transfer
Affects Versions: 6.0.0.Alpha3
Environment: uname -s ; cat /etc/redhat-release ; java -version
Linux
Red Hat Enterprise Linux Server release 5.9 (Tikanga)
java version "1.6.0_30"
Java(TM) SE Runtime Environment (build 1.6.0_30-b12)
Java HotSpot(TM) 64-Bit Server VM (build 20.5-b03, mixed mode)
Reporter: Nikolay Martynov
Assignee: Mircea Markus
When state transfer sends data to newly joining node no version information is provided despite the fact that this information is available to the cluster (for example, loaded from store). When newly joining node has loaded from its store newer version of data than cluster has then this newer version of data is overwritten because no version information is provided during state transfer.
Scenario:
1. Start node1, node2, node3
2. Put {A=>A1} from node1
3. Put {B=>B1} from node2
4. Put {C=>C1} from node3
5. Gracefully shutdown node1 saving the data
6. Gracefully shutdown node2 saving the data
7. Put {C=>C2} from node3
8. Gracefully shutdown node3 saving the data
9. Start node1 loading the data
10. Start node2 loading the data
11. Start node3 loading the data
Loaded from store on node3 - version information shows its newer than nodes 1 and 2 have:
org.infinispan.interceptors.CallInterceptor
Executing command: PutKeyValueCommand{key=C, value=C2, flags=[CACHE_MODE_LOCAL, SKIP_LOCKING, SKIP_CACHE_STORE, SKIP_INDEXING, SKIP_OWNERSHIP_CHECK, IGNORE_RETURN_VALUES], putIfAbsent=false, metadata=EmbeddedMetadata{version=SimpleClusteredVersion{topologyId=8, version=2}}, successful=true, ignorePreviousValue=false}.
During state transfer older value C1 is received with version information being null:
org.infinispan.statetransfer.StateTransferInterceptor
handleNonTxWriteCommand for command PutKeyValueCommand{key=C, value=C1, flags=[CACHE_MODE_LOCAL, SKIP_REMOTE_LOOKUP, PUT_FOR_STATE_TRANSFER, SKIP_SHARED_CACHE_STORE, SKIP_OWNERSHIP_CHECK, IGNORE_RETURN_VALUES, SKIP_XSITE_BACKUP], putIfAbsent=false, metadata=EmbeddedMetadata{version=null}, successful=true, ignorePreviousValue=false}
As a result newer value is replaced with older:
org.infinispan.interceptors.EntryWrappingInterceptor
About to commit entry ClusteredRepeatableReadEntry(323f265b){key=C, value=C1, oldValue=C2, isCreated=false, isChanged=true, isRemoved=false, isValid=true, skipRemoteGet=true, metadata=EmbeddedMetadata{version=SimpleClusteredVersion{topologyId=8, version=2}}}
As far as i can see, any key on any node that it didnt written but has received during resync has version=null after loading from store.
Config:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<!--
This is just a very simplistic example configuration file. For more information, please see
http://docs.jboss.org/infinispan/5.3/configdocs/infinispan-config-5.3.html
-->
<infinispan
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:infinispan:config:6.0 http://docs.jboss.org/infinispan/schemas/infinispan-config-6.0.xsd"
xmlns="urn:infinispan:config:6.0">
<global>
<globalJmxStatistics enabled="true" jmxDomain="Infinispan" />
<transport>
<properties>
<property name="configurationFile" value="jgroups.xml" />
</properties>
</transport>
</global>
<namedCache name="routing_table">
<clustering mode="REPL">
<stateTransfer awaitInitialTransfer="true" fetchInMemoryState="true"/>
<sync replTimeout="1000"/>
<!--async useReplQueue="true" replQueueMaxElements="100" /-->
</clustering>
<loaders passivation="false" shared="false" preload="true">
<singleFileStore
location="target/routing_table${infinispan.store_name:not_specified}/">
</singleFileStore>
</loaders>
<versioning enabled="true" versioningScheme="SIMPLE"/>
<transaction
transactionMode="TRANSACTIONAL"
autoCommit="true"
transactionManagerLookupClass="org.infinispan.transaction.lookup.GenericTransactionManagerLookup"
lockingMode="OPTIMISTIC"
/>
<locking
writeSkewCheck="true"
isolationLevel="REPEATABLE_READ"/>
</namedCache>
</infinispan>
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months
[JBoss JIRA] (ISPN-1822) Cache entry not evicted from memory on IBM JDK when another entry was loaded from a cache loader and maxEntries had been reached
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-1822?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-1822:
------------------------------
Fix Version/s: 6.0.0.Beta1
(was: 6.0.0.Alpha3)
> Cache entry not evicted from memory on IBM JDK when another entry was loaded from a cache loader and maxEntries had been reached
> --------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-1822
> URL: https://issues.jboss.org/browse/ISPN-1822
> Project: Infinispan
> Issue Type: Bug
> Components: Eviction
> Affects Versions: 5.1.0.FINAL
> Environment: java version "1.6.0"
> Java(TM) SE Runtime Environment (build pxi3260sr9fp1-20110208_03(SR9 FP1))
> IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux x86-32 jvmxi3260sr9-20110203_74623 (JIT enabled, AOT enabled) ;
> java version "1.7.0"
> Java(TM) SE Runtime Environment (build pxi3270-20110827_01)
> IBM J9 VM (build 2.6, JRE 1.7.0 Linux x86-32 20110810_88604 (JIT enabled, AOT enabled)
> Reporter: Martin Gencur
> Assignee: Tristan Tarrant
> Fix For: 6.0.0.Beta1
>
>
> This behavior is specific to IBM JDK (I tried JDK6 and 7), it works fine with Java HotSpot.
> Steps to reproduce the problem:
> 1) set maxEntries for eviction to 2 and algorithm e.g. to LRU
> 2) store 3 entries key1, key2, key3 to the cache (after that you can see that the cache contains only 2 entries - key2 and key3, the first one was evicted from memory)
> 3) call cache.get("key1")
> 4) PROBLEM - cache contains all key1, key2, key3 even though it should contain only 2 entries - only happens with IBM JDK (6 or 7 ..no matter)
> I'll shortly issue a pull request with a test to ispn-core
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 7 months