[JBoss JIRA] (ISPN-2575) KeyTransformer registration is required on all nodes of the cluster, in case of custom keys
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2575?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2575:
--------------------------------
Assignee: Adrian Nistor (was: Sanne Grinovero)
> KeyTransformer registration is required on all nodes of the cluster, in case of custom keys
> -------------------------------------------------------------------------------------------
>
> Key: ISPN-2575
> URL: https://issues.jboss.org/browse/ISPN-2575
> Project: Infinispan
> Issue Type: Enhancement
> Components: Querying
> Affects Versions: 5.2.0.Beta5
> Reporter: Anna Manukyan
> Assignee: Adrian Nistor
> Attachments: ClusteredCacheTest.java
>
>
> The case is the following:
> I have a clustered cache on which I want to perform a search. I'm doing the following:
> I'm initializing SearchManager on node1, I'm registering a custom key transformer for my key using the created searchmanager, but then when I'm trying to put data into the cache on node1 (which is in REPL_SYNC mode with cache on node2), I'm getting the exception:
> java.lang.IllegalArgumentException: Indexing only works with entries keyed on Strings, primitives and classes that have the @Transformable annotation - you passed in a class org.infinispan.query.test.CustomKey3. Alternatively, see org.infinispan.query.SearchManager#registerKeyTransformer
> When I'm initializing the SearchManager using node2 cache and register the keyTransformer on it as well, then everything works perfectly, even though I am not using the second created SearchManager.
> The test which reproduces the issue is attached to the jira. Please see the test case: testSearchKeyTransformer()
--
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
4 days, 22 hours
[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)
9 years
[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)
9 years
[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)
9 years
[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)
9 years
[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)
9 years
[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)
9 years
[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)
9 years