[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)
8 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)
8 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)
8 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)
8 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)
8 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)
8 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)
8 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)
8 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:
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
> Reporter: Sebastian Łaskawiec
>
> 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)
8 years, 1 month