Andrey, Using factory instead of policy instance in configuration makes sense to me, I think we should do this change.
As for Hadoop module issue, is it possible to do the mentioned validation after creating the policy? I think that should fix the problem. -Val On Thu, Oct 19, 2017 at 7:50 AM Andrey Mashenkov <andrey.mashen...@gmail.com> wrote: > Hi Igniters, > > I'm working on a ticket IGNITE-6649 [1] and got stuck. > Currently, we allow user to set EvictionPolicy instance into configuration > instead of factory. > The leads to some isses when user tries to reuse EvictionPolicy instance, > e.g. it doesn't clean its queue on cache stop. > > Seems, we should replace EvictionPolicy with its factory as policy objec is > a statefull object and current approach is error prone. > > The issue I faced is that we make checks for EvicitonPolicy derives some > known class in several code places. > E.g. in HadoopModule you can find IgfsPerBlockLruEvictionPolicy usages. > What will be correct way to overwork this with using facrories? > > > Also, I've noticed that we check EvictionPolicy instances if they implement > LifecycleAware interface and no one policy available out-of-box really > implements it. > The second way here is to make these EvictionPolicies implements > LifecycleAware interface and gracefully clean their queues. > This will resolve the issue for case when user recreate cache with same > configuration instance, > but seem will not help in case when user share EvictionPolicy instance for > several caches. > > > Also`EvictionPolicies has non-transient "queue" field, so queue may leak to > another node. > I'm not sure it can happens, I'll check. > > Thoughts? > > > > [1] https://issues.apache.org/jira/browse/IGNITE-6649 > > -- > Best regards, > Andrey V. Mashenkov >
