[JBoss JIRA] (ISPN-2958) Lucene Directory Read past EOF
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-2958?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-2958:
------------------------------
Fix Version/s: 7.0.0.Beta1
(was: 7.0.0.Alpha4)
> Lucene Directory Read past EOF
> ------------------------------
>
> Key: ISPN-2958
> URL: https://issues.jboss.org/browse/ISPN-2958
> Project: Infinispan
> Issue Type: Bug
> Components: Lucene Directory
> Affects Versions: 5.2.1.Final
> Reporter: Clement Pang
> Assignee: Pedro Ruivo
> Labels: retest, stable_embedded_query
> Fix For: 7.0.0.Beta1
>
>
> This seems to be happening rather deterministically.
> Infinispan configuration (in JBoss EAP 6.1.0.Alpha):
> {code}
> <cache-container name="lucene">
> <local-cache name="dshell-index-data" start="EAGER">
> <eviction strategy="LIRS" max-entries="50000"/>
> <file-store path="lucene" passivation="true" purge="false"/>
> </local-cache>
> <local-cache name="dshell-index-metadata" start="EAGER">
> <file-store path="lucene" passivation="true" purge="false"/>
> </local-cache>
> <local-cache name="dshell-index-lock" start="EAGER">
> <file-store path="lucene" passivation="true" purge="false"/>
> </local-cache>
> </cache-container>
> {code}
> Upon shutting down the server and confirming that passivation did indeed write the data to disk, the subsequent start-up would fail right away with:
> {code}
> Caused by: org.hibernate.search.SearchException: Could not initialize index
> at org.hibernate.search.store.impl.DirectoryProviderHelper.initializeIndexIfNeeded(DirectoryProviderHelper.java:162)
> at org.hibernate.search.infinispan.impl.InfinispanDirectoryProvider.start(InfinispanDirectoryProvider.java:103)
> at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:104)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:227)
> ... 64 more
> Caused by: java.io.IOException: Read past EOF
> at org.infinispan.lucene.SingleChunkIndexInput.readByte(SingleChunkIndexInput.java:77)
> at org.apache.lucene.store.ChecksumIndexInput.readByte(ChecksumIndexInput.java:41)
> at org.apache.lucene.store.DataInput.readInt(DataInput.java:86)
> at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:272)
> at org.apache.lucene.index.IndexFileDeleter.<init>(IndexFileDeleter.java:182)
> at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:1168)
> at org.hibernate.search.store.impl.DirectoryProviderHelper.initializeIndexIfNeeded(DirectoryProviderHelper.java:157)
> ... 67 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-3229) L1 cache entries should not be passivated
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3229?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3229:
------------------------------
Fix Version/s: 7.0.0.Beta1
(was: 7.0.0.Alpha4)
> L1 cache entries should not be passivated
> -----------------------------------------
>
> Key: ISPN-3229
> URL: https://issues.jboss.org/browse/ISPN-3229
> Project: Infinispan
> Issue Type: Bug
> Components: L1
> Affects Versions: 5.2.6.Final
> Reporter: William Burns
> Assignee: William Burns
> Fix For: 7.0.0.Beta1
>
> Attachments: DistSyncL1PassivationFuncTest.java
>
>
> L1 entries are stored in the same data container as the real entries. These can be evicted which is fine, however we don't want them to be passivated as this could be costly to write/read from the cache store. We should either prevent L1 cache entries from being passivated or have an option to allow for it.
> Currently L1 entries are not differentiated from other entries except through the fact that they are mortal, which is used for other operations as well, which means they would need a placeholder of some kind to tell the container this is a L1 entry.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months
[JBoss JIRA] (ISPN-3244) TopologyAwareSyncConsistentHashFactory should limit the number of segments per node
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3244?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3244:
------------------------------
Fix Version/s: 7.0.0.Beta1
(was: 7.0.0.Alpha4)
> TopologyAwareSyncConsistentHashFactory should limit the number of segments per node
> -----------------------------------------------------------------------------------
>
> Key: ISPN-3244
> URL: https://issues.jboss.org/browse/ISPN-3244
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 5.2.6.Final, 5.3.0.CR2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 7.0.0.Beta1
>
>
> Let's say we have a cluster with 5 nodes: A(r1), B(r2), C(r2), D(r3), E(r3)
> TopologyAwareConsistentSyncHashFactory will spread the segments equally on each rack, meaning A will own 2x segments compared to the other nodes.
> TopologyAwareConsistentHashFactory limits the maximum number per node, so that A owns just as many segments as the other nodes. With a slight limitation: the number of racks must be greater than numOwners, otherwise each rack must hold (at least) one copy of all the data.
> TopologyAwareConsistentSyncHashFactory is a little random, so we can't distribute the data perfectly, but we can limit the number of segments on each node to something like 1.5x the average number of segments.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months