12:15 p.m.
Hello,
I just noticed that the Flag.SKIP_CACHE_STORE will prevent my values
to be put in the store, but when using it with get() then the store is
still invoked; from the option name I was expecting it to skip lookup
too?
So I'm not sure how this was intended to work, should I clarify this
limitation in the javadocs or can I propose a fix to the
implementation, in case this wasn't intended?
I'd personally love to fix the implementation, as I've several use
cases in which this invocation is a useless yet expensive operation
for some types as the same flag is always used when putting in this
specific key types (and I can't use an additional differently
configured cache for it).
Cheers,
Sanne
2:19 p.m.
following up to my previous findings about SKIP_CACHE_STORE, I just
discovered that also using put()
I experience Store hits;
In InfinispanDirectory.java:230 I'm using: [*]
cache.withFlags(Flag.SKIP_REMOTE_LOOKUP, Flag.SKIP_CACHE_STORE).put(
key, value )
as you can see from the following stacktrace, it's loading it from the store;
especially annoying as it shouldn't find anything there, as on this
type of key the SKIP_CACHE_STORE is consistently enabled:
at
org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore.getLockFromKey(JdbcStringBasedCacheStore.java:158)
at org.infinispan.loaders.LockSupportCacheStore.load(LockSupportCacheStore.java:93)
at
org.infinispan.interceptors.CacheLoaderInterceptor.loadIfNeeded(CacheLoaderInterceptor.java:133)
at
org.infinispan.interceptors.CacheLoaderInterceptor.visitPutKeyValueCommand(CacheLoaderInterceptor.java:77)
at
org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at
org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
at
org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:57)
at
org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at
org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:183)
at
org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:132)
at
org.infinispan.interceptors.DistTxInterceptor.visitPutKeyValueCommand(DistTxInterceptor.java:76)
at
org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at
org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:58)
at
org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:39)
at
org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:57)
at
org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at
org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:76)
at
org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:57)
at
org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:271)
at org.infinispan.CacheDelegate.put(CacheDelegate.java:426)
at org.infinispan.CacheSupport.put(CacheSupport.java:28)
at
org.infinispan.lucene.InfinispanDirectory.createRefCountForNewFile(InfinispanDirectory.java:230)
at org.infinispan.lucene.InfinispanDirectory.createOutput(InfinispanDirectory.java:218)
at org.apache.lucene.index.SegmentInfos.write(SegmentInfos.java:330)
This stacktrace was produced as I implemented a Key2StringMapper
intentionally not supporting a
specific kind of key, which should never be stored.
Shall we create a
SKIP_STORE_LOOKUP ?
Or better yet, I think that SKIP_STORE should work both for reading and writing:
Index: CacheLoaderInterceptor.java
===================================================================
--- CacheLoaderInterceptor.java (revision 2171)
+++ CacheLoaderInterceptor.java (working copy)
@@ -74,7 +75,7 @@
@Override
public Object visitPutKeyValueCommand(InvocationContext ctx,
PutKeyValueCommand command) throws Throwable {
Object key;
- if ((key = command.getKey()) != null) loadIfNeeded(ctx, key);
+ if ((key = command.getKey()) != null && !
ctx.hasFlag(Flag.SKIP_CACHE_STORE)) loadIfNeeded(ctx, key);
return invokeNextInterceptor(ctx, command);
}
this appears to pass all UT, but I don't know if this was actually
important for some form of locking.
Sanne
[*] it's not committed yet, I was experimenting with it to see
performance improvements or possible effects on ISPN-575
6:22 a.m.
SKIP_STORE should bypass both get and put from the cache store. This is a bug. Your
patch is valid, but you would also want to apply the same technique to
visitRemoveCommand(), visitReplaceCommand(), visitGetCommand(), etc.
Have you created a JIRA for this?
Cheers
Manik
On 6 Aug 2010, at 20:19, Sanne Grinovero wrote:
following up to my previous findings about SKIP_CACHE_STORE, I just
discovered that also using put()
I experience Store hits;
In InfinispanDirectory.java:230 I'm using: [*]
cache.withFlags(Flag.SKIP_REMOTE_LOOKUP, Flag.SKIP_CACHE_STORE).put(
key, value )
as you can see from the following stacktrace, it's loading it from the store;
especially annoying as it shouldn't find anything there, as on this
type of key the SKIP_CACHE_STORE is consistently enabled:
at
org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore.getLockFromKey(JdbcStringBasedCacheStore.java:158)
at org.infinispan.loaders.LockSupportCacheStore.load(LockSupportCacheStore.java:93)
at
org.infinispan.interceptors.CacheLoaderInterceptor.loadIfNeeded(CacheLoaderInterceptor.java:133)
at
org.infinispan.interceptors.CacheLoaderInterceptor.visitPutKeyValueCommand(CacheLoaderInterceptor.java:77)
at
org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at
org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
at
org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:57)
at
org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at
org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:183)
at
org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:132)
at
org.infinispan.interceptors.DistTxInterceptor.visitPutKeyValueCommand(DistTxInterceptor.java:76)
at
org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at
org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:58)
at
org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:39)
at
org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:57)
at
org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76)
at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
at
org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:76)
at
org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:57)
at
org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76)
at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:271)
at org.infinispan.CacheDelegate.put(CacheDelegate.java:426)
at org.infinispan.CacheSupport.put(CacheSupport.java:28)
at
org.infinispan.lucene.InfinispanDirectory.createRefCountForNewFile(InfinispanDirectory.java:230)
at org.infinispan.lucene.InfinispanDirectory.createOutput(InfinispanDirectory.java:218)
at org.apache.lucene.index.SegmentInfos.write(SegmentInfos.java:330)
This stacktrace was produced as I implemented a Key2StringMapper
intentionally not supporting a
specific kind of key, which should never be stored.
Shall we create a
SKIP_STORE_LOOKUP ?
Or better yet, I think that SKIP_STORE should work both for reading and writing:
Index: CacheLoaderInterceptor.java
===================================================================
--- CacheLoaderInterceptor.java (revision 2171)
+++ CacheLoaderInterceptor.java (working copy)
@@ -74,7 +75,7 @@
@Override
public Object visitPutKeyValueCommand(InvocationContext ctx,
PutKeyValueCommand command) throws Throwable {
Object key;
- if ((key = command.getKey()) != null) loadIfNeeded(ctx, key);
+ if ((key = command.getKey()) != null && !
ctx.hasFlag(Flag.SKIP_CACHE_STORE)) loadIfNeeded(ctx, key);
return invokeNextInterceptor(ctx, command);
}
this appears to pass all UT, but I don't know if this was actually
important for some form of locking.
Sanne
[*] it's not committed yet, I was experimenting with it to see
performance improvements or possible effects on ISPN-575
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
6:57 a.m.
2010/8/9 Manik Surtani <manik(a)jboss.org>:
SKIP_STORE should bypass both get and put from the cache store. This
is a bug. Your patch is valid, but you would also want to apply the same technique to
visitRemoveCommand(), visitReplaceCommand(), visitGetCommand(), etc.
Have you created a JIRA for this?
Thanks, now that I know that it's a bug I've opened ISPN-581.
I could try implementing this one myself, but will need directions on
how to apply this during batches or transactions: I couldn't retrieve
the context in the modifications, while each single modification might
have been invoked with different Flags. Adding the flag to the
modification container?
Cheers,
Sanne
Cheers
Manik
On 6 Aug 2010, at 20:19, Sanne Grinovero wrote:
> following up to my previous findings about SKIP_CACHE_STORE, I just
> discovered that also using put()
> I experience Store hits;
> In InfinispanDirectory.java:230 I'm using: [*]
>
> cache.withFlags(Flag.SKIP_REMOTE_LOOKUP, Flag.SKIP_CACHE_STORE).put(
> key, value )
>
> as you can see from the following stacktrace, it's loading it from the store;
> especially annoying as it shouldn't find anything there, as on this
> type of key the SKIP_CACHE_STORE is consistently enabled:
>
> at
org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore.getLockFromKey(JdbcStringBasedCacheStore.java:158)
> at
org.infinispan.loaders.LockSupportCacheStore.load(LockSupportCacheStore.java:93)
> at
org.infinispan.interceptors.CacheLoaderInterceptor.loadIfNeeded(CacheLoaderInterceptor.java:133)
> at
org.infinispan.interceptors.CacheLoaderInterceptor.visitPutKeyValueCommand(CacheLoaderInterceptor.java:77)
> at
org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76)
> at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at
org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:132)
> at
org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:57)
> at
org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76)
> at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at
org.infinispan.interceptors.TxInterceptor.enlistWriteAndInvokeNext(TxInterceptor.java:183)
> at
org.infinispan.interceptors.TxInterceptor.visitPutKeyValueCommand(TxInterceptor.java:132)
> at
org.infinispan.interceptors.DistTxInterceptor.visitPutKeyValueCommand(DistTxInterceptor.java:76)
> at
org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76)
> at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at
org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:58)
> at
org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:39)
> at
org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:57)
> at
org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76)
> at
org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:118)
> at
org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:76)
> at
org.infinispan.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:57)
> at
org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:76)
> at
org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:271)
> at org.infinispan.CacheDelegate.put(CacheDelegate.java:426)
> at org.infinispan.CacheSupport.put(CacheSupport.java:28)
> at
org.infinispan.lucene.InfinispanDirectory.createRefCountForNewFile(InfinispanDirectory.java:230)
> at
org.infinispan.lucene.InfinispanDirectory.createOutput(InfinispanDirectory.java:218)
> at org.apache.lucene.index.SegmentInfos.write(SegmentInfos.java:330)
>
> This stacktrace was produced as I implemented a Key2StringMapper
> intentionally not supporting a
> specific kind of key, which should never be stored.
>
> Shall we create a
> SKIP_STORE_LOOKUP ?
>
> Or better yet, I think that SKIP_STORE should work both for reading and writing:
> Index: CacheLoaderInterceptor.java
> ===================================================================
> --- CacheLoaderInterceptor.java (revision 2171)
> +++ CacheLoaderInterceptor.java (working copy)
> @@ -74,7 +75,7 @@
> @Override
> public Object visitPutKeyValueCommand(InvocationContext ctx,
> PutKeyValueCommand command) throws Throwable {
> Object key;
> - if ((key = command.getKey()) != null) loadIfNeeded(ctx, key);
> + if ((key = command.getKey()) != null && !
> ctx.hasFlag(Flag.SKIP_CACHE_STORE)) loadIfNeeded(ctx, key);
> return invokeNextInterceptor(ctx, command);
> }
>
> this appears to pass all UT, but I don't know if this was actually
> important for some form of locking.
>
> Sanne
>
> [*] it's not committed yet, I was experimenting with it to see
> performance improvements or possible effects on ISPN-575
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
7:01 a.m.
On 9 Aug 2010, at 12:57, Sanne Grinovero wrote:
2010/8/9 Manik Surtani <manik(a)jboss.org>:
> SKIP_STORE should bypass both get and put from the cache store. This is a bug. Your
patch is valid, but you would also want to apply the same technique to
visitRemoveCommand(), visitReplaceCommand(), visitGetCommand(), etc.
>
> Have you created a JIRA for this?
Thanks, now that I know that it's a bug I've opened ISPN-581.
I could try implementing this one myself, but will need directions on
how to apply this during batches or transactions: I couldn't retrieve
the context in the modifications, while each single modification might
have been invoked with different Flags. Adding the flag to the
modification container?
The flag gets added to the context as the call exists, regardless if the call is in a
batch or transaction. You should just have to interact with the InvocationContext
interface.
Cheers
Manik
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
1:59 a.m.
If you plan to enable what Sanne is talking about, have a look at JPA 2 settings for cache
interaction. I think we have them nailed down properly with decent names and proper
separation between gets and puts.
On 6 août 2010, at 19:15, Sanne Grinovero <sanne.grinovero(a)gmail.com> wrote:
Hello,
I just noticed that the Flag.SKIP_CACHE_STORE will prevent my values
to be put in the store, but when using it with get() then the store is
still invoked; from the option name I was expecting it to skip lookup
too?
So I'm not sure how this was intended to work, should I clarify this
limitation in the javadocs or can I propose a fix to the
implementation, in case this wasn't intended?
I'd personally love to fix the implementation, as I've several use
cases in which this invocation is a useless yet expensive operation
for some types as the same flag is always used when putting in this
specific key types (and I can't use an additional differently
configured cache for it).
Cheers,
Sanne
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
5206
days inactive
5209
days old
infinispan-dev@lists.jboss.org
5 comments
3 participants
participants (3)
-
Emmanuel Bernard -
Manik Surtani -
Sanne Grinovero