Replication cache with indexing

[craigching]

I'm running Infinispan 5.0.1.FINAL and was wondering a bit about indexing.  I had been assuming that with a configuration like this:

    <loaders passivation="false" shared="false" preload="false">

      <loader class="org.infinispan.loaders.jdbm.JdbmCacheStore"

        fetchPersistentState="true"

        purgerThreads="10"

        purgeSynchronously="true"

        ignoreModifications="false"

        purgeOnStartup="false">

        <properties>

          <property name="location" value="./data/stores"/>

        </properties>

        <async enabled="false" flushLockTimeout="15000" threadPoolSize="20"/>

      </loader>

    </loaders>

    <clustering mode="replication">

      <stateRetrieval timeout="2000000" fetchInMemoryState="true"/>

      <sync/>

    </clustering>

    <eviction maxEntries="1000" strategy="LRU" wakeUpInterval="5000" />

    <indexing enabled="true" indexLocalOnly="false" />

    <invocationBatching enabled="true" />

that data would be indexed on the second+ node to join a cluster.  99% of the time, that works.  But occasionally we're seeing that objects sent by state transfer aren't getting indexed.  So I decided to read the documenation and I note that what I intuitively (and probably naively) thought would work isn't actually documented.

So why is this not a valid way to copy indexes?

EDIT:  I don't think I will ever understand the markup for these forums :-P

[galder.zamarreno]

I know, the formatting here is a bit weird

Hmmm, this particular issue does not ring a bell but there's been substantial changes to how state transfer works in 5.1, so I'd suggest you give it a go to 5.1.0.CR2. One thing to remember is that wakeUpInterval is now set in expiration element rather than eviction.

[craigching]

Ok, so indexes should be created during state transfer, that's very good news, I was afraid we were relying on behavior that wasn't expected or documented.  Thanks much for the response Galder!

I did try CR1 at one point, but I had a lot of problems with lucene write locks being left after shutdown and didn't want to take the time then to figure out if I had a configuration problem or if it was just a buggy CR ;-)  I'll give CR2 a try and see if I can get past those problems.  CR1 worked even worse than 5.0.1.FINAL, but because I was getting the stale write lock problems I kind of assumed it was related to that.

[galder.zamarreno]

If you had problems with CR1, you should have reported them. That's the point of CRs, finding those bits that might not be working fully as expected.

[craigching]

Understood and agree, but I'm in an OSGi environment and it's a lot of work to switch versions of infinispan around.  I promised to help out with that in whatever way I could when I get a bit more time (probably starting next month I can start helping to address some of the issues we regularly run into).

For instance, CR2 added a whole bunch of new dependencies (for the StAX parsing).  So creating a new bundle taking those into account can take me a day or more (to fully test etc.).  And I'm afraid of having to go through that for CR3, CR4, etc., so in that case it's unfortunately just easier for me to wait for the release when things have settled down.

So I apologize, but with extenuating circumstances ;-)

I will give CR2 a go though, I need to do everything I can to get this problem resolved.

[galder.zamarreno]

CR3 should go out today or tomorrow and changes are pretty much limited to bug fixes now. FINAL is coming soon after.