5 Replies Latest reply on Jan 9, 2012 11:20 AM by Galder Zamarreño

    Replication cache with indexing

    Craig Ching Newbie

      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"







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


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





          <clustering mode="replication">

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




          <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

        • 1. Re: Replication cache with indexing
          Galder Zamarreño Master

          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.

          • 2. Re: Replication cache with indexing
            Craig Ching Newbie

            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.

            • 3. Re: Replication cache with indexing
              Galder Zamarreño Master

              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.

              • 4. Re: Replication cache with indexing
                Craig Ching Newbie

                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.

                • 5. Re: Replication cache with indexing
                  Galder Zamarreño Master

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