Failover and state of Callable in dist.exec
by Vladimir Blagojevic
Hey guys,
As Anna and I were working on failover tests we discovered one
peculiarity - state of Callable is not preserved as we send it to
various nodes for execution. I am not 100% this is important but it
might be for some clients. As things stand right now we always failover
to different nodes from master node. Every time Callables fails the call
unwinds immediately back to originating node and originating node sends
callable to another node. Fairly straight forward and expected. However,
for repeated executions, we send fresh "originating" copy of Callable,
in virgin state as it was submitted to dist.exec to begin with. In order
to preserve state we would have to serialize back state from failed node
and use that Callable state instead of virgin copy.
What do you think? Is this state preservation a deal breaker? Or should
we postpone it for next release?
Regards,
Vladimir
12 years, 10 months
Magic at JdbcStringBasedCacheStoreTest2
by Thomas Fromm
Hey,
I recognized today when executing test cases above at cmd line:
infinispan/cachestore/jdbc ~> mvn -Dsurefire.useFile=false
-Dtest=org/infinispan/loaders/jdbc/stringbased/JdbcStringBasedCacheStorest2
test
ends up in:
Caused by: java.lang.InstantiationException:
org.infinispan.loaders.keymappers.TwoWayKey2StringMapper
Problematic row is
config.setKey2StringMapperClass(TwoWayKey2StringMapper.class.getName());
I looked around to find some magic mocking, which explains why there can
be only an interface used, but I failed.
Using e.g. TwoWayPersonKey2StringMapper at this point works.
So why this test class does not fail in CI?
--tf
12 years, 10 months
public API/what should be preserve between minor releases?
by Mircea Markus
Hi,
Cache, CacheManager and all the API that's in the org.infinispan package needs to be backward compatible.
What about more obscure stuff, e.g.
RpcManager.invokeRemotelyInFuture(Collection<Address> recipients, ReplicableCommand rpc, boolean usePriorityQueue, NotifyingNotifiableFuture<Object> future);
This is still accessible through cache.getAdvancedCache().getRpcManager(), so it still counts as public API. I doubt that any user is using that method directly, but OTOH it's public so who knows.
What do people think? Shall we be strict with regard to such 'obscure' methods between minor releases?
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
12 years, 10 months
Testsuite error jiras
by Galder Zamarreño
When you open JIRAs to fix randomly failing tets, i.e. https://issues.jboss.org/browse/ISPN-2102, please make sure the test is disabled too.
This avoids confusion with the tests that have been identified and the ones that have not been.
Cheers,
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
12 years, 10 months
NPE in Lifecycle::cacheStopping
by Ales Justin
I'm regularly seeing this NPE while undeploying my app / tests:
21:48:41,367 WARN [org.jboss.msc.service.fail] (MSC service thread 1-10) MSC00004: Failure during stop of service jboss.capedwarf.cache-lifecycle.prospective_search.capedwarf-test: java.lang.NullPointerException
at java.util.TreeMap.rotateRight(TreeMap.java:2062) [classes.jar:1.6.0_37]
at java.util.TreeMap.fixAfterInsertion(TreeMap.java:2101) [classes.jar:1.6.0_37]
at java.util.TreeMap.put(TreeMap.java:559) [classes.jar:1.6.0_37]
at org.infinispan.query.impl.LifecycleManager.cacheStopping(LifecycleManager.java:173)
at org.infinispan.factories.ComponentRegistry.stop(ComponentRegistry.java:221)
at org.infinispan.CacheImpl.stop(CacheImpl.java:540)
at org.infinispan.CacheImpl.stop(CacheImpl.java:535)
at org.infinispan.AbstractDelegatingCache.stop(AbstractDelegatingCache.java:348)
at org.jboss.as.capedwarf.services.CacheLifecycleService.stop(CacheLifecycleService.java:94)
at org.jboss.msc.service.ServiceControllerImpl$StopTask.stopService(ServiceControllerImpl.java:1911) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at org.jboss.msc.service.ServiceControllerImpl$StopTask.run(ServiceControllerImpl.java:1874) [jboss-msc-1.0.2.GA.jar:1.0.2.GA]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [classes.jar:1.6.0_37]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [classes.jar:1.6.0_37]
at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_37]
It doesn't break the app, hence just reporting NPE. :-)
12 years, 10 months
Self-tuning data placement in Infinispan
by Paolo Romano
Hi all,
in attach I'm sending the last of our efforts, a paper in which we
describe the design and implementation of AutoPlacer, a system for
self-tuning the placement of data in Infinispan (distribution mode). I
thought of sharing this paper with you, as I had already mentioned our
results in this area during the previous Cloud-TM project's meetings.
In a nutshell, Autoplacer combines two main innovative contributions:
- a lightweight round-based distributed optimizer. In each round, each
node uses a space-efficient top-k algorithm to analyze the stream of
data accesses and determine, in an approximate way, their own "hot
spots" (i.e., the data items that are generating most remote accesses)
and their corresponding access frequencies. The access statistics on the
top-k most accessed data items in the system are then scattered among
the nodes in the system, which solve a linear programming optimization
problem to determine the optimal placement for these data.
- a novel data structure, that we named Probabilistic Associative Array
(PAA). PAAs expose an API similar to classic Associative Arrays, but can
provide erroneous results, when queried, with a user tunable probabilty.
Internally, PAA use probabilistic techniques (namely, bloom filters +
decision-tree classifiers) to minimize the amount of memory required for
their encoding. Autoplacer uses PAAs to minimize the overhead associated
with maintating, and updating, the information concerning the placement
of data items across the nodes constituting an Infinispan cluster.
The paper has been submitted to an international conference and is
currently under review.
Comments are more than welcome of course!
Cheers,
Paolo
12 years, 10 months
ISPN-2463: Removing some deprecated methods within MultipleCacheManagersTest?
by Navin Surtani
Hey all,
Possibly the first of a few emails with questions on this JIRA and understanding the state of things since I haven't been looking at code on this project in a long, long time.
This JIRA (ISPN-2463) is essentially about cleaning up the use of the configuration API - i.e. not using org.infinispan.config.Configuration and using org.infinispan.configuration.cache.Configuration - and removing a lot of calls to the deprecated Configuration class within the test-suite. Should the methods that make calls to the now deprecated Configuration class be removed in the abstract test classes such as MultipleCacheManagersTest? For example, should this method [1] be removed and any other methods that call it be modified appropriately?
I just wonder if it's something that should be cleaned up properly before any 5.2 CR's happen.
Discuss away, Infinispan gurus.
------------------------
Navin Surtani
Software Engineer
JBoss SET
JBoss EAP
Twitter: @navssurtani
[1] - https://github.com/infinispan/infinispan/blob/master/core/src/test/java/o...
12 years, 10 months
