[JBoss JIRA] (ISPN-2831) NPE in DistributedSegmentReadLocker
by Marko Lukša (JIRA)
[ https://issues.jboss.org/browse/ISPN-2831?page=com.atlassian.jira.plugin.... ]
Marko Lukša updated ISPN-2831:
------------------------------
Issue Type: Bug (was: Feature Request)
Affects Version/s: 5.3.0.Alpha1
> NPE in DistributedSegmentReadLocker
> -----------------------------------
>
> Key: ISPN-2831
> URL: https://issues.jboss.org/browse/ISPN-2831
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.1.Final, 5.3.0.Alpha1
> Reporter: Michal Zaborec
> Assignee: Sanne Grinovero
> Fix For: 5.3.0.Final
>
> Attachments: unable-init-indexmanager-on-restart.txt
>
>
> possible NPE in DistributedSegmentReadLocker
> {code}
> java.lang.NullPointerException
> at org.infinispan.lucene.readlocks.DistributedSegmentReadLocker.realFileDelete(DistributedSegmentReadLocker.java:184)
> at org.infinispan.lucene.readlocks.DistributedSegmentReadLocker.deleteOrReleaseReadLock(DistributedSegmentReadLocker.java:109)
> at org.infinispan.lucene.InfinispanDirectory.deleteFile(InfinispanDirectory.java:213)
> at org.apache.lucene.index.IndexFileDeleter.deleteFile(IndexFileDeleter.java:578)
> {code}
> this is caused by this code:
> {code}
> final int bufferSize = file.getBufferSize();
> if (file != null) //during optimization of index a same file could be deleted twice, so you could see a null here
> ......
> {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, 2 months
[JBoss JIRA] (ISPN-3002) Fix RpcManager API
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-3002?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-3002:
-------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Fix RpcManager API
> ------------------
>
> Key: ISPN-3002
> URL: https://issues.jboss.org/browse/ISPN-3002
> Project: Infinispan
> Issue Type: Bug
> Components: RPC
> Affects Versions: 5.3.0.Alpha1
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Labels: remoting, rpc
> Fix For: 5.3.0.Final
>
>
> The parameter added for Total Order based protocol has broken Hibernate Search API. Create new methods for Total Order instead of changing the old.
> In addition, create a new class (e.g. RpcOptions) to have the rpc options instead of a bunch of methods.
--
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, 2 months
[JBoss JIRA] (ISPN-3032) Use both context and class' class loader when reading component metadata
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3032?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3032:
--------------------------------
Priority: Minor (was: Major)
> Use both context and class' class loader when reading component metadata
> ------------------------------------------------------------------------
>
> Key: ISPN-3032
> URL: https://issues.jboss.org/browse/ISPN-3032
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Mircea Markus
> Assignee: Mircea Markus
> Priority: Minor
>
> {quote}
> Caused by: org.hibernate.search.SearchException: Unable to initialize
> directory provider:
> org.hibernate.search.test.integration.jbossas7.model.Member
> at org.hibernate.search.store.impl.DirectoryProviderFactory.createDirectoryProvider(DirectoryProviderFactory.java:87)
> at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.createDirectoryProvider(DirectoryBasedIndexManager.java:232)
> at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:100)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:227)
> ... 19 more
> Caused by: org.infinispan.config.ConfigurationException:
> org.infinispan.CacheException: Unable to load component metadata!
> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:386)
> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:341)
> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:328)
> at org.hibernate.search.infinispan.CacheManagerServiceProvider.start(CacheManagerServiceProvider.java:93)
> at org.hibernate.search.engine.impl.StandardServiceManager$ServiceProviderWrapper.startVirtual(StandardServiceManager.java:178)
> at org.hibernate.search.engine.impl.StandardServiceManager.requestService(StandardServiceManager.java:124)
> at org.hibernate.search.infinispan.impl.InfinispanDirectoryProvider.initialize(InfinispanDirectoryProvider.java:86)
> at org.hibernate.search.store.impl.DirectoryProviderFactory.createDirectoryProvider(DirectoryProviderFactory.java:84)
> ... 22 more
> Caused by: org.infinispan.CacheException: Unable to load component metadata!
> at org.infinispan.factories.components.ComponentMetadataRepo.initialize(ComponentMetadataRepo.java:131)
> at org.infinispan.factories.GlobalComponentRegistry.<init>(GlobalComponentRegistry.java:103)
> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:381)
> ... 29 more
> Caused by: java.lang.NullPointerException
> at org.infinispan.factories.components.ComponentMetadataRepo.readMetadata(ComponentMetadataRepo.java:53)
> at org.infinispan.factories.components.ComponentMetadataRepo.initialize(ComponentMetadataRepo.java:129)
> ... 31 more
> {quote}
> The exception above is caused by Infinispan using (by default) invocation context's ClassLoader when trying to read the component metadata. In a modularized environment such as AS7 this will cause the metadata not to be found (metadata is packaged in the same jar as the infinispan class that reads it). In order to overcome this problem we should try to use both class' ClassLoader and InvocationContxt's class loader when trying to read the metadata.
> Workaround: set the class loader on the GlobalConfiguration object:
> {code:java}
> GlobalConfiguration.classLoader( GlobalConfiguration.class.getClassLoder())
> {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, 2 months
[JBoss JIRA] (ISPN-3032) Use both context and class' class loader when reading component metadata
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3032?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3032:
--------------------------------
Forum Reference: http://infinispan.markmail.org/search/#query:+page:2+mid:bfmmzxy23teiruvi...
> Use both context and class' class loader when reading component metadata
> ------------------------------------------------------------------------
>
> Key: ISPN-3032
> URL: https://issues.jboss.org/browse/ISPN-3032
> Project: Infinispan
> Issue Type: Enhancement
> Reporter: Mircea Markus
> Assignee: Mircea Markus
> Priority: Minor
>
> {quote}
> Caused by: org.hibernate.search.SearchException: Unable to initialize
> directory provider:
> org.hibernate.search.test.integration.jbossas7.model.Member
> at org.hibernate.search.store.impl.DirectoryProviderFactory.createDirectoryProvider(DirectoryProviderFactory.java:87)
> at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.createDirectoryProvider(DirectoryBasedIndexManager.java:232)
> at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:100)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:227)
> ... 19 more
> Caused by: org.infinispan.config.ConfigurationException:
> org.infinispan.CacheException: Unable to load component metadata!
> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:386)
> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:341)
> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:328)
> at org.hibernate.search.infinispan.CacheManagerServiceProvider.start(CacheManagerServiceProvider.java:93)
> at org.hibernate.search.engine.impl.StandardServiceManager$ServiceProviderWrapper.startVirtual(StandardServiceManager.java:178)
> at org.hibernate.search.engine.impl.StandardServiceManager.requestService(StandardServiceManager.java:124)
> at org.hibernate.search.infinispan.impl.InfinispanDirectoryProvider.initialize(InfinispanDirectoryProvider.java:86)
> at org.hibernate.search.store.impl.DirectoryProviderFactory.createDirectoryProvider(DirectoryProviderFactory.java:84)
> ... 22 more
> Caused by: org.infinispan.CacheException: Unable to load component metadata!
> at org.infinispan.factories.components.ComponentMetadataRepo.initialize(ComponentMetadataRepo.java:131)
> at org.infinispan.factories.GlobalComponentRegistry.<init>(GlobalComponentRegistry.java:103)
> at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:381)
> ... 29 more
> Caused by: java.lang.NullPointerException
> at org.infinispan.factories.components.ComponentMetadataRepo.readMetadata(ComponentMetadataRepo.java:53)
> at org.infinispan.factories.components.ComponentMetadataRepo.initialize(ComponentMetadataRepo.java:129)
> ... 31 more
> {quote}
> The exception above is caused by Infinispan using (by default) invocation context's ClassLoader when trying to read the component metadata. In a modularized environment such as AS7 this will cause the metadata not to be found (metadata is packaged in the same jar as the infinispan class that reads it). In order to overcome this problem we should try to use both class' ClassLoader and InvocationContxt's class loader when trying to read the metadata.
> Workaround: set the class loader on the GlobalConfiguration object:
> {code:java}
> GlobalConfiguration.classLoader( GlobalConfiguration.class.getClassLoder())
> {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, 2 months
[JBoss JIRA] (ISPN-3032) Use both context and class' class loader when reading component metadata
by Mircea Markus (JIRA)
Mircea Markus created ISPN-3032:
-----------------------------------
Summary: Use both context and class' class loader when reading component metadata
Key: ISPN-3032
URL: https://issues.jboss.org/browse/ISPN-3032
Project: Infinispan
Issue Type: Enhancement
Reporter: Mircea Markus
Assignee: Mircea Markus
{quote}
Caused by: org.hibernate.search.SearchException: Unable to initialize
directory provider:
org.hibernate.search.test.integration.jbossas7.model.Member
at org.hibernate.search.store.impl.DirectoryProviderFactory.createDirectoryProvider(DirectoryProviderFactory.java:87)
at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.createDirectoryProvider(DirectoryBasedIndexManager.java:232)
at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:100)
at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:227)
... 19 more
Caused by: org.infinispan.config.ConfigurationException:
org.infinispan.CacheException: Unable to load component metadata!
at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:386)
at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:341)
at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:328)
at org.hibernate.search.infinispan.CacheManagerServiceProvider.start(CacheManagerServiceProvider.java:93)
at org.hibernate.search.engine.impl.StandardServiceManager$ServiceProviderWrapper.startVirtual(StandardServiceManager.java:178)
at org.hibernate.search.engine.impl.StandardServiceManager.requestService(StandardServiceManager.java:124)
at org.hibernate.search.infinispan.impl.InfinispanDirectoryProvider.initialize(InfinispanDirectoryProvider.java:86)
at org.hibernate.search.store.impl.DirectoryProviderFactory.createDirectoryProvider(DirectoryProviderFactory.java:84)
... 22 more
Caused by: org.infinispan.CacheException: Unable to load component metadata!
at org.infinispan.factories.components.ComponentMetadataRepo.initialize(ComponentMetadataRepo.java:131)
at org.infinispan.factories.GlobalComponentRegistry.<init>(GlobalComponentRegistry.java:103)
at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:381)
... 29 more
Caused by: java.lang.NullPointerException
at org.infinispan.factories.components.ComponentMetadataRepo.readMetadata(ComponentMetadataRepo.java:53)
at org.infinispan.factories.components.ComponentMetadataRepo.initialize(ComponentMetadataRepo.java:129)
... 31 more
{quote}
The exception above is caused by Infinispan using (by default) invocation context's ClassLoader when trying to read the component metadata. In a modularized environment such as AS7 this will cause the metadata not to be found (metadata is packaged in the same jar as the infinispan class that reads it). In order to overcome this problem we should try to use both class' ClassLoader and InvocationContxt's class loader when trying to read the metadata.
Workaround: set the class loader on the GlobalConfiguration object:
{code:java}
GlobalConfiguration.classLoader( GlobalConfiguration.class.getClassLoder())
{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, 2 months
[JBoss JIRA] (ISPN-3030) Implement a way to retrieve all keys from a REST endpoint
by Tristan Tarrant (JIRA)
Tristan Tarrant created ISPN-3030:
-------------------------------------
Summary: Implement a way to retrieve all keys from a REST endpoint
Key: ISPN-3030
URL: https://issues.jboss.org/browse/ISPN-3030
Project: Infinispan
Issue Type: Feature Request
Components: Remote protocols
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
Fix For: 5.3.0.Final
The REST server should implement a method for handling GET /cacheName requests and return all available keys.
Depending on the "Accept" header, the keys may be returned in JSON, XML, HTML and plain text formats.
--
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, 2 months
[JBoss JIRA] (ISPN-3029) IllegalMonitorStateException in LockSupportCacheStore.loadAllKeys
by Dan Berindei (JIRA)
Dan Berindei created ISPN-3029:
----------------------------------
Summary: IllegalMonitorStateException in LockSupportCacheStore.loadAllKeys
Key: ISPN-3029
URL: https://issues.jboss.org/browse/ISPN-3029
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Affects Versions: 5.2.5.Final
Reporter: Dan Berindei
Assignee: Mircea Markus
Priority: Critical
Fix For: 5.3.0.Final
Most LockSupportCacheStore methods that call {{acquireGlobalLock()}} ignore its return value and proceed as if the lock was acquired on all the buckets. ISPN-2378 partially fixed this by only attempting to unlock the global lock if the lock was actually acquired, but the processing that was supposed to be protected by the global lock is still executed even if the lock acquisition failed.
In {{loadAllKeys}}, this doesn't usually cause any problems. But if the cache store contains expired entries, it will try to upgrade a bucket lock to a write lock in order to update the bucket on disk, and the upgrade will fail with a IllegalMonitorStateException:
{noformat}
> 20:41:36,960 ERROR [org.infinispan.statetransfer.OutboundTransferTask] (undefined) Failed to execute outbound transfer: java.lang.IllegalMonitorStateException: attempt to unlock read lock, not locked by current thread
> at java.util.concurrent.locks.ReentrantReadWriteLock$Sync.unmatchedUnlockException(ReentrantReadWriteLock.java:447) [rt.jar:1.7.0_09-icedtea]
> at java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(ReentrantReadWriteLock.java:431) [rt.jar:1.7.0_09-icedtea]
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1340) [rt.jar:1.7.0_09-icedtea]
> at java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(ReentrantReadWriteLock.java:883) [rt.jar:1.7.0_09-icedtea]
> at org.infinispan.util.concurrent.locks.StripedLock.upgradeLock(StripedLock.java:140) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> at org.infinispan.loaders.LockSupportCacheStore.upgradeLock(LockSupportCacheStore.java:106) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> at org.infinispan.loaders.bucket.BucketBasedCacheStore.access$000(BucketBasedCacheStore.java:49) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> at org.infinispan.loaders.bucket.BucketBasedCacheStore$CollectionGeneratingBucketHandler.handle(BucketBasedCacheStore.java:159) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> at org.infinispan.loaders.file.FileCacheStore.loopOverBuckets(FileCacheStore.java:102) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> at org.infinispan.loaders.bucket.BucketBasedCacheStore.loadAllKeysLockSafe(BucketBasedCacheStore.java:219) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> at org.infinispan.loaders.LockSupportCacheStore.loadAllKeys(LockSupportCacheStore.java:179) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> at org.infinispan.loaders.decorators.AbstractDelegatingStore.loadAllKeys(AbstractDelegatingStore.java:140) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> at org.infinispan.loaders.decorators.AsyncStore.loadKeys(AsyncStore.java:184) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> at org.infinispan.loaders.decorators.AsyncStore.loadAllKeys(AsyncStore.java:205) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> at org.infinispan.statetransfer.OutboundTransferTask.run(OutboundTransferTask.java:163) [infinispan-core-5.2.4.Final-redhat-2.jar:5.2.4.Final-redhat-2]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_09-icedtea]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_09-icedtea]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_09-icedtea]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [rt.jar:1.7.0_09-icedtea]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_09-icedtea]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_09-icedtea]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_09-icedtea]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_09-icedtea]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_09-icedtea]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA-redhat-2.jar:2.0.0.GA-redhat-2]
{noformat}
A simple solution would be to throw an exception any time the global lock acquisition failed, but the current global lock acquisition algorithm might need to change because it seems very deadlock-prone at the moment.
--
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, 2 months