Re: Strange behaviour on replicated cache with FIFO eviction policy

[Andrey Mashenkov <an...@gmail.com>]

Hi,

Please properly subscribe to the mailing list so that the community can
receive email notifications for your messages. To subscribe, send empty
email to user-subscribe@ignite.apache.org and follow simple instructions in
the reply.



I've made a test and fifo eviction policy works fine for me on ignite 1.7,
1.8, 1.9 and master.
However, I found a bug that cache size can be wrong until first write
attempt to cache. I've create a ticket [1]

PFA repro.

[1] https://issues.apache.org/jira/browse/IGNITE-4881


You wrote:

We are configuring an ignite 1.7.0 setup with to server nodes and several
> client ones to use it as a temporary cache. We need that all the info is
> available even if one of the server nodes goes down so we choose to have
> our cache in REPLICATED mode. We also want that there are no more than n
> entries on our cache, so we have limited the size of it with a FIFO
> eviction policy.
> In out testing we configure an eviction policy with a max size of 15. Then
> run a simple loop that inserts 20 entries on the cache named from key0 to
> key19. After running the loop, conncting with ignitevisord and running
> cache -scan shows all 20 entries. Then we take down one server node. Get it
> up again. Let the cluster time to replicate the data and take down the
> other server node. Then a cache -scan returns 15 of the 20 initial entries
> selected at "random", but what we expected was to see the last 15: from
> key5 to key19. Because of the first five had been evicted and didn't
> survive the nodes restart.
> I suspect an error in either the configuration of the cache or in our
> understanding of the replication - eviction interaction. ¿ Can anyone
> enlight us on what is happening ?
> We are defining our cache statically on the server nodes xml config file
> like this:
>   <property name="cacheConfiguration">
>    <bean class="org.apache.ignite.configuration.CacheConfiguration">
>     <property name="name" value="TEST"/>
>     <property name="cacheMode" value="REPLICATED"/>
>     <property name="writeSynchronizationMode" value="PRIMARY_SYNC"/>
>     <property name="atomicityMode" value="ATOMIC"/>
>     <property name="rebalanceMode" value="ASYNC"/>
>     <!-- Expire data after 10 minutes -->
>     <property name="expiryPolicyFactory">
>      <bean id="expiryPolicy"
> class="javax.cache.expiry.CreatedExpiryPolicy" factory-method="factoryOf">
>       <constructor-arg>
>        <bean class="javax.cache.expiry.Duration">
>         <constructor-arg value="SECONDS"/>
>         <constructor-arg value="600"/>
>        </bean>
>       </constructor-arg>
>      </bean>
>     </property>
>     <!-- Eviction policy: keep only 15 elements -->
>     <property name="evictionPolicy">
>      <bean
> class="org.apache.ignite.cache.eviction.fifo.FifoEvictionPolicy">
>       <property name="maxSize" value="15"/>
>      </bean>
>     </property>
>     -<property name="offHeapMaxMemory" value="-1"/>
>     <property name="swapEnabled" value="false"/>
>    </bean>
>   </property>
> For populating the cache we are using a simple java class that connects to
> the cluster and inerts the values on the cache. We use NearCache in our
> client connection with an eviction policy of 10.
>

-- 

Best regards,
Andrey V. Mashenkov