[JBoss JIRA] (ISPN-4585) Prioritize commands in the remote executor
by Dan Berindei (JIRA)
Dan Berindei created ISPN-4585:
----------------------------------
Summary: Prioritize commands in the remote executor
Key: ISPN-4585
URL: https://issues.jboss.org/browse/ISPN-4585
Project: Infinispan
Issue Type: Enhancement
Security Level: Public (Everyone can see)
Components: Core
Affects Versions: 7.0.0.Alpha5
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 7.0.0.Final
The remote executor currently has an unlimited queue of blocked task, but the underlying executor cannot use a queue. With a queue, we wouldn't need to overflow remote commands to the OOB threads, and the OOB threads would be free to process response messages.
The problem is that {{ThreadPoolExecutor}} executes tasks in the order they are in the queue. If a node has a remote executor thread pool of 100 threads and receives a prepare(tx1, put(k, v1) comand, then 1000 prepare(tx_i, put(k, v_i)) commands, and finally a commit(tx1) command, the commit(tx1) command will block until all but 99 of the the prepare(tx_i, put(k, v_i)) commands have timed out.
I think we could help this by using a {{PriorityBlockingQueue}} for the underlying executor, with commands ordered so that state transfer commands < commit/tx completion notification < prepare/lock. The commit command would still have to wait for one of the prepare commands currently running to time out, but it wouldn't have to wait for all of them.
The current code, without a queue, would fill the remote executor and OOB thread pools, and it would discard the commit message (along with most of the prepare commands). The time it would take to process the commit successfully would depend on the timing of the retransmitted messages.
Another possible improvement would be to keep track of the commands currently being executed, and always keep some threads free for commands with higher priority. But I'm not sure how easy it would be to do that on top of an injected {{ExecutorService}}.
I believe there is also a problem with {{BlockingTaskAwareExecutorServiceImpl.checkForReadyTasks()}} after a topology change. Commands with the new topology id are all unblocked by submitting them to the underlying executor in FIFO order, on a single thread, so {{CallerRunsPolicy}} is not a valid rejection policy here.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-4378) Configure marshaller class for binary filter/converter instances
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-4378?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-4378:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Configure marshaller class for binary filter/converter instances
> ----------------------------------------------------------------
>
> Key: ISPN-4378
> URL: https://issues.jboss.org/browse/ISPN-4378
> Project: Infinispan
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 7.0.0.Beta1, 7.0.0.Final
>
>
> Instead of having the filter/converters plugged with the marshaller instances, it's more practical to have them constructed with the marshaller class, and they can instantiate it in each of the servers. Previous description, for reference, below:
> ----
> The Hot Rod server configuration now has a marshaller configured which is used to enable typed filter/converter parameter handling, and in order to enable typed filter/converter callbacks.
> Note that this is separate from the cache marshaller, and separate from the compatibility marshaller, both of which, have different objectives. For example, you don't want to force compatibility to be enabled to be able to have typed converter/filters. This type conversion has been implementing using BinaryFilter/BinaryConverter classes which unmarshall the key/values and pass them to the filter/converter instances that the user has configured.
> There's a problem with this when running in a cluster. Part of the cluster listener logic involves serializing these filter/converter instances and sending them to other nodes. However, these Binary* classes require the marshaller to do their job, which is not serializable.
> However, the marshaller could be plugged to the Binary* classes if there was some kind of callback or something in each node that gets these classes replicated to, and it can initialise it properly.
> Will has done some work with Adrian to make filter/converters cache components and be able to inject stuff in them. Check if that would work for this use case.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-4584) Stricter validation of cache configurations for distributed indexes
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-4584?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-4584:
---------------------------------------
More short-hand and automated configuration should be delivered in ISPN-4340, here I'm literally exploring what we can do to help debugging for the power users who actually want to do the fine tuning.
The names are inferred already (by default) but we allow to override them, and the test in ISPN-4577 was overriding them.
Same for replTimeout and lock acquisition timeout, those values were set as they were for for reasons unrelated to the indexing system.
Also there is a valid short hand for the property:
{code}<property name="default.indexmanager" value="infinispan" />{code}
Technically this is the only required option, as even lucene_version was not set to the ideal version (but acceptable).
Indeed the metadata Cache could be forced to require REPL, but that's unless it's single node in which you want LOCAL, or unless it's managing independent indexes per node.. tricky. The data storing cache also should be allowed to be anything :-/
So the problem is literally that an advanced user can override most of this and shoot himself. Another problem is that the exceptions I was getting from the failing test is very misleading as there is a long chain of "caused by.." and the interesting part is swallowed: the user facing error is the infamous "UserType is not annotated with @Indexed" just that in this case it was a flat classloader, embedded mode and definitely annotated.
(What was happening is that the EOF triggered by the missing bytes in the storage was happening during the second mutation of the SearchFactory, in which case the type is already marked as "installed" into the known types registry, but the SearchFactory had actually rejected the mutation).
> Stricter validation of cache configurations for distributed indexes
> -------------------------------------------------------------------
>
> Key: ISPN-4584
> URL: https://issues.jboss.org/browse/ISPN-4584
> Project: Infinispan
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Lucene Directory
> Reporter: Sanne Grinovero
> Assignee: Gustavo Fernandes
> Priority: Minor
>
> See also ISPN-4577 : it should not be allowed to configure a distributed metadata cache while the chunks cache is using local mode.
> Ideally think of additional strict checks which we should apply.. suggestions?
> Mitigated by ISPN-4340
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-4577) Indexing: Read past EOF
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-4577?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-4577:
---------------------------------------
I agree, it was very subtle. Your first suggestion matches ISPN-4584 right?
The second one, I don't know how to do that as any cache name is valid and I won't know if it's receiving the default configuration.
> Indexing: Read past EOF
> -----------------------
>
> Key: ISPN-4577
> URL: https://issues.jboss.org/browse/ISPN-4577
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Embedded Querying
> Affects Versions: 6.0.1.Final
> Reporter: Radim Vansa
> Assignee: Sanne Grinovero
> Priority: Critical
>
> When starting a cluster of 2 nodes with distributed cache configured to index to Infinispan, on the second I get this exception:
> {code}
> org.hibernate.search.SearchException: HSEARCH000103: Unable to initialize IndexManager org.infinispan.query.remote.indexing.ProtobufValueWrapper
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:265)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:528)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManagers(IndexManagerHolder.java:495)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.buildEntityIndexBinding(IndexManagerHolder.java:104)
> at org.hibernate.search.spi.SearchFactoryBuilder.initDocumentBuilders(SearchFactoryBuilder.java:359)
> at org.hibernate.search.spi.SearchFactoryBuilder.buildNewSearchFactory(SearchFactoryBuilder.java:217)
> at org.hibernate.search.spi.SearchFactoryBuilder.buildSearchFactory(SearchFactoryBuilder.java:141)
> at org.infinispan.query.impl.LifecycleManager.getSearchFactory(LifecycleManager.java:213)
> at org.infinispan.query.impl.LifecycleManager.cacheStarting(LifecycleManager.java:73)
> at org.infinispan.factories.ComponentRegistry.notifyCacheStarting(ComponentRegistry.java:228)
> at org.infinispan.factories.ComponentRegistry.start(ComponentRegistry.java:214)
> at org.infinispan.CacheImpl.start(CacheImpl.java:675)
> at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:553)
> at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:516)
> at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:398)
> at (my application stack)
> Caused by: org.hibernate.search.SearchException: Could not initialize index
> at org.hibernate.search.store.impl.DirectoryProviderHelper.initializeIndexIfNeeded(DirectoryProviderHelper.java:162)
> at org.hibernate.search.infinispan.impl.InfinispanDirectoryProvider.start(InfinispanDirectoryProvider.java:103)
> at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:103)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:261)
> ... 23 more
> Caused by: java.io.IOException: Read past EOF
> at org.infinispan.lucene.impl.SingleChunkIndexInput.readByte(SingleChunkIndexInput.java:54)
> at org.apache.lucene.store.ChecksumIndexInput.readByte(ChecksumIndexInput.java:41)
> at org.apache.lucene.store.DataInput.readInt(DataInput.java:86)
> at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:272)
> at org.apache.lucene.index.IndexFileDeleter.<init>(IndexFileDeleter.java:182)
> at org.apache.lucene.index.IndexWriter.<init>(IndexWriter.java:1168)
> at org.hibernate.search.store.impl.DirectoryProviderHelper.initializeIndexIfNeeded(DirectoryProviderHelper.java:157)
> ... 26 more
> {code}
> Here is the configuration:
> {code}
> <?xml version="1.0" encoding="UTF-8"?>
> <infinispan
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="urn:infinispan:config:6.0 http://www.infinispan.org/schemas/infinispan-config-6.0.xsd"
> xmlns="urn:infinispan:config:6.0">
> <global>
> <transport clusterName="default" distributedSyncTimeout="600000">
> <properties>
> <property name="configurationFile" value="${infinispan.jgroups.config:jgroups-udp-custom.xml}"/>
> </properties>
> </transport>
> </global>
> <default/>
> <namedCache name="dist_lucene">
> <transaction transactionMode="NON_TRANSACTIONAL"/>
> <clustering mode="DIST">
> <hash numOwners="2" />
> </clustering>
> <locking lockAcquisitionTimeout="3000" concurrencyLevel="1000" />
> <indexing enabled="true" indexLocalOnly="true">
> <properties>
> <property name="default.indexmanager" value="org.infinispan.query.indexmanager.InfinispanIndexManager" />
> <property name="default.exclusive_index_use" value="false" />
> <property name="default.metadata_cachename" value="lucene_metadata_repl" />
> <property name="default.data_cachename" value="lucene_data_dist" />
> <property name="default.locking_cachename" value="lucene_locking_repl" />
> <property name="lucene_version" value="LUCENE_36" />
> </properties>
> </indexing>
> </namedCache>
> <namedCache name="lucene_metadata_repl">
> <clustering mode="REPL">
> <sync replTimeout="30000" />
> </clustering>
> </namedCache>
> <namedCache name="lucene_data_repl">
> <clustering mode="DIST">
> <hash numOwners="2" />
> <sync replTimeout="30000" />
> </clustering>
> </namedCache>
> <namedCache name="lucene_locking_repl">
> <clustering mode="REPL">
> <sync replTimeout="30000" />
> </clustering>
> </namedCache>
> </infinispan>
> {code}
> I was not able to locate the root cause though I can replicate the issue all the time.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-4436) Karaf stucked when running iOSGI integration tests on IBM JDK
by Ion Savin (JIRA)
[ https://issues.jboss.org/browse/ISPN-4436?page=com.atlassian.jira.plugin.... ]
Ion Savin updated ISPN-4436:
----------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/2758
> Karaf stucked when running iOSGI integration tests on IBM JDK
> -------------------------------------------------------------
>
> Key: ISPN-4436
> URL: https://issues.jboss.org/browse/ISPN-4436
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Vitalii Chepeliuk
> Assignee: Ion Savin
> Labels: testsuite_stability
>
> {noformat}
> __ __ ____
> / //_/____ __________ _/ __/
> / ,< / __ `/ ___/ __ `/ /_
> / /| |/ /_/ / / / /_/ / __/
> /_/ |_|\__,_/_/ \__,_/_/
> Apache Karaf (2.3.3)
> Hit '<tab>' for a list of available commands
> and '[cmd] --help' for help on a specific command.
> Hit '<ctrl-d>' or type 'osgi:shutdown' or 'logout' to shutdown Karaf.
> karaf@root> Failed to instantiate SLF4J LoggerFactory
> Reported exception:
> java.lang.NoClassDefFoundError: org.slf4j.impl.StaticLoggerBinder
> at org.slf4j.LoggerFactory.bind(LoggerFactory.java:121)
> at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:111)
> at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:268)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:241)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:254)
> at org.ops4j.pax.exam.rbc.internal.Activator.<clinit>(Activator.java:46)
> at java.lang.J9VMInternals.newInstanceImpl(Native Method)
> at java.lang.Class.newInstance(Class.java:1774)
> at org.apache.felix.framework.Felix.createBundleActivator(Felix.java:4177)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:1972)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1895)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:931)
> at org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:530)
> at org.apache.karaf.features.internal.FeaturesServiceImpl.start(FeaturesServiceImpl.java:1207)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:94)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:619)
> at org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)
> at org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:958)
> at org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:712)
> at org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:824)
> at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)
> at org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
> at java.util.concurrent.FutureTask.run(FutureTask.java:273)
> at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
> at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:245)
> at org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:183)
> at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:668)
> at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:370)
> at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:261)
> at org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:259)
> at org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:222)
> at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)
> at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)
> at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)
> at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)
> at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)
> at org.apache.felix.framework.util.SecureAction.invokeBundleEventHook(SecureAction.java:1103)
> at org.apache.felix.framework.util.EventDispatcher.createWhitelistFromHooks(EventDispatcher.java:695)
> at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:483)
> at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4244)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1923)
> at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
> at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
> at java.lang.Thread.run(Thread.java:853)
> Caused by: java.lang.ClassNotFoundException: org.slf4j.impl.StaticLoggerBinder not found by org.ops4j.pax.exam.rbc [87]
> at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1460)
> at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
> at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:827)
> {noformat}
> Jenkins job could be found here
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-4436) Karaf stucked when running iOSGI integration tests on IBM JDK
by Ion Savin (JIRA)
[ https://issues.jboss.org/browse/ISPN-4436?page=com.atlassian.jira.plugin.... ]
Ion Savin commented on ISPN-4436:
---------------------------------
The OOMEs were caused by JPAStoreOOMETest running with the store in memory. Removed the test from the OSGi suite.
> Karaf stucked when running iOSGI integration tests on IBM JDK
> -------------------------------------------------------------
>
> Key: ISPN-4436
> URL: https://issues.jboss.org/browse/ISPN-4436
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Vitalii Chepeliuk
> Assignee: Ion Savin
> Labels: testsuite_stability
>
> {noformat}
> __ __ ____
> / //_/____ __________ _/ __/
> / ,< / __ `/ ___/ __ `/ /_
> / /| |/ /_/ / / / /_/ / __/
> /_/ |_|\__,_/_/ \__,_/_/
> Apache Karaf (2.3.3)
> Hit '<tab>' for a list of available commands
> and '[cmd] --help' for help on a specific command.
> Hit '<ctrl-d>' or type 'osgi:shutdown' or 'logout' to shutdown Karaf.
> karaf@root> Failed to instantiate SLF4J LoggerFactory
> Reported exception:
> java.lang.NoClassDefFoundError: org.slf4j.impl.StaticLoggerBinder
> at org.slf4j.LoggerFactory.bind(LoggerFactory.java:121)
> at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:111)
> at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:268)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:241)
> at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:254)
> at org.ops4j.pax.exam.rbc.internal.Activator.<clinit>(Activator.java:46)
> at java.lang.J9VMInternals.newInstanceImpl(Native Method)
> at java.lang.Class.newInstance(Class.java:1774)
> at org.apache.felix.framework.Felix.createBundleActivator(Felix.java:4177)
> at org.apache.felix.framework.Felix.activateBundle(Felix.java:1972)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1895)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:944)
> at org.apache.felix.framework.BundleImpl.start(BundleImpl.java:931)
> at org.apache.karaf.features.internal.FeaturesServiceImpl.installFeatures(FeaturesServiceImpl.java:530)
> at org.apache.karaf.features.internal.FeaturesServiceImpl.start(FeaturesServiceImpl.java:1207)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:94)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:619)
> at org.apache.aries.blueprint.utils.ReflectionUtils.invoke(ReflectionUtils.java:297)
> at org.apache.aries.blueprint.container.BeanRecipe.invoke(BeanRecipe.java:958)
> at org.apache.aries.blueprint.container.BeanRecipe.runBeanProcInit(BeanRecipe.java:712)
> at org.apache.aries.blueprint.container.BeanRecipe.internalCreate2(BeanRecipe.java:824)
> at org.apache.aries.blueprint.container.BeanRecipe.internalCreate(BeanRecipe.java:787)
> at org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
> at java.util.concurrent.FutureTask.run(FutureTask.java:273)
> at org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
> at org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:245)
> at org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:183)
> at org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:668)
> at org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:370)
> at org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:261)
> at org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:259)
> at org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:222)
> at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)
> at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)
> at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)
> at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)
> at org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)
> at org.apache.felix.framework.util.SecureAction.invokeBundleEventHook(SecureAction.java:1103)
> at org.apache.felix.framework.util.EventDispatcher.createWhitelistFromHooks(EventDispatcher.java:695)
> at org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:483)
> at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4244)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:1923)
> at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
> at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
> at java.lang.Thread.run(Thread.java:853)
> Caused by: java.lang.ClassNotFoundException: org.slf4j.impl.StaticLoggerBinder not found by org.ops4j.pax.exam.rbc [87]
> at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1460)
> at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72)
> at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:827)
> {noformat}
> Jenkins job could be found here
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/e...
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-2849) Don't keep threads blocked when waiting for locks to be released
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-2849?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-2849:
------------------------------------
My comment about TopologyAffectedCommands was fixed with ISPN-3527.
> Don't keep threads blocked when waiting for locks to be released
> ----------------------------------------------------------------
>
> Key: ISPN-2849
> URL: https://issues.jboss.org/browse/ISPN-2849
> Project: Infinispan
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Core
> Affects Versions: 6.0.0.CR1
> Reporter: Mircea Markus
> Assignee: Pedro Ruivo
>
> ATM if a tx2 waits on a lock to be released by tx1, the (incoming) tx2 thread is BLOCKED and taken out from the pool. A better way to implement this is by using a structure that would hold and order the depending transactions on the receiver correlated with the async execution API from JGroups 3.3.0, result being that tx2 would not BLOCK but return to the pool this (not maxing out the thread pool that executes commands).
> More about it in the "Async invocation section" of https://docspace.corp.redhat.com/docs/DOC-134411
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months
[JBoss JIRA] (ISPN-4584) Stricter validation of cache configurations for distributed indexes
by Emmanuel Bernard (JIRA)
[ https://issues.jboss.org/browse/ISPN-4584?page=com.atlassian.jira.plugin.... ]
Emmanuel Bernard commented on ISPN-4584:
----------------------------------------
Maybe by rethinking how much of these settings the user should see and for how many use cases.
Could we impose or default the names of the index data, metadata and locking caches to <owning-cache>_index_data, <owning-cache>_index_metadata, <owning-cache>_index_locking? Could we infer most of their settings, should they all be interlocked (same time out?, some are always REPL, some are always DIST?).
Based on that you can infer things and end up with something like
{code}
<namedCache name="dist_lucene">
<transaction transactionMode="NON_TRANSACTIONAL"/>
<clustering mode="DIST">
<hash numOwners="2" />
</clustering>
<locking lockAcquisitionTimeout="3000" concurrencyLevel="1000" />
<indexing enabled="true" indexLocalOnly="true">
<properties>
<!-- can we infer this, or make it a more compact setting before |properties| maybe an attribute of |indexing storage="infinispan"|
<property name="default.indexmanager" value="org.infinispan.query.indexmanager.InfinispanIndexManager" />
<property name="default.exclusive_index_use" value="false" />
<!-- names inferred from the owning named cache, number of owners inferred from the owner's clustering.hash[numOwners], -->
<! should we offer the ability to set replTimeout="30000" or can it be inferred? -->
<property name="lucene_version" value="LUCENE_36" />
</properties>
</indexing>
</namedCache>
{code}
This approach does not replace the old model where all the guts and gory details are exposed. It just makes it much simpler for new comers that don't need to control and fine tune every quark of their body like Dr Manhattan and Sanne. The drawback is that if you need fine tuning, the complexity grows pretty quickly but that's the price of the backward compatibility.
Note that most of this trick can probably be implemented in the configuration parser as a front end that spits out what the fully detailed configuration would have been.
> Stricter validation of cache configurations for distributed indexes
> -------------------------------------------------------------------
>
> Key: ISPN-4584
> URL: https://issues.jboss.org/browse/ISPN-4584
> Project: Infinispan
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Lucene Directory
> Reporter: Sanne Grinovero
> Assignee: Gustavo Fernandes
> Priority: Minor
>
> See also ISPN-4577 : it should not be allowed to configure a distributed metadata cache while the chunks cache is using local mode.
> Ideally think of additional strict checks which we should apply.. suggestions?
> Mitigated by ISPN-4340
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
10 years, 5 months