[JBoss JIRA] (ISPN-3850) Introduce non-static utility to handle classloading hierarchy
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/ISPN-3850?page=com.atlassian.jira.plugin.... ]
Work on ISPN-3850 started by Brett Meyer.
> Introduce non-static utility to handle classloading hierarchy
> -------------------------------------------------------------
>
> Key: ISPN-3850
> URL: https://issues.jboss.org/browse/ISPN-3850
> Project: Infinispan
> Issue Type: Sub-task
> Components: Core API
> Reporter: Brett Meyer
> Assignee: Brett Meyer
>
> In Commons, the FileLookup and CL concepts within Util need replaced by a non-static/non-singleton classloading service. This will run through the following sequence, in order:
> 1.) OsgiClassLoader (new)
> 2.) explicit classloader (provided per-operation by AdvancedCache#with(ClassLoader))
> 3.) Infinispan CL
> 4.) system CL
> 5.) TCCL
> Since it's not static/singleton, the util instance will need wired into GlobalConfiguration (or elsewhere). The instance will replace the related Util/FileLookup calls.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (ISPN-3850) Introduce non-static utility to handle classloading hierarchy
by Brett Meyer (JIRA)
Brett Meyer created ISPN-3850:
---------------------------------
Summary: Introduce non-static utility to handle classloading hierarchy
Key: ISPN-3850
URL: https://issues.jboss.org/browse/ISPN-3850
Project: Infinispan
Issue Type: Sub-task
Reporter: Brett Meyer
Assignee: Brett Meyer
In Commons, the FileLookup and CL concepts within Util need replaced by a non-static/non-singleton classloading service. This will run through the following sequence, in order:
1.) OsgiClassLoader (new)
2.) explicit classloader (provided per-operation by AdvancedCache#with(ClassLoader))
3.) Infinispan CL
4.) system CL
5.) TCCL
Since it's not static/singleton, the util instance will need wired into GlobalConfiguration (or elsewhere). The instance will replace the related Util/FileLookup calls.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (ISPN-3296) Total Order: timeout exceptions are not throw correctly
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3296?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3296:
-------------------------------
Fix Version/s: 7.0.0.Final
7.0.0.Alpha1
(was: 6.0.1.Final)
> Total Order: timeout exceptions are not throw correctly
> -------------------------------------------------------
>
> Key: ISPN-3296
> URL: https://issues.jboss.org/browse/ISPN-3296
> Project: Infinispan
> Issue Type: Bug
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Priority: Critical
> Fix For: 7.0.0.Final, 7.0.0.Alpha1
>
>
> Issues found in Cloud-TM. Check if they happen here and create a JIRA for each of them
> * IgnoreExtraResponseFilter is not needed anymore.
> * missing argument log message
> * TimeoutException, when happens, it is ignored and the transaction is processed normally
> * TimeoutException can block the total order chain (all system is blocked!)
> * port the testTimeoutCleanup from cloudtm to master
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (ISPN-3849) Re-work ServiceLoader concepts
by Brett Meyer (JIRA)
Brett Meyer created ISPN-3849:
---------------------------------
Summary: Re-work ServiceLoader concepts
Key: ISPN-3849
URL: https://issues.jboss.org/browse/ISPN-3849
Project: Infinispan
Issue Type: Sub-task
Reporter: Brett Meyer
Assignee: Brett Meyer
Any uses of ServiceLoader will need to be replaced by a new utility to first check OSGi services w/ SL as a fallback. This also requires that any internal services also need to be registered with OSGi (as well as external extension point impls, etc.). That's not invasive at all. OSGi blueprint files are very similar to the service loader text files in META-INF/services.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (ISPN-3731) Multicast messages can be replayed to new node
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-3731?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo updated ISPN-3731:
------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 6.1.0.Final
Resolution: Done
> Multicast messages can be replayed to new node
> ----------------------------------------------
>
> Key: ISPN-3731
> URL: https://issues.jboss.org/browse/ISPN-3731
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.0.Final
> Reporter: Radim Vansa
> Assignee: Dan Berindei
> Priority: Critical
> Labels: 620
> Fix For: 6.1.0.Final
>
>
> Messages that target all current members are sent as multicast messages.
> However, these retransmissions can be replayed on new nodes that have just joined the cluster.
> This can result for example in execution of already completed transaction on the new node, causing possible data inconsistency for those entries which are owned by the new node in backup way - the replayed transaction sequence authoritatively overwrites them.
> The node should remember the first topologyId it has seen and do not execute any commands that have lower topologyId.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (ISPN-800) Infinispan inside OSGI
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/ISPN-800?page=com.atlassian.jira.plugin.s... ]
Brett Meyer commented on ISPN-800:
----------------------------------
I'm in the middle of working on multi-faceted fixes to correctly support OSGi in my fork. Creating subtasks to document everything. I'll hopefully have a PR soon.
> Infinispan inside OSGI
> ----------------------
>
> Key: ISPN-800
> URL: https://issues.jboss.org/browse/ISPN-800
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core API
> Reporter: Luca Stancapiano
> Assignee: Galder Zamarreño
>
> We need to import infinispan inside a OSGI repository. Tests are made with Felix.
> I added the configuration to use infinispan inside a osgi repository. We need to ignore all listed dependencies. With this configuration we can install infinispan-core.jar inside OSGI. Its achievement will be as a base installation here: https://github.com/flashboss/infinispan
> I added the Import-Package because you are forced to put manually in Felix all dependencies as jgroups, jboss marshalling, jcip, all apache commons. I've seen infinispan core working by default without all those libraries, so I think the same achievement should be replicated in OSGI.
> Inside the Import-Package tag I excluded those libraries so Infinispan core can be started in default mode without errors. If we want use the replication in OSGI, it is enough add manually the other packages (jgroups.jar etc etc)
> Actually the core bundle can be installed. But to be used it needs theese projects be installed as osgi bundles:
> jboss transaction api 1.0.1.GA
> We patched it. There is a new OSGI version here: https://repository.jboss.org/nexus/content/groups/public/org/jboss/spec/j... )
> jgroups 2.10.1.GA
> (it's a osgi bundle since the 3.x version)
> river 1.2.3.GA
> (opened an issue for marshalling 1.4.0 in JBMAR-118 and https://github.com/flashboss/jboss-marshalling/blob/master/river/pom.xml )
> marshalling-api 1.2.3.GA
> (opened an issue for marshalling 1.4.0 in JBMAR-118 and https://github.com/flashboss/jboss-marshalling/blob/master/api/pom.xml )
> jboss logging spi 2.0.5.GA
> (added a jira issue in JBLOGGING-51 . It could be fixed in the 2.2.0.CR2 version. Fixed in the 3.x version)
> rhq plugin annotations 1.4.0.B01
> (opened a feature request in https://bugzilla.redhat.com/show_bug.cgi?id=657754 )
> i18nlog 1.0.9
> (sent a patch in https://sourceforge.net/projects/i18nlog . It could become a OSGI bundle in the 1.0.10 version. Waiting for a response. Fixed in 1.15)
> log4j 1.2.16
> (that's ok...it is a osgi bundle ;))
> jcip-annotations 1.0
> (I sent a patch via email to brian(a)briangoetz.com and a post in http://tembrel.blogspot.com. Sent the patch in concurrency-interest(a)cs.oswego.edu too. They responded to me. There is a OSGI version with a different artifact name. I changed the dependency in the pom.xml of the parent project)
> We should make sure proper 'Import-Package' property is specified in the MANIFEST.MF so that:
> 1- it fails to load obviously when there's any missing bundles that are essential in using the very core functionality of Infinispan.
> 2 - it does not fail due to the dependency that is not really essential.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (ISPN-3848) JBoss Marshalling Dependency is LGPL (not usable for Apache projects)
by Sebastian Schaffert (JIRA)
Sebastian Schaffert created ISPN-3848:
-----------------------------------------
Summary: JBoss Marshalling Dependency is LGPL (not usable for Apache projects)
Key: ISPN-3848
URL: https://issues.jboss.org/browse/ISPN-3848
Project: Infinispan
Issue Type: Feature Request
Components: Marshalling
Reporter: Sebastian Schaffert
Assignee: Galder Zamarreño
The marshalling component has a dependency to jboss-marshalling, which is currently licensed under LGPL only. This makes it very hard to use Infinispan in projects that require a licensing 100% compatible with the Apache License, in particular those hosted by the Apache Software Foundation. In my concrete case, I'd like to use Infinispan in Apache Marmotta, but the dependency to LGPL libraries is not possible.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (ISPN-3846) CNFE: java.util.RegularEnumSet on IBM JDK 1.6
by Galder Zamarreño (JIRA)
[ https://issues.jboss.org/browse/ISPN-3846?page=com.atlassian.jira.plugin.... ]
Galder Zamarreño commented on ISPN-3846:
----------------------------------------
[~mgencur], can you try [this branch|https://github.com/galderz/infinispan/tree/t_3846] and see if it works on IBM JVM?
> CNFE: java.util.RegularEnumSet on IBM JDK 1.6
> ---------------------------------------------
>
> Key: ISPN-3846
> URL: https://issues.jboss.org/browse/ISPN-3846
> Project: Infinispan
> Issue Type: Bug
> Components: Marshalling
> Environment: IBM Java:
> java version "1.6.0"
> Java(TM) SE Runtime Environment (build pxa6460sr13ifix-20130303_02(SR13+IV37419))
> IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 jvmxa6460sr13-20130114_134867 (JIT enabled, AOT enabled)
> J9VM - 20130114_134867
> JIT - r9_20130108_31100
> GC - 20121212_AA)
> JCL - 20130303_02
> Reporter: Martin Gencur
> Assignee: Galder Zamarreño
> Priority: Critical
> Labels: 620
>
> I'm getting the following exception when running tests from ISPN core on IBM JDK 1.6.
> I checked that the class is not present in the JVM. However, it is present in IBM JDK 1.7
> {code}
> org.infinispan.commons.CacheConfigurationException: Unable to instantiate class java.util.RegularEnumSet
> at org.infinispan.commons.util.Util.loadClass(Util.java:85)
> at org.infinispan.marshall.exts.EnumSetExternalizer.getEnumSetClass(EnumSetExternalizer.java:87)
> at org.infinispan.marshall.exts.EnumSetExternalizer.getRegularEnumSetClass(EnumSetExternalizer.java:83)
> at org.infinispan.marshall.exts.EnumSetExternalizer.<init>(EnumSetExternalizer.java:35)
> at org.infinispan.marshall.core.ExternalizerTable.loadInternalMarshallables(ExternalizerTable.java:220)
> at org.infinispan.marshall.core.ExternalizerTable.start(ExternalizerTable.java:144)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:183)
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:869)
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:638)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:207)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:156)
> at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:277)
> at org.infinispan.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:147)
> at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:227)
> at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:65)
> at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:797)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:201)
> at org.infinispan.factories.ComponentRegistry.registerComponentInternal(ComponentRegistry.java:187)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:156)
> at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:277)
> at org.infinispan.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:150)
> at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:227)
> at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:65)
> at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:797)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:201)
> at org.infinispan.factories.ComponentRegistry.registerComponentInternal(ComponentRegistry.java:187)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:156)
> at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:277)
> at org.infinispan.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:150)
> at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:227)
> at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:65)
> at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:797)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:201)
> at org.infinispan.factories.ComponentRegistry.registerComponentInternal(ComponentRegistry.java:187)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:156)
> at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:277)
> at org.infinispan.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:150)
> at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:227)
> at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:65)
> at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:797)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:201)
> at org.infinispan.factories.ComponentRegistry.registerComponentInternal(ComponentRegistry.java:187)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:156)
> at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:277)
> at org.infinispan.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:150)
> at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:227)
> at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:65)
> at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:797)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:201)
> at org.infinispan.factories.ComponentRegistry.registerComponentInternal(ComponentRegistry.java:187)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:156)
> at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:277)
> at org.infinispan.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:150)
> at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:227)
> at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:65)
> at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:797)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:201)
> at org.infinispan.factories.ComponentRegistry.registerComponentInternal(ComponentRegistry.java:187)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:156)
> at org.infinispan.factories.AbstractComponentRegistry.getOrCreateComponent(AbstractComponentRegistry.java:277)
> at org.infinispan.factories.ComponentRegistry.getOrCreateComponent(ComponentRegistry.java:150)
> at org.infinispan.factories.AbstractComponentRegistry.invokeInjectionMethod(AbstractComponentRegistry.java:227)
> at org.infinispan.factories.AbstractComponentRegistry.access$000(AbstractComponentRegistry.java:65)
> at org.infinispan.factories.AbstractComponentRegistry$Component.injectDependencies(AbstractComponentRegistry.java:797)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:201)
> at org.infinispan.factories.ComponentRegistry.registerComponentInternal(ComponentRegistry.java:187)
> at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:156)
> at org.infinispan.factories.InternalCacheFactory.bootstrap(InternalCacheFactory.java:79)
> at org.infinispan.factories.InternalCacheFactory.createAndWire(InternalCacheFactory.java:58)
> at org.infinispan.factories.InternalCacheFactory.createCache(InternalCacheFactory.java:42)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:549)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:516)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:398)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:371)
> at org.infinispan.test.SingleCacheManagerTest.setup(SingleCacheManagerTest.java:32)
> at org.infinispan.test.SingleCacheManagerTest.createBeforeMethod(SingleCacheManagerTest.java:55)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
> at java.lang.reflect.Method.invoke(Method.java:611)
> at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:80)
> at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:564)
> at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:213)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:653)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:901)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1231)
> at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:127)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:111)
> at org.testng.TestRunner.privateRun(TestRunner.java:767)
> at org.testng.TestRunner.run(TestRunner.java:617)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:334)
> at org.testng.SuiteRunner.access$000(SuiteRunner.java:37)
> at org.testng.SuiteRunner$SuiteWorker.run(SuiteRunner.java:368)
> at org.testng.internal.thread.ThreadUtil$2.call(ThreadUtil.java:64)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:314)
> at java.util.concurrent.FutureTask.run(FutureTask.java:149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:908)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:931)
> at java.lang.Thread.run(Thread.java:738)
> Caused by: java.lang.ClassNotFoundException: java.util.RegularEnumSet
> at java.lang.Class.forName(Class.java:217)
> at org.infinispan.commons.util.Util.loadClassStrict(Util.java:122)
> at org.infinispan.commons.util.Util.loadClass(Util.java:83)
> ... 102 more
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (ISPN-3847) Improve resilience of ModuleLifecycle loading
by Paul Ferraro (JIRA)
Paul Ferraro created ISPN-3847:
----------------------------------
Summary: Improve resilience of ModuleLifecycle loading
Key: ISPN-3847
URL: https://issues.jboss.org/browse/ISPN-3847
Project: Infinispan
Issue Type: Enhancement
Components: Core API
Affects Versions: 6.0.0.Final
Reporter: Paul Ferraro
Assignee: Mircea Markus
Currently, org.infinispan.util.ModuleProperties.resolveModuleLifecycles(...) uses a ServiceLoader to directly load ModuleLifecycle instances. However, if a jar exists on the classpath containing a META-INF/services/org.infinispan.lifecycle.ModuleLifecycle file, but the class name contained within cannot be loaded, due to, for example, a dependency jar being missing, then the whole resolveModuleLifecycles(...) method chokes due to a ServiceConfigurationError. For example, if infinispan-query is on the classpath, but hibernate-search is not, Infinispan is unusable.
I can see 2 ways to fix this:
1. Use the iterator directly instead of the enhanced for-loop, and catch and handle the SCE:
e.g.
{code:java}
Iterator<ModuleLifecycle> lifecycles = ServiceLoader.load(ModuleLifecycle.class, classLoader);
while (lifecycles.hasNext()) {
try {
ModuleLifecycle lifecycle = lifecycles.next(); // This can throw SCE
result.add(lifecycle);
} catch (ServiceConfigurationError e) {
// Log error
}
}
{code}
2. Introduce a ModuleLifecycleProvider abstraction - that won't throw an SCE. The ServiceLoader spec actually recommends this:
"The provider class is typically not the entire provider itself but rather a proxy which contains enough information to decide whether the provider is able to satisfy a particular request together with code that can create the actual provider on demand."
In the end, this would look something like:
{code:java}
for (ModuleLifecycleFactory factory: ServiceLoader.load(ModuleLifecycleFactory.class, classLoader)) {
if (factory.isEnabled()) { // returns true if create method will not throw SCE
ModuleLifecycle lifecycle = factory.createModuleLifecycle();
result.add(lifecycle);
}
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years
[JBoss JIRA] (ISPN-3842) Inconsistent L1 in non-tx distributed cache in certain circumstances
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-3842?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-3842:
-------------------------------------
Okay looking a bit closer I think I know what the issue is here. The InvalidateL1Command comes in and finds no value in the data container so it doesn't store anything in the invocation context. Then the get completes and commits the data to the container. Then the InvalidateL1Command checks the data container and finds the value and delegates the call to the RemoveCommand which it extends. Unfortunately the RemoveCommand only marks entries that are in the context for removal. So in this case the InvalidateL1Command should wrap the newly found value from the data container and put it in the context so the RemoveCommand can properly remove it.
I will write up a test which should reproduce this consistently and fix this up.
> Inconsistent L1 in non-tx distributed cache in certain circumstances
> --------------------------------------------------------------------
>
> Key: ISPN-3842
> URL: https://issues.jboss.org/browse/ISPN-3842
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 6.0.0.Final
> Reporter: Mikolaj Gierulski
> Assignee: William Burns
>
> In my poc environment there are two nodes in dist non-tx sync cluster with L1 enabled and numOwners=1.
> Node A, in a loop, reads one key (K), which is stored on node B (in test case it performs about 1 000 000 reads per second).
> From time to time K is updated on node B. This causes an L1 invalidation message sent to A, and K is fetched from B upon next read attempt.
> But whenever I run my test, I come to a situation, where updates of K no longer invalidate it on A, and A sees old value of K.
> When this happens, I can see in logs of node A:
> {noformat}
> 18:21:33.296 [remote-thread-0] TRACE o.i.i.d.L1NonTxInterceptor - L1 invalidation found a pending update for key K - need to block until finished
> 18:21:33.296 [remote-thread-0] TRACE o.i.i.d.L1NonTxInterceptor - Pending L1 update completed successfully: true - L1 invalidation can occur for key K
> 18:21:33.296 [remote-thread-0] TRACE o.i.c.write.InvalidateL1Command - Preparing to invalidate keys [K]
> 18:21:33.296 [remote-thread-0] TRACE o.i.c.write.InvalidateL1Command - Invalidating key K.
> 18:21:33.296 [remote-thread-0] TRACE o.i.commands.write.RemoveCommand - Nothing to remove since the entry is null or we have a null entry
> {noformat}
> While logs of node B show:
> {noformat}
> 18:21:33.200 [OOB-1,AGST-2012000591-33853] TRACE o.i.distribution.L1ManagerImpl - Registering requestor AGST-2012000591-25400 for key 'K'
> 18:21:33.266 [remote-thread-1] TRACE o.i.distribution.L1ManagerImpl - Invalidating keys [K] on nodes [AGST-2012000591-25400]. Use multicast? false
> 18:21:33.269 [remote-thread-1] TRACE o.i.i.d.L1NonTxInterceptor - Allowing entry to commit as local node is owner
> 18:21:33.269 [OOB-2,AGST-2012000591-33853] TRACE o.i.distribution.L1ManagerImpl - Registering requestor AGST-2012000591-25400 for key 'K'
> 18:21:33.269 [remote-thread-1] TRACE o.i.i.d.L1NonTxInterceptor - Sending additional invalidation for requestors if necessary.
> 18:21:33.269 [remote-thread-1] TRACE o.i.distribution.L1ManagerImpl - Invalidating keys [K] on nodes [AGST-2012000591-25400]. Use multicast? false
> 18:21:33.270 [remote-thread-1] INFO p.c.a.ispn.WriteTask - Update task runtime millis 3
> 18:21:33.271 [OOB-1,AGST-2012000591-33853] TRACE o.i.distribution.L1ManagerImpl - Registering requestor AGST-2012000591-25400 for key 'K'
> 18:21:33.293 [remote-thread-1] TRACE o.i.distribution.L1ManagerImpl - Invalidating keys [K] on nodes [AGST-2012000591-25400]. Use multicast? false
> 18:21:33.295 [remote-thread-1] TRACE o.i.i.d.L1NonTxInterceptor - Allowing entry to commit as local node is owner
> 18:21:33.295 [OOB-2,AGST-2012000591-33853] TRACE o.i.distribution.L1ManagerImpl - Registering requestor AGST-2012000591-25400 for key 'K'
> 18:21:33.295 [remote-thread-1] TRACE o.i.i.d.L1NonTxInterceptor - Sending additional invalidation for requestors if necessary.
> 18:21:33.295 [remote-thread-1] TRACE o.i.distribution.L1ManagerImpl - Invalidating keys [K] on nodes [AGST-2012000591-25400]. Use multicast? false
> 18:21:33.295 [remote-thread-1] INFO p.c.a.ispn.WriteTask - Update task runtime millis 2
> 18:21:33.476 [remote-thread-1] TRACE o.i.distribution.L1ManagerImpl - No L1 caches to invalidate for keys [K]
> 18:21:33.476 [remote-thread-1] TRACE o.i.i.d.L1NonTxInterceptor - Allowing entry to commit as local node is owner
> 18:21:33.476 [remote-thread-1] TRACE o.i.i.d.L1NonTxInterceptor - Sending additional invalidation for requestors if necessary.
> 18:21:33.476 [remote-thread-1] TRACE o.i.distribution.L1ManagerImpl - No L1 caches to invalidate for keys [K]
> {noformat}
> So it seems, that after this:
> bq. 'L1 invalidation found a pending update for key K - need to block until finished'
> B no longer knows A holds K in L1, and no longer sends invalidation commands after updates.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years