[JBoss JIRA] (ISPN-6563) If Infinispan is used as a provider for JCache using the remote approach it will not pick up the hotrod-client.properties
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-6563?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-6563:
-----------------------------------------------
Vaclav Dedik <vdedik(a)redhat.com> changed the Status of [bug 1332936|https://bugzilla.redhat.com/show_bug.cgi?id=1332936] from POST to MODIFIED
> If Infinispan is used as a provider for JCache using the remote approach it will not pick up the hotrod-client.properties
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-6563
> URL: https://issues.jboss.org/browse/ISPN-6563
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols
> Affects Versions: 8.2.1.Final, 9.0.0.Alpha1
> Reporter: Wolf-Dieter Fink
> Assignee: Galder Zamarreño
> Fix For: 9.0.0.Alpha2, 8.2.2.Final, 9.0.0.Final
>
>
> If an application use the javax.cache JCache API together with the infinispan-jcache-remote library the CacheManager is created with defaults.
> But it is expected that the hotrod-client.properties are used to configure the remote connection.
> The code is like this:
> {
> import javax.cache.*;
> ...
> CachingProvider jcacheProvider = Caching.getCachingProvider();
> CacheManager cacheManager = jcacheProvider.getCacheManager();
> }
> The org.infinispan.jcache.AbstractJCachingProvider use the org.infinispan.jcache.remote.CacheManger but does not provide properties.
> Therefor the CacheManager is constructed with the default of localhost:11222 as the configuration is not loaded from the properties file.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (ISPN-6574) JCache CacheManger need to know about existing caches if remote (HotRod) is used
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-6574?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-6574:
-----------------------------------------------
Vaclav Dedik <vdedik(a)redhat.com> changed the Status of [bug 1332924|https://bugzilla.redhat.com/show_bug.cgi?id=1332924] from POST to MODIFIED
> JCache CacheManger need to know about existing caches if remote (HotRod) is used
> --------------------------------------------------------------------------------
>
> Key: ISPN-6574
> URL: https://issues.jboss.org/browse/ISPN-6574
> Project: Infinispan
> Issue Type: Bug
> Components: JCache
> Affects Versions: 8.2.1.Final, 9.0.0.Alpha1
> Reporter: Wolf-Dieter Fink
> Assignee: Galder Zamarreño
> Fix For: 9.0.0.Alpha2, 8.2.2.Final, 9.0.0.Final
>
>
> For a client which use the JCache API in combination with a Infinispan server it is expected that a getCache("MyCache") would return a reference to the existing cache or an Exception according to JSR-107 API.
> Also the getCacheNames() enableManagement(..) and enableStatistic(...) should support this also.
> Excerpt from API Doc:
> ------------------------------------
> K,V> Cache<K,V> getCache(String cacheName,
> Class<K> keyType,
> Class<V> valueType)
> Looks up a managed Cache given its name.
> This method must be used for Caches that were configured with runtime key and value types. Use getCache(String) for Caches where these were not specified.
> Implementations must ensure that the key and value types are the same as those configured for the Cache prior to returning from this method.
> Implementations may further perform type checking on mutative cache operations and throw a ClassCastException if these checks fail.
> Implementations that support declarative mechanisms for pre-configuring Caches may return a pre-configured Cache instead of null.
> Parameters:
> cacheName - the name of the managed Cache to acquire
> keyType - the expected Class of the key
> valueType - the expected Class of the value
> Returns:
> the Cache or null if it does exist or can't be pre-configured
> Throws:
> IllegalStateException - if the CacheManager is isClosed()
> IllegalArgumentException - if the specified key and/or value types are incompatible with the configured cache.
> SecurityException - when the operation could not be performed due to the current security settings
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (ISPN-3938) AdvancedAsyncCacheLoader.process() concurrency issues
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3938?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3938:
-----------------------------------------------
Vaclav Dedik <vdedik(a)redhat.com> changed the Status of [bug 1312186|https://bugzilla.redhat.com/show_bug.cgi?id=1312186] from POST to MODIFIED
> AdvancedAsyncCacheLoader.process() concurrency issues
> -----------------------------------------------------
>
> Key: ISPN-3938
> URL: https://issues.jboss.org/browse/ISPN-3938
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Loaders and Stores
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Assignee: Sebastian Łaskawiec
> Fix For: 8.2.0.CR1
>
>
> {{AdvancedAsyncCacheLoader.process()}} calls {{advancedLoader().process()}} to collect all the keys in the store, but the HashSet used to collect the keys it not thread-safe. This can cause problems, e.g. during state transfer:
> {noformat}
> WARN cheTopologyControlCommand | ISPN000071: Caught exception when handling command CacheTopologyControlCommand{cache=sessions, type=CH_UPDATE, sender=alfie-lt-46127, joinInfo=null, topologyId=3, currentCH=DefaultConsistentHash{numSegments=60, numOwners=1, members=[alfie-lt-46127]}, pendingCH=null, throwable=null, viewId=1}java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextEntry(HashMap.java:926)
> at java.util.HashMap$KeyIterator.next(HashMap.java:960)
> at org.infinispan.persistence.async.AdvancedAsyncCacheLoader.process(AdvancedAsyncCacheLoader.java:80)
> at org.infinispan.persistence.manager.PersistenceManagerImpl.processOnAllStores(PersistenceManagerImpl.java:414)
> at org.infinispan.statetransfer.StateConsumerImpl.invalidateSegments(StateConsumerImpl.java:910)
> at org.infinispan.statetransfer.StateConsumerImpl.onTopologyUpdate(StateConsumerImpl.java:393)
> at org.infinispan.statetransfer.StateTransferManagerImpl.doTopologyUpdate(StateTransferManagerImpl.java:178)
> at org.infinispan.statetransfer.StateTransferManagerImpl.access$000(StateTransferManagerImpl.java:38)
> at org.infinispan.statetransfer.StateTransferManagerImpl$1.updateConsistentHash(StateTransferManagerImpl.java:100)
> at org.infinispan.topology.LocalTopologyManagerImpl.handleConsistentHashUpdate(LocalTopologyManagerImpl.java:191)
> at org.infinispan.topology.CacheTopologyControlCommand.doPerform(CacheTopologyControlCommand.java:152)
> at org.infinispan.topology.CacheTopologyControlCommand.perform(CacheTopologyControlCommand.java:124)
> at org.infinispan.topology.ClusterTopologyManagerImpl$3.run(ClusterTopologyManagerImpl.java:606)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (ISPN-6276) Non-threadsafe use of HashSet in AdvancedAsyncCacheLoader
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-6276?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-6276:
-----------------------------------------------
Vaclav Dedik <vdedik(a)redhat.com> changed the Status of [bug 1312186|https://bugzilla.redhat.com/show_bug.cgi?id=1312186] from POST to MODIFIED
> Non-threadsafe use of HashSet in AdvancedAsyncCacheLoader
> ----------------------------------------------------------
>
> Key: ISPN-6276
> URL: https://issues.jboss.org/browse/ISPN-6276
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 6.0.2.Final
> Reporter: Dennis Reed
> Assignee: Sebastian Łaskawiec
>
> org.infinispan.persistence.async.AdvancedAsyncCacheLoader$process creates a HashSet, and passes it to loadAllKeys().
> loadAllKeys() creates a task to get each key and add it to the HashSet.
> This task is run by org.infinispan.persistence.file.SingleFileStore#process, which runs it in multiple threads at once (one thread per key).
> There is no synchronization on that HashSet that is shared by the multiple threads.
> HashSet is not thread safe. One known side effect of non-synchronized access by multiple threads is infinite loops, which has been witnessed here.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months