[JBoss JIRA] (ISPN-6038) ClientAsymmetricClusterTest.testAsymmetricCluster random failures
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6038?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant commented on ISPN-6038:
---------------------------------------
This is quite tricky to resolve:
the test is supposed to demonstrate that clients can connect to caches which are only defined on some nodes, but the way the PING is handled prevents this from succeeding if the first server to reply doesn't have the cache.
If we really want to support asymmetric caches (and I think it's too much effort for the remote use-case anyway), PING should look at the hotrod topology cache for topology information instead of checking with its cache manager for cache existence. However, this raises another issue: the cache might have been defined after the server has started so the topology cache won't have any knowledge about it. This could be mitigated by adding a cacheStarted listener on the cacheManager which would update the topology information, but obviously this needs the cache to actually be started.
All in all, I vote to suppress this test and declare asymmetric caches as unsupported in server.
> ClientAsymmetricClusterTest.testAsymmetricCluster random failures
> -----------------------------------------------------------------
>
> Key: ISPN-6038
> URL: https://issues.jboss.org/browse/ISPN-6038
> Project: Infinispan
> Issue Type: Bug
> Components: Remote Protocols, Test Suite - Server
> Reporter: Dan Berindei
> Assignee: Galder Zamarreño
> Priority: Blocker
> Labels: testsuite_stability
> Fix For: 8.2.0.CR1
>
>
> {{ClientAsymmetricClusterTest.testAsymmetricCluster}} is failing since the ISPN-5981 fix, which enabled {{pingOnStartup}} by default, and now returns {{null}} if the first server to be pinged doesn't have the cache defined.
> {noformat}
> 10:23:07,862 WARN (testng-ClientAsymmetricClusterTest:) [Codec21] ISPN004005: Error received from the server: org.infinispan.server.hotrod.CacheNotFoundException: Cache with name 'asymmetricCache' not found amongst the configured caches
> 10:23:07,862 ERROR (testng-ClientAsymmetricClusterTest:) [UnitTestTestNGListener] Test testAsymmetricCluster(org.infinispan.client.hotrod.ClientAsymmetricClusterTest) failed.
> java.lang.NullPointerException
> at org.infinispan.client.hotrod.ClientAsymmetricClusterTest.testAsymmetricCluster(ClientAsymmetricClusterTest.java:38) ~[test-classes/:?]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ISPN-6117) Management console - cache configuration can not be be edited
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-6117?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic commented on ISPN-6117:
-------------------------------------------
The reason editing existing cache configuration is more complicated is that we have to detect if we are changing an existing cache configuration subnode (e.g. locking) or if we are adding an entirely new configuration subnode (e.g. eviction). In the first case, we have to use write-attribute DMR op and in the second add DMR op. We effectively have to do a diff of a cache configuration tree executing a mix of write attribute and add operations. Not impossible but not trivial either.
> Management console - cache configuration can not be be edited
> -------------------------------------------------------------
>
> Key: ISPN-6117
> URL: https://issues.jboss.org/browse/ISPN-6117
> Project: Infinispan
> Issue Type: Bug
> Components: Console
> Reporter: Roman Macor
> Assignee: Vladimir Blagojevic
> Priority: Blocker
>
> go to Caches tab -> click on container -> click on cache -> actions
> There is no option to edit configuration, only option to view configuration.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ISPN-6093) When infinispan-remote and infinispan-embedded are deployed together we get an error
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-6093?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec closed ISPN-6093.
-------------------------------------
Fix Version/s: 8.2.0.CR1
Resolution: Done
> When infinispan-remote and infinispan-embedded are deployed together we get an error
> ------------------------------------------------------------------------------------
>
> Key: ISPN-6093
> URL: https://issues.jboss.org/browse/ISPN-6093
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 8.1.0.Final
> Reporter: Sebastian Łaskawiec
> Assignee: Sebastian Łaskawiec
> Priority: Minor
> Fix For: 8.2.0.CR1
>
>
> {code}
> Exception in thread "main" java.lang.NoSuchMethodError: org.infinispan.commons.logging.BasicLogFactory.getLog(Ljava/lang/Class;)Lorg/jboss/logging/BasicLogger;
> at org.infinispan.client.hotrod.impl.operations.PingOperation.<clinit>(PingOperation.java:25)
> at org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory.ping(TransportObjectFactory.java:51)
> at org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory.makeObject(TransportObjectFactory.java:45)
> at org.infinispan.client.hotrod.impl.transport.tcp.TransportObjectFactory.makeObject(TransportObjectFactory.java:16)
> at infinispan.org.apache.commons.pool.impl.GenericKeyedObjectPool.borrowObject(GenericKeyedObjectPool.java:1220)
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.pingServersIgnoreException(TcpTransportFactory.java:177)
> at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransportFactory.start(TcpTransportFactory.java:148)
> at org.infinispan.client.hotrod.RemoteCacheManager.start(RemoteCacheManager.java:579)
> at org.infinispan.client.hotrod.RemoteCacheManager.<init>(RemoteCacheManager.java:380)
> at org.infinispan.client.hotrod.RemoteCacheManager.<init>(RemoteCacheManager.java:387)
> at org.infinispan.data.RemoteWordCount.main(RemoteWordCount.java:25)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:144)
> {code}
> The main cause is that in embedded BasicLogger is relocated whereas in remote it's not.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ISPN-6149) Management console - refresh button on cluster detail page doesn't work properly
by Vladimir Blagojevic (JIRA)
[ https://issues.jboss.org/browse/ISPN-6149?page=com.atlassian.jira.plugin.... ]
Vladimir Blagojevic commented on ISPN-6149:
-------------------------------------------
[~rmacor] Let's open another issue for that particular problem - double click issue. We are going to prevent double clicks across the board. I am sure there are more instances of it all across the admin console application.
> Management console - refresh button on cluster detail page doesn't work properly
> --------------------------------------------------------------------------------
>
> Key: ISPN-6149
> URL: https://issues.jboss.org/browse/ISPN-6149
> Project: Infinispan
> Issue Type: Bug
> Components: Console
> Reporter: Roman Macor
> Assignee: Vladimir Blagojevic
> Attachments: Screenshot-refresh.png
>
>
> Clusters tab -> click on cluster
> Actions -> stop -> wait for cluster to stop -> refresh
> - cluster status doesn't change (should be "stopped"), after pressing refresh again cluster status disappears
> Another issue:
> - Pressing refresh repeatably results in nodes being displayed more than once (please see attached screenshot)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ISPN-3938) AdvancedAsyncCacheLoader.process() concurrency issues
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-3938?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec commented on ISPN-3938:
-------------------------------------------
I think this issue might be treated as a duplicate of https://issues.jboss.org/browse/ISPN-6276.
A JIRA for proper solution (which might help us defending from broken implementations) has been created here: https://issues.jboss.org/browse/ISPN-6279
If you agree with me - I'll close this ticket.
> 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: Dan Berindei
> 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)
10 years, 1 month
[JBoss JIRA] (ISPN-6279) Refactor CacheLoader API to make it thread safe
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-6279?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec updated ISPN-6279:
--------------------------------------
Description:
h3. Introduction
Currently {{CacheLoader}} thread safety can be easily compromised by broken implementations. We should provide a better implementation to make it more convenient and less error prone.
h3. Problem statement
CacheLoader API looks like this:
{code}
public interface AdvancedCacheLoader<K, V> extends CacheLoader<K, V> {
...
void process(KeyFilter<? super K> filter, CacheLoaderTask<K, V> task, Executor executor, boolean fetchValue, boolean fetchMetadata);
...
}
{code}
The CacheLoader implementation controls {{CacheLoaderTask}} as well as the number of threads used for processing (specified by {{Executor}}). If one wants to collect all keys (similarly to [AdvancedCacheLoader|https://github.com/infinispan/infinispan/blob/master/...]) it is very easy to hit concurrently issues while adding them to the set (See previous JIRAs: ISPN-3938 and ISPN-6276).
h3. Solution
The solution should take away currently control (Executor) and keyset (the simplest idea is to add it to {{CacheLoaderTask}}) from from the implementation. One of the ideas is to create a Lambda expression for pulling records from Cache Store. Note that similar changes will need to be performed to {{CacheWriter}} (to make it similar).
was:
Currently the CacheLoader thread safety can be easily compromised by broken implementations.
CacheLoader API looks like this:
{code}
void process(KeyFilter<? super K> filter, CacheLoaderTask<K, V> task, Executor executor, boolean fetchValue, boolean fetchMetadata);
{code}
The CacheLoader implementation controls {{CacheLoaderTask}} as well as the number of threads (specified by {{Executor}}). If one wants to collect keys (similarly to [AdvancedCacheLoader|https://github.com/infinispan/infinispan/blob/master/...]) it is very easy to hit concurrently issues while adding new entries to the set (See previous JIRAs: ISPN-3938 and ISPN-6276).
The solution should take away the control of both concurrently (Executor) and keyset (the simplest idea is to add it to {{CacheLoaderTask}}) from user. However there are other (better) ideas like allowing CacheLoader implementations to specify Lambda expression for loading entries
> Refactor CacheLoader API to make it thread safe
> -----------------------------------------------
>
> Key: ISPN-6279
> URL: https://issues.jboss.org/browse/ISPN-6279
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores
> Reporter: Sebastian Łaskawiec
> Priority: Minor
> Fix For: 9.0.0.Final
>
>
> h3. Introduction
> Currently {{CacheLoader}} thread safety can be easily compromised by broken implementations. We should provide a better implementation to make it more convenient and less error prone.
> h3. Problem statement
> CacheLoader API looks like this:
> {code}
> public interface AdvancedCacheLoader<K, V> extends CacheLoader<K, V> {
> ...
> void process(KeyFilter<? super K> filter, CacheLoaderTask<K, V> task, Executor executor, boolean fetchValue, boolean fetchMetadata);
> ...
> }
> {code}
> The CacheLoader implementation controls {{CacheLoaderTask}} as well as the number of threads used for processing (specified by {{Executor}}). If one wants to collect all keys (similarly to [AdvancedCacheLoader|https://github.com/infinispan/infinispan/blob/master/...]) it is very easy to hit concurrently issues while adding them to the set (See previous JIRAs: ISPN-3938 and ISPN-6276).
> h3. Solution
> The solution should take away currently control (Executor) and keyset (the simplest idea is to add it to {{CacheLoaderTask}}) from from the implementation. One of the ideas is to create a Lambda expression for pulling records from Cache Store. Note that similar changes will need to be performed to {{CacheWriter}} (to make it similar).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ISPN-6279) Refactor CacheLoader API to make it thread safe
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-6279?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec updated ISPN-6279:
--------------------------------------
Fix Version/s: 9.0.0.Final
> Refactor CacheLoader API to make it thread safe
> -----------------------------------------------
>
> Key: ISPN-6279
> URL: https://issues.jboss.org/browse/ISPN-6279
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores
> Reporter: Sebastian Łaskawiec
> Fix For: 9.0.0.Final
>
>
> Currently the CacheLoader thread safety can be easily compromised by broken implementations.
> CacheLoader API looks like this:
> {code}
> void process(KeyFilter<? super K> filter, CacheLoaderTask<K, V> task, Executor executor, boolean fetchValue, boolean fetchMetadata);
> {code}
> The CacheLoader implementation controls {{CacheLoaderTask}} as well as the number of threads (specified by {{Executor}}). If one wants to collect keys (similarly to [AdvancedCacheLoader|https://github.com/infinispan/infinispan/blob/master/...]) it is very easy to hit concurrently issues while adding new entries to the set (See previous JIRAs: ISPN-3938 and ISPN-6276).
> The solution should take away the control of both concurrently (Executor) and keyset (the simplest idea is to add it to {{CacheLoaderTask}}) from user. However there are other (better) ideas like allowing CacheLoader implementations to specify Lambda expression for loading entries
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ISPN-6279) Refactor CacheLoader API to make it thread safe
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-6279?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec updated ISPN-6279:
--------------------------------------
Priority: Minor (was: Major)
> Refactor CacheLoader API to make it thread safe
> -----------------------------------------------
>
> Key: ISPN-6279
> URL: https://issues.jboss.org/browse/ISPN-6279
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores
> Reporter: Sebastian Łaskawiec
> Priority: Minor
> Fix For: 9.0.0.Final
>
>
> Currently the CacheLoader thread safety can be easily compromised by broken implementations.
> CacheLoader API looks like this:
> {code}
> void process(KeyFilter<? super K> filter, CacheLoaderTask<K, V> task, Executor executor, boolean fetchValue, boolean fetchMetadata);
> {code}
> The CacheLoader implementation controls {{CacheLoaderTask}} as well as the number of threads (specified by {{Executor}}). If one wants to collect keys (similarly to [AdvancedCacheLoader|https://github.com/infinispan/infinispan/blob/master/...]) it is very easy to hit concurrently issues while adding new entries to the set (See previous JIRAs: ISPN-3938 and ISPN-6276).
> The solution should take away the control of both concurrently (Executor) and keyset (the simplest idea is to add it to {{CacheLoaderTask}}) from user. However there are other (better) ideas like allowing CacheLoader implementations to specify Lambda expression for loading entries
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ISPN-6279) Refactor CacheLoader API to make it thread safe
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-6279?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec updated ISPN-6279:
--------------------------------------
Component/s: Loaders and Stores
> Refactor CacheLoader API to make it thread safe
> -----------------------------------------------
>
> Key: ISPN-6279
> URL: https://issues.jboss.org/browse/ISPN-6279
> Project: Infinispan
> Issue Type: Feature Request
> Components: Loaders and Stores
> Reporter: Sebastian Łaskawiec
> Fix For: 9.0.0.Final
>
>
> Currently the CacheLoader thread safety can be easily compromised by broken implementations.
> CacheLoader API looks like this:
> {code}
> void process(KeyFilter<? super K> filter, CacheLoaderTask<K, V> task, Executor executor, boolean fetchValue, boolean fetchMetadata);
> {code}
> The CacheLoader implementation controls {{CacheLoaderTask}} as well as the number of threads (specified by {{Executor}}). If one wants to collect keys (similarly to [AdvancedCacheLoader|https://github.com/infinispan/infinispan/blob/master/...]) it is very easy to hit concurrently issues while adding new entries to the set (See previous JIRAs: ISPN-3938 and ISPN-6276).
> The solution should take away the control of both concurrently (Executor) and keyset (the simplest idea is to add it to {{CacheLoaderTask}}) from user. However there are other (better) ideas like allowing CacheLoader implementations to specify Lambda expression for loading entries
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month