strictly not returning expired values
by Sanne Grinovero
I've noticed that every time we perform a get() operation (or any
other retrieval) the value is NOT returned to the client if it's
expired, which is going to receive a null instead.
It looks like that these checks are in place to prevent
a) a race condition with the eviction process
b) to not return very old values from a very large "wakeUpInterval"
between eviction activity
c) to load from cacheLoaders
Now for the first case, as a user of a caching library I would prefer
to get the value instead. Expiry is in place only to prevent me from
wasting memory, but this entry wasn't collected yet so why is
Infinispan denying me access to the value I want to retrieve? We're
introducing unneeded cache misses.
Since even with the current code we can not provide guarantees that we
won't ever return an expired entry (between the check and the actual
return to user code we might be briefly suspended), I don't see why we
should not make it clear that the expiry timeout is a best-effort time
and relax our code checks a bit; there are many reasons to do so:
1) avoid fictitious cache misses.
2) Avoid the need to invoke a System.currentTimeMillis() for each
retrieval operation - that's expensive!
3) Some operations like size() or values() now explicitly iterate the
whole result set twice to make sure all expired entries are removed.
This is unnecessary following the reasoning above.
Regarding the other cases:
b) We don't need to care imo. If people need more precision they
should use a lower wakeUpInterval.
c) We should keep this logic in CacheLoader, just because having an
aggressive wakeUpInterval might be very expensive in this case.
I'm asking as I've built a quick POC for ISPN-1459 but since now the
current time needs to be passed to the entry, I end up needing to
invoke the wall clock even for immortal cache entries making many
other use cases slower: not happy with that, I'd rather speed up both
use cases.
Sanne
12 years, 6 months
FineGrainedAtomicMap - remaining items
by Vladimir Blagojevic
After Mircea's thorough review and advice from him and Sanne we are
almost ready to integrate FineGrainedAtomicMap. I say almost because
Sanne, Mircea and I concluded that two questions remain unanswered.
1) Should we stick fine-grained functionality under current AtomicMap
and discard legacy AtomicMap? FineGrainedAtomicMap seems to offer a
super-set of AtomicMap features and we should not confuse users with yet
another AtomicMap; at the same time we have less headache maintaining
AtomicMap codebase.
2) This one is a bit technical. What should we do if tx1 deletes entire
AtomicMap while tx2 updates entries in the same Map. Should we create a
new Map and apply deltas to a new fresh map *or* simply discard delta
changes because entire Map has been deleted?
Anything else Mircea, Sanne?
Regards,
Vladimir
12 years, 6 months
Separating FluentTypes into a separate file?
by Galder Zamarreño
Hi,
Would it cause any problems if FluentTypes class in FluentConfiguration was separated into a separate file? i.e. backward compatibility issues.
Remember that FluentTypes is not a public interface per se, and it's not something clients would reference directly.
The reason I want to change this is cos it causes all sorts of access issues when you try to use fluent configuration from Scala.
If it can be problematic, no probs, I'll wait for 6.0 to separate this class into a separate file and Scala can carry on with old configuration.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
12 years, 6 months
getting ISPN config as XML via JMX
by Martin Gencur
Hi,
one of our efforts around EDG testing is to test whether all XML
elements/attributes being set in standalone.xml take effect, i.e.
whether org.infinispan.config.Configuration, which in turn is used to
create caches, is populated properly based on the xml config file.
(this test goal is mentioned in our testplan - second row -
https://docspace.corp.redhat.com/docs/DOC-79912)
I think one possible way to test this would be to start EDG with certain
config. defined in standalone.xml and look at how it was really
configured via JMX. There's a JIRA I reported last week which shows that
this is not working currently
(https://issues.jboss.org/browse/ISPN-1443). Would there be a chance to
make it work? Or has this ever been working?
If anyone has any thoughts how to test this in a different way, they can
tell me. The problem is that we're testing client-server mode where we
cannot access AdvancedCache and so on, so getting the real configuration
is hard (if possible at all).
Thanks for your thoughts
--
Martin Gencur
--
JBoss QE, Enterprise Data Grid
Desk phone: +420 532 294 192, ext. 62192
12 years, 6 months
5.1.0.BETA2 should be out tonight - BETA3 in a week?
by Galder Zamarreño
Hi all,
5.1.0.BETA2 should be out tonight with Dan's asymmetric stuff and other smaller fixes.
We have however some work in the pipeline such as https://github.com/infinispan/infinispan/pull/574 which Mircea is expecting to fix in a day or two.
Also, last week I was working on https://issues.jboss.org/browse/ISPN-1408 and version 1.1 of the Hot Rod protocol, and I probably need 2 days more to have it complete.
So, I'm considering doing a BETA3 next Monday. How does that sound? Btw, I'm assuming that Vladimir, Pete and Manik are not ready yet with their stuff for BETA2.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
12 years, 6 months
Infinispan 5.1 + AS 7.1
by Paul Ferraro
Hey all,
I'm a bit stuck with the Infinispan 5.1 upgrade in AS 7.1.
I've tried both with BETA1 and a SNAPSHOT build from today.
When a deployment forces a cache to start, I see the following
stacktrace:
14:06:07,584 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC00001: Failed to start service jboss.infinispan.web.repl: org.jboss.msc.service.StartException in service jboss.infinispan.web.repl: Failed to start service
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1780) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [:1.6.0_23]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [:1.6.0_23]
at java.lang.Thread.run(Thread.java:679) [:1.6.0_23]
Caused by: org.infinispan.CacheException: Unable to invoke method private void org.infinispan.statetransfer.BaseStateTransferManagerImpl.start() throws java.lang.Exception on object
at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:205)
at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:825)
at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:624)
at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:527)
at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:177)
at org.infinispan.CacheImpl.start(CacheImpl.java:462)
at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:574)
at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:453)
at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:467)
at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:84)
at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:73)
at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:73)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1824) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1759) [jboss-msc-1.0.1.GA.jar:1.0.1.GA]
... 3 more
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [:1.6.0_23]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [:1.6.0_23]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [:1.6.0_23]
at java.lang.reflect.Method.invoke(Method.java:616) [:1.6.0_23]
at org.infinispan.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:203)
... 16 more
Caused by: java.lang.IllegalArgumentException: Invalid cache list for consistent hash: []
at org.infinispan.distribution.ch.AbstractWheelConsistentHash.setCaches(AbstractWheelConsistentHash.java:96)
at org.infinispan.distribution.ch.ConsistentHashHelper.createConsistentHash(ConsistentHashHelper.java:122)
at org.infinispan.statetransfer.ReplicatedStateTransferManagerImpl.createConsistentHash(ReplicatedStateTransferManagerImpl.java:56)
at org.infinispan.statetransfer.BaseStateTransferManagerImpl.start(BaseStateTransferManagerImpl.java:143)
What's particularly puzzling is that this is a REPL_ASYNC cache with
state transfer enabled. Why are we attempting to create a consistent
hash here? Dan, is this related to your work?
Thanks in advance,
Paul
12 years, 6 months
