Design change in Infinispan Query
by Sanne Grinovero
Hello all,
currently Infinispan Query is an interceptor registering on the
specific Cache instance which has indexing enabled; one such
interceptor is doing all what it needs to do in the sole scope of the
cache it was registered in.
If you enable indexing - for example - on 3 different caches, there
will be 3 different Hibernate Search engines started in background,
and they are all unaware of each other.
After some design discussions with Ales for CapeDwarf, but also
calling attention on something that bothered me since some time, I'd
evaluate the option to have a single Hibernate Search Engine
registered in the CacheManager, and have it shared across indexed
caches.
Current design limitations:
A- If they are all configured to use the same base directory to
store indexes, and happen to have same-named indexes, they'll share
the index without being aware of each other. This is going to break
unless the user configures some tricky parameters, and even so
performance won't be great: instances will lock each other out, or at
best write in alternate turns.
B- The search engine isn't particularly "heavy", still it would be
nice to share some components and internal services.
C- Configuration details which need some care - like injecting a
JGroups channel for clustering - needs to be done right isolating each
instance (so large parts of configuration would be quite similar but
not totally equal)
D- Incoming messages into a JGroups Receiver need to be routed not
only among indexes, but also among Engine instances. This prevents
Query to reuse code from Hibernate Search.
Problems with a unified Hibernate Search Engine:
1#- Isolation of types / indexes. If the same indexed class is
stored in different (indexed) caches, they'll share the same index. Is
it a problem? I'm tempted to consider this a good thing, but wonder if
it would surprise some users. Would you expect that?
2#- configuration format overhaul: indexing options won't be set on
the cache section but in the global section. I'm looking forward to
use the schema extensions anyway to provide a better configuration
experience than the current <properties />.
3#- Assuming 1# is fine, when a search hit is found I'd need to be
able to figure out from which cache the value should be loaded.
3#A we could have the cache name encoded in the index, as part
of the identifier: {PK,cacheName}
3#B we actually shard the index, keeping a physically separate
index per cache. This would mean searching on the joint index view but
extracting hits from specific indexes to keep track of "which index"..
I think we can do that but it's definitely tricky.
It's likely easier to keep indexed values from different caches in
different indexes. that would mean to reject #1 and mess with the user
defined index name, to add for example the cache name to the user
defined string.
Any comment?
Cheers,
Sanne
11 years, 7 months
singleton @Listeners
by Mircea Markus
This is a problem that pops up constantly:
User: "I add a listener to my distributed/replicated cache but this gets invoked numOwners times - can I make that to be invoked only once cluster wise?"
Developer: "Yes, you can! You have to do that and that..."
What about a "singleton" attribute on the Listener? Would make the reply shorter:
Developer: "Use @Listener(singleton=true)"
Cheers,
Mircea
12 years, 1 month
NPE in MapReduceTask running in cluster
by Matej Lazar
NPE ocures while running CapeDwarf cluster tests, see stack below.
Null comes from MapReduceTask.invokeEverywhere
13:36:51,053 INFO [org.jboss.as.clustering.infinispan] (http-/192.168.30.248:8080-1) JBAS010281: Started search_capedwarf-test cache from capedwarf container
13:36:51,058 DEBUG [org.infinispan.distexec.mapreduce.MapReduceTask] (http-/192.168.30.248:8080-1) Invoking MapCombineCommand [keys=[], taskId=14c75f18-3861-4a06-8a4a-b1592d542d14] across entire cluster
*13:36:51,065 DEBUG [org.infinispan.distexec.mapreduce.MapReduceTask] (http-/192.168.30.248:8080-1) Invoked MapCombineCommand [keys=[], taskId=14c75f18-3861-4a06-8a4a-b1592d542d14] across entire cluster, results are {node-b/capedwarf=null}*
13:36:51,067 DEBUG [org.infinispan.distexec.mapreduce.MapReduceTask] (http-/192.168.30.248:8080-1) Invoking MapCombineCommand [keys=[], taskId=14c75f18-3861-4a06-8a4a-b1592d542d14] locally
13:36:51,069 DEBUG [org.infinispan.distexec.mapreduce.MapReduceTask] (http-/192.168.30.248:8080-1) Invoked MapCombineCommand [keys=[], taskId=14c75f18-3861-4a06-8a4a-b1592d542d14] locally
Any idea ?
Thanks,
Matej.
java.lang.NullPointerException
at org.infinispan.distexec.mapreduce.MapReduceTask.mergeResponse(MapReduceTask.java:530)
at org.infinispan.distexec.mapreduce.MapReduceTask.executeMapPhaseWithLocalReduction(MapReduceTask.java:439)
at org.infinispan.distexec.mapreduce.MapReduceTask.execute(MapReduceTask.java:328)
at org.infinispan.distexec.mapreduce.MapReduceTask.execute(MapReduceTask.java:692)
at org.jboss.capedwarf.search.CapedwarfSearchService.listIndexes(CapedwarfSearchService.java:94)
at org.jboss.test.capedwarf.cluster.SearchTestCase.clear(SearchTestCase.java:360)
at org.jboss.test.capedwarf.cluster.SearchTestCase.cleanpOnStart(SearchTestCase.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at org.jboss.arquillian.junit.Arquillian$6$1.invoke(Arquillian.java:270)
at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
at org.jboss.arquillian.container.test.impl.execution.ContainerTestExecuter.execute(ContainerTestExecuter.java:38)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:89)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:75)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:90)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:135)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:111)
at org.jboss.arquillian.junit.Arquillian$6.evaluate(Arquillian.java:263)
at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:226)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:240)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:185)
at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:314)
at org.jboss.arquillian.junit.Arquillian.access$100(Arquillian.java:46)
at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:199)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:147)
at org.junit.runner.JUnitCore.run(JUnitCore.java:157)
at org.junit.runner.JUnitCore.run(JUnitCore.java:136)
at org.jboss.arquillian.junit.container.JUnitTestRunner.execute(JUnitTestRunner.java:65)
at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.executeTest(ServletTestRunner.java:160)
at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.execute(ServletTestRunner.java:126)
at org.jboss.arquillian.protocol.servlet.runner.ServletTestRunner.doGet(ServletTestRunner.java:90)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:734)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:847)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:329)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
at org.jboss.weld.servlet.ConversationPropagationFilter.doFilter(ConversationPropagationFilter.java:62)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
at org.jboss.capedwarf.appidentity.GAEFilter.doFilter(GAEFilter.java:57)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:280)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:248)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:161)
at org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.event(JBossWebContext.java:67)
at org.jboss.modcluster.container.jbossweb.JBossWebContext$RequestListenerValve.invoke(JBossWebContext.java:48)
at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:165)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:372)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:679)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:931)
at java.lang.Thread.run(Thread.java:722)
12 years, 3 months
Re: [infinispan-dev] Removing Infinispan dependency on the Hibernate-Infinispan module in 4.x
by Galder Zamarreño
Scott, what do you suggest doing instead then? Without the commands, evictAll invalidation won't work.
Are you suggesting that I revert back to using the cache as a notification bus so that regions are invalidated?
On Feb 8, 2012, at 4:13 PM, Scott Marlow wrote:
> http://lists.jboss.org/pipermail/infinispan-dev/2012-February/010125.html has more context.
>
> Since there are no easy/quick fixes that can be applied at this time, to remove the AS7 Infinispan dependency on the Hibernate-Infinispan module, I think we should avoid depending on the service loader way to supply the custom commands (in the Hibernate-Infinispan module), at least until this can be addressed elsewhere.
>
> I propose that the Hibernate-Infinispan second level cache should not use the Service Loader to pass custom commands into Infinispan. If we agree, I'll create a jira for this.
>
> Scott
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
12 years, 4 months
Separate ExecutorService for map/reduce tasks?
by Vladimir Blagojevic
Hi,
Although https://issues.jboss.org/browse/ISPN-2284 is charted for 6.0 I
would like to see if there is a possibility to finish it for 5.2. Most
of the parallel execution I have done already this and last week [1].
However, this change is not limited to map/reduce package only as we
might possibly want to have a separate executor for map/reduce execution
on each node. These changes affect global configuration and are not
confined to map/reduce packages only. Or should we simply use transport
executor for execution of these tasks for now and should the need arise
introduce separate executor in the future releases?
Regards,
Vladimir
[1] https://github.com/vblagoje/infinispan/tree/t_2284
12 years, 8 months
Test status
by Sanne Grinovero
Hi all,
after a break from Infinispan (and work) I updated to master today and
fired up a test run; it fails, so my usual question: is it just me or
are these already "well known" tests:
Results :
Failed tests:
testReplicateJBossExternalizePojoToNewJoiningNode(org.infinispan.marshall.MarshallExternalPojosTest):
Replication timeout for MarshallExternalPojosTest-NodeC-7830
testNodeDown(org.infinispan.distribution.topologyaware.TopologyAwareStateTransferTest):
Timed out waiting for rebalancing to complete on node
TopologyAwareStateTransferTest-NodeA-8435, current topology is
CacheTopology{id=9, currentCH=DefaultConsistentHash{numSegments=60,
numOwners=2, members=[TopologyAwareStateTransferTest-NodeA-8435,
TopologyAwareStateTransferTest-NodeB-63066,
TopologyAwareStateTransferTest-NodeC-2272,
TopologyAwareStateTransferTest-NodeD-57364], owners={0: 0 1, 1: 0 1,
2: 0 1, 3: 0 1, 4: 0 1, 5: 0 1, 6: 0 1, 7: 0 1, 8: 0 1, 9: 0 1, 10: 0
1, 11: 0 1, 12: 0, 13: 0, 14: 0, 15: 3 0, 16: 3 0, 17: 3 0, 18: 3 0,
19: 3 0, 20: 2 0, 21: 2 0, 22: 2 0, 23: 2 0, 24: 2 0, 25: 2 0, 26: 2
0, 27: 2 0, 28: 2 0, 29: 2 0, 30: 1 0, 31: 1 0, 32: 1 0, 33: 1 0, 34:
1 0, 35: 1 0, 36: 1 0, 37: 1 0, 38: 1 0, 39: 1 0, 40: 1 0, 41: 1 0,
42: 1, 43: 1, 44: 1, 45: 3 1, 46: 3 1, 47: 3 1, 48: 3 1, 49: 3 1, 50:
2 1, 51: 2 1, 52: 2, 53: 2, 54: 2, 55: 3 2, 56: 3 2, 57: 3, 58: 3, 59:
3}, pendingCH=DefaultConsistentHash{numSegments=60, numOwners=2,
members=[TopologyAwareStateTransferTest-NodeA-8435,
TopologyAwareStateTransferTest-NodeB-63066,
TopologyAwareStateTransferTest-NodeC-2272,
TopologyAwareStateTransferTest-NodeD-57364], owners={0: 0 1, 1: 0 1,
2: 0 1, 3: 0 1, 4: 0 1, 5: 0 1, 6: 0 1, 7: 0 1, 8: 0 1, 9: 0 1, 10: 0
1, 11: 0 1, 12: 0 2, 13: 0 2, 14: 0 2, 15: 3 0, 16: 3 0, 17: 3 0, 18:
3 0, 19: 3 0, 20: 2 0, 21: 2 0, 22: 2 0, 23: 2 0, 24: 2 0, 25: 2 0,
26: 2 0, 27: 2 0, 28: 2 0, 29: 2 0, 30: 1 0, 31: 1 0, 32: 1 0, 33: 1
0, 34: 1 0, 35: 1 0, 36: 1 0, 37: 1 0, 38: 1 0, 39: 1 0, 40: 1 0, 41:
1 0, 42: 1 2, 43: 1 2, 44: 1 2, 45: 3 1, 46: 3 1, 47: 3 1, 48: 3 1,
49: 3 1, 50: 2 1, 51: 2 1, 52: 2 3, 53: 2 3, 54: 2 3, 55: 3 2, 56: 3
2, 57: 3 2, 58: 3 2, 59: 3 2}}
testRestrictionOnAddingToAsyncQueue(org.infinispan.loaders.decorators.AsyncStoreTest):
Method org.testng.internal.TestNGMethod.testRestrictionOnAddingToAsyncQueue()
didn't finish within the time-out 10000
testSTWithWritingNonTxThread(org.infinispan.statetransfer.StateTransferFunctionalTest):
Method org.testng.internal.TestNGMethod.testSTWithWritingNonTxThread()
didn't finish within the time-out 120000
testSTWithWritingTxThread(org.infinispan.statetransfer.StateTransferCacheLoaderFunctionalTest):
Method org.testng.internal.TestNGMethod.testSTWithWritingTxThread()
didn't finish within the time-out 120000
testSTWithWritingTxThread(org.infinispan.statetransfer.StateTransferFunctionalTest):
Method org.testng.internal.TestNGMethod.testSTWithWritingTxThread()
didn't finish within the time-out 120000
Tests run: 1868, Failures: 6, Errors: 0, Skipped: 2
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO]
[INFO] Infinispan Common Parent .......................... SUCCESS [3.356s]
[INFO] Infinispan Core ................................... FAILURE [6:24.978s]
[INFO] Parent pom for server modules ..................... SKIPPED
[INFO] Infinispan Server - Core Components ............... SKIPPED
[INFO] Infinispan Tools .................................. SKIPPED
[INFO] Parent pom for cachestore modules ................. SKIPPED
[INFO] Infinispan JDBC CacheStore ........................ SKIPPED
[INFO] Infinispan Lucene Directory Implementation ........ SKIPPED
[INFO] Infinispan Query API .............................. SKIPPED
[INFO] Infinispan JDBM CacheStore ........................ SKIPPED
[INFO] Infinispan Tree API ............................... SKIPPED
[INFO] Infinispan BDBJE CacheStore ....................... SKIPPED
[INFO] Infinispan CloudCacheStore ........................ SKIPPED
[INFO] Infinispan Hot Rod Server ......................... SKIPPED
[INFO] Infinispan Hot Rod Client ......................... SKIPPED
[INFO] Infinispan remote CacheStore ...................... SKIPPED
[INFO] Infinispan CassandraCacheStore .................... SKIPPED
[INFO] Infinispan HBaseCacheStore ........................ SKIPPED
[INFO] Infinispan Memcached Server ....................... SKIPPED
[INFO] Infinispan WebSocket Server ....................... SKIPPED
[INFO] Infinispan REST Server ............................ SKIPPED
[INFO] Infinispan RHQ Plugin ............................. SKIPPED
[INFO] Infinispan Rolling Upgrade Tooling ................ SKIPPED
[INFO] Infinispan Spring Integration ..................... SKIPPED
[INFO] Infinispan QL Interpreter ......................... SKIPPED
[INFO] Infinispan CLI Client ............................. SKIPPED
[INFO] Infinispan GUI Demo ............................... SKIPPED
[INFO] Infinispan EC2 Demo ............................... SKIPPED
[INFO] Infinispan Distributed Executors and Map/Reduce Demo SKIPPED
[INFO] Infinispan EC2 Demo UI ............................ SKIPPED
[INFO] Infinispan Directory Demo ......................... SKIPPED
[INFO] Infinispan Lucene Directory Demo .................. SKIPPED
[INFO] Infinispan GridFileSystem WebDAV interface ........ SKIPPED
[INFO] Infinispan Near Cache Demo ........................ SKIPPED
[INFO] Infinispan CDI support ............................ SKIPPED
[INFO] Infinispan Near Cache Demo Client ................. SKIPPED
[INFO] Infinispan CDI support JCache TCK runner .......... SKIPPED
[INFO] Integration tests: Lucene Directory with Infinispan Query SKIPPED
[INFO] Infinispan Distribution ........................... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6:28.840s
[INFO] Finished at: Fri Nov 30 15:00:29 GMT 2012
[INFO] Final Memory: 292M/762M
Cheers,
Sanne
12 years, 10 months
no eviction on indexing
by Ales Justin
I was changing cache config a bit, and got this:
* https://gist.github.com/4130728
private static void verifyCacheHasNoEviction(AdvancedCache<?, ?> cache) {
if (cache.getConfiguration().getEvictionStrategy().isEnabled())
throw new IllegalArgumentException("DistributedSegmentReadLocker is not reliable when using a cache with eviction enabled, disable eviction on this cache instance");
}
How do you then handle memory overflow on no-eviction caches?
-Ales
12 years, 10 months
Refactoring async operations
by Mircea Markus
Hi,
Part of fixing ISPN-2435, I need to significantly change DistributionInterceptor which at the moment is a very complex pice of code. Building the fix on top of it is extremely difficult and error prone, so I need to refactor it a bit before moving forward.
One such refactoring is about changing the way the async operations are handled (e.g. putAsync()). At the moment all the interceptor calls happen in user's thread, but two remote calls which are invoked with futures and aggregated:
the L1 invalidation and the actual distribution call. The code for handling this future aggregation is rather complicated and spreads over multiple classes (RpcManager, L1Manager, ReplicationInterceptor, DistributionInterceptor), so the simple alternative solution I have in mind is to build an asycPut on top of a syncPut and wrap it in a future:
CacheImpl:putAsync(k,v) {
final InvocationContext ic = createInvocatinonContextInCallerThread(); //this is for class loading purpose
return asyncPoolExecutor.submit(new Callable() {
public Object call() {
return put(k,v, ic); //this is the actual sync put
}
}
}
This would significantly simplify several components ( no references to network/aggregated futures in RpcManager, L1Manager, ReplicationInterceptor, DistributionInterceptor).
Possible issues:
- caller's class loader - the class loader is aggregated in the InvocationContext, so as long as we build the class loader in caller's thread we should be fine
- IsMarshallableInterceptor is used with async marshalling, in order to notify the user when objects added to the cache are not serializable. With the approach I suggested, for async calls only (e.g. putAsync) this notification would not happen in caller's thread, but async on future.get(). I really don't expect users to rely on this functionality, but something that would change never the less.
- anything else you can think of?
I know this is a significant change at this stage in the project, so I really tried to go without it - but that resulted in spaghetti code taking a lot of time to patch. So instead of spending that time to code a complex hack I'd rather go for the simple and nice solution and add more unit tests to prove it works.
Cheers,
--
Mircea Markus
Infinispan lead (www.infinispan.org)
12 years, 10 months
ISPN-2463: Hopefully one final question
by Navin Surtani
Hey all,
Nearly finished up with cleaning up the compile errors - should be able to run the test-suite by this afternoon in order to make sure that there aren't any failures. I was wondering, though, whether the tests in the package org.infinispan.config.* should still be making use of the deprecated configuration API? I understand that the point of this migration is to eliminate the use of org.infinispan.config.Configuration within the test-suite, but should just these specific tests still be testing the old method?
My personal opinion is that we should still have tests making use of the old API as long as it does exist in the code-base. Speaking with Tristan on IRC last week, he mentioned that the org.infinispan.config.* package is likely to be totally removed in due course. I think that until that does actually happen, we ought to have tests for that code - deprecated or not.
Thoughts?
------------------------
Navin Surtani
Software Engineer
JBoss SET
JBoss EAP
Twitter: @navssurtani
12 years, 10 months
