[JBoss JIRA] (ISPN-7063) FunctionalCachestoreTest and FunctionalInMemoryTest random failures
by Radim Vansa (JIRA)
[ https://issues.jboss.org/browse/ISPN-7063?page=com.atlassian.jira.plugin.... ]
Radim Vansa commented on ISPN-7063:
-----------------------------------
[~dan.berindei] I can't reproduce that locally, but I have added one more commit that could fix this. Could you test it?
> FunctionalCachestoreTest and FunctionalInMemoryTest random failures
> -------------------------------------------------------------------
>
> Key: ISPN-7063
> URL: https://issues.jboss.org/browse/ISPN-7063
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Reporter: Dan Berindei
> Assignee: Radim Vansa
> Labels: testsuite_stability
> Fix For: 9.0.0.Beta1
>
>
> ISPN-6586 introduced a static field in {{invocationCount}} that is shared by {{FunctionalInMemoryTest}} and {{FunctionalCachestoreTest}}. When they run in parallel, the counter is no longer deterministic and they both fail randomly.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (ISPN-7064) RPC to leaver times out instead of finishing immediately
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-7064?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-7064:
-------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/4580, https://github.com/infinispan/infinispan/pull/4581
> RPC to leaver times out instead of finishing immediately
> --------------------------------------------------------
>
> Key: ISPN-7064
> URL: https://issues.jboss.org/browse/ISPN-7064
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Test Suite - Core
> Affects Versions: 9.0.0.Alpha4, 8.2.4.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Critical
> Labels: testsuite_stability
> Fix For: 9.0.0.Beta1
>
>
> This causes random failures in {{ClusterTopologyManagerTest.testAbruptLeaveAfterGetStatus2}}. Node D leaves and nodes E and F start a rebalance. Then node F also leaves, but {{DISCARD}} is enabled first, so the {{CacheTopologyControlCommand(LEAVE)}} synchronous RPC blocks until node F installs a view by itself.
> {noformat}
> 14:05:17,187 INFO (Incoming-1,Test-NodeF-12732:[]) [JGroupsTransport] ISPN000094: Received new cluster view for channel ISPN: [Test-NodeE-18953|3] (2) [Test-NodeE-18953, Test-NodeF-12732]
> 14:05:17,261 TRACE (testng-Test:[]) [JGroupsTransport] dests=[Test-NodeE-18953], command=CacheTopologyControlCommand{cache=testCache, type=LEAVE, sender=Test-NodeF-12732, joinInfo=null, topologyId=0, rebalanceId=0, currentCH=null, pendingCH=null, availabilityMode=null, actualMembers=null, throwable=null, viewId=3}, mode=SYNCHRONOUS, timeout=240000
> 14:05:22,546 DEBUG (Thread-88606:[]) [GMS] Test-NodeF-12732: installing view [Test-NodeF-12732|4] (1) [Test-NodeF-12732]
> 14:05:22,589 DEBUG (testng-Test:[]) [LocalTopologyManagerImpl] Error sending the leave request for cache testCache to coordinator
> {noformat}
> Node F then cancels its inbound state transfers by sending a synchronous {{StateRequestCommand(CANCEL_STATE_TRANSFER)}} RPC to node F. This RPC sometimes hits JGRP-2103 and it only times out after 5 minutes, causing the test to fail.
> {noformat}
> 14:05:22,608 TRACE (testng-Test:[]) [JGroupsTransport] dests=[Test-NodeE-18953], command=StateRequestCommand{cache=testCache, origin=Test-NodeF-12732, type=CANCEL_STATE_TRANSFER, topologyId=7, segments=[130, 3, ...]}, mode=SYNCHRONOUS_IGNORE_LEAVERS, timeout=240000
> 14:05:22,608 TRACE (testng-Test:[]) [RequestCorrelator] Test-NodeF-12732: invoking multicast RPC [req-id=134161]
> 14:05:22,609 DEBUG (Thread-88606:[]) [JGroupsTransport] New view accepted: [Test-NodeF-12732|4] (1) [Test-NodeF-12732]
> 14:09:22,608 TRACE (timeout-thread-Test-NodeF-p48767-t1:[]) [JGroupsTransport] Responses: Responses{
> Test-NodeE-18953: sender=Test-NodeE-18953, received=false, suspected=true}
> 14:09:22,608 TRACE (timeout-thread-Test-NodeF-p48767-t1:[]) [RpcManagerImpl] Replication exception
> org.infinispan.util.concurrent.TimeoutException: Replication timeout
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$2(JGroupsTransport.java:659) ~[classes/:?]
> at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602) ~[?:1.8.0_101]
> at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577) ~[?:1.8.0_101]
> at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) [?:1.8.0_101]
> at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) [?:1.8.0_101]
> at org.infinispan.remoting.transport.jgroups.RspListFuture.call(RspListFuture.java:47) [classes/:?]
> at org.infinispan.remoting.transport.jgroups.RspListFuture.call(RspListFuture.java:15) [classes/:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_101]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:1.8.0_101]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:1.8.0_101]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:1.8.0_101]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:1.8.0_101]
> at java.lang.Thread.run(Thread.java:745) [?:1.8.0_101]
> Suppressed: org.infinispan.remoting.RpcException: Test-NodeE-18953 was suspected
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.addSuppressedExceptions(JGroupsTransport.java:707) ~[classes/:?]
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.lambda$invokeRemotelyAsync$2(JGroupsTransport.java:659) ~[classes/:?]
> at java.util.concurrent.CompletableFuture.uniApply(CompletableFuture.java:602) ~[?:1.8.0_101]
> at java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:577) ~[?:1.8.0_101]
> at java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:474) [?:1.8.0_101]
> at java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:1962) [?:1.8.0_101]
> at org.infinispan.remoting.transport.jgroups.RspListFuture.call(RspListFuture.java:47) [classes/:?]
> at org.infinispan.remoting.transport.jgroups.RspListFuture.call(RspListFuture.java:15) [classes/:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:1.8.0_101]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) [?:1.8.0_101]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) [?:1.8.0_101]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:1.8.0_101]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:1.8.0_101]
> at java.lang.Thread.run(Thread.java:745) [?:1.8.0_101]
> 14:09:22,609 DEBUG (testng-Test:[]) [InboundTransferTask] Caught an exception while cancelling state transfer for segments [130, 3, ...] from Test-NodeE-18953
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (ISPN-7067) Cache.evict() sometimes performs a DataContainer.remove()
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-7067?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-7067:
-------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/4579
> Cache.evict() sometimes performs a DataContainer.remove()
> ---------------------------------------------------------
>
> Key: ISPN-7067
> URL: https://issues.jboss.org/browse/ISPN-7067
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.0.0.Alpha4, 8.2.4.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.0.0.Beta1
>
>
> {{Cache.evict()}} generally uses {{DataContainer.evict()}} to move an entry from the data container to the store.
> However, when {{EntryWrappingInterceptor}} doesn't find the entry in the data container, {{EvictCommand.perform()}} doesn't set the {{EVICTED}} flag on the context entry, and then {{ReadCommittedEntry.commit()}} calls {{DataContainer.remove()}} instead of {{DataContainer.evict()}}.
> If another command activated the entry between the entry wrapping and the commit, this will remove the entry altogether instead of moving it to the store.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (ISPN-7067) Cache.evict() sometimes performs a DataContainer.remove()
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-7067?page=com.atlassian.jira.plugin.... ]
Dan Berindei updated ISPN-7067:
-------------------------------
Status: Open (was: New)
> Cache.evict() sometimes performs a DataContainer.remove()
> ---------------------------------------------------------
>
> Key: ISPN-7067
> URL: https://issues.jboss.org/browse/ISPN-7067
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 9.0.0.Alpha4, 8.2.4.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 9.0.0.Beta1
>
>
> {{Cache.evict()}} generally uses {{DataContainer.evict()}} to move an entry from the data container to the store.
> However, when {{EntryWrappingInterceptor}} doesn't find the entry in the data container, {{EvictCommand.perform()}} doesn't set the {{EVICTED}} flag on the context entry, and then {{ReadCommittedEntry.commit()}} calls {{DataContainer.remove()}} instead of {{DataContainer.evict()}}.
> If another command activated the entry between the entry wrapping and the commit, this will remove the entry altogether instead of moving it to the store.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (ISPN-7067) Cache.evict() sometimes performs a DataContainer.remove()
by Dan Berindei (JIRA)
Dan Berindei created ISPN-7067:
----------------------------------
Summary: Cache.evict() sometimes performs a DataContainer.remove()
Key: ISPN-7067
URL: https://issues.jboss.org/browse/ISPN-7067
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 8.2.4.Final, 9.0.0.Alpha4
Reporter: Dan Berindei
Assignee: Dan Berindei
Fix For: 9.0.0.Beta1
{{Cache.evict()}} generally uses {{DataContainer.evict()}} to move an entry from the data container to the store.
However, when {{EntryWrappingInterceptor}} doesn't find the entry in the data container, {{EvictCommand.perform()}} doesn't set the {{EVICTED}} flag on the context entry, and then {{ReadCommittedEntry.commit()}} calls {{DataContainer.remove()}} instead of {{DataContainer.evict()}}.
If another command activated the entry between the entry wrapping and the commit, this will remove the entry altogether instead of moving it to the store.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (ISPN-3337) Define an approach to allow the injection of Configuration and GlobalConfiguration beans for overriding
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-3337?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec resolved ISPN-3337.
---------------------------------------
Fix Version/s: 9.0.0.Beta1
9.0.0.Final
Resolution: Won't Fix
> Define an approach to allow the injection of Configuration and GlobalConfiguration beans for overriding
> -------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3337
> URL: https://issues.jboss.org/browse/ISPN-3337
> Project: Infinispan
> Issue Type: Feature Request
> Components: Spring Integration
> Reporter: Navin Surtani
> Assignee: Sebastian Łaskawiec
> Fix For: 9.0.0.Beta1, 9.0.0.Final
>
>
> ISPN-3279 removed the ConfigurationOverrides and GlobalConfigurationOverrides classes in the Spring module. These classes contained older set() calls in order to override Cache configurations and given the way that programmatic Configuration currently works in Infinispan, that approach is not maintainable.
> We hence need a clean way to provide (Global) Configuration beans as a newer, cleaner approach.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (ISPN-3337) Define an approach to allow the injection of Configuration and GlobalConfiguration beans for overriding
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-3337?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec commented on ISPN-3337:
-------------------------------------------
This can be perfectly solved without any code change. Here's an example:
{code}
public class SpringAnnotationConfiguration {
@Configuration
public static class ApplicationConfiguration {
@Bean
public GlobalConfigurationBuilder globalConfigurationBuilder() {
GlobalConfigurationBuilder gcb = new GlobalConfigurationBuilder();
gcb.globalJmxStatistics().allowDuplicateDomains(true);
return gcb;
}
@Bean
public ConfigurationBuilder configurationBuilder() {
ConfigurationBuilder cb = new ConfigurationBuilder();
cb.compatibility().enable();
return cb;
}
@Bean
public SpringEmbeddedCacheManagerFactoryBean springCache(GlobalConfigurationBuilder gcb, ConfigurationBuilder cb) {
SpringEmbeddedCacheManagerFactoryBean factoryBean = new SpringEmbeddedCacheManagerFactoryBean();
factoryBean.addCustomGlobalConfiguration(gcb);
factoryBean.addCustomCacheConfiguration(cb);
return factoryBean;
}
@Bean
public CachePlayground playground() {
return new CachePlayground();
}
}
public static class CachePlayground {
@Autowired
private CacheManager cacheManager;
public void add(String key, String value) {
cacheManager.getCache("default").put(key, value);
}
public String getContent(String key) {
return cacheManager.getCache("default").get(key).get().toString();
}
}
public static void main(String[] args) {
ApplicationContext applicationContext = new AnnotationConfigApplicationContext(ApplicationConfiguration.class);
CachePlayground cachePlayground = applicationContext.getBean(CachePlayground.class);
cachePlayground.add("Infinispan", "Is cool!");
System.out.println(cachePlayground.getContent("Infinispan"));
//validate if configuration has been set
SpringEmbeddedCacheManager springCacheManager = applicationContext.getBean(SpringEmbeddedCacheManager.class);
AdvancedCache<?, ?> ac = (AdvancedCache<?, ?>) springCacheManager.getCache("default").getNativeCache();
System.out.println("Compatibility: " + ac.getCacheConfiguration().compatibility().enabled());
}
}
{code}
The example above shows that it's possible to create both {{GlobalConfigurationBuilder}} and {{ConfigurationBuilder}} separately and put them into {{SpringEmbeddedCacheManagerFactoryBean}}. There's also other approach which gives you even more flexibility - you might ignore {{SpringEmbeddedCacheManagerFactoryBean}} and create {{SpringEmbeddedCacheManager}} by your own using an {{EmbeddedCacheManager}}.
> Define an approach to allow the injection of Configuration and GlobalConfiguration beans for overriding
> -------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3337
> URL: https://issues.jboss.org/browse/ISPN-3337
> Project: Infinispan
> Issue Type: Feature Request
> Components: Spring Integration
> Reporter: Navin Surtani
> Assignee: Sebastian Łaskawiec
>
> ISPN-3279 removed the ConfigurationOverrides and GlobalConfigurationOverrides classes in the Spring module. These classes contained older set() calls in order to override Cache configurations and given the way that programmatic Configuration currently works in Infinispan, that approach is not maintainable.
> We hence need a clean way to provide (Global) Configuration beans as a newer, cleaner approach.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months
[JBoss JIRA] (ISPN-7066) Caches assume persistence configuration from default cache
by Vladimir Dzhuvinov (JIRA)
[ https://issues.jboss.org/browse/ISPN-7066?page=com.atlassian.jira.plugin.... ]
Vladimir Dzhuvinov commented on ISPN-7066:
------------------------------------------
Thanks, this is good to know :) I'll double check our config to make sure we don't inherit other unexpected stuff from the default cache. I would personally vote for having this removed at some point in future.
> Caches assume persistence configuration from default cache
> ----------------------------------------------------------
>
> Key: ISPN-7066
> URL: https://issues.jboss.org/browse/ISPN-7066
> Project: Infinispan
> Issue Type: Bug
> Components: Configuration
> Affects Versions: 8.2.3.Final, 8.2.4.Final
> Reporter: Vladimir Dzhuvinov
>
> Hi guys,
> We noticed a weird behaviour of the Infinispan config where caches that are configured with no persistence assume the persistence configuration of the default cache for the cache container. This can potentially lead to some serious errors as data put into the other caches is getting written into the store of the default cache.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 2 months