[JBoss JIRA] (ISPN-9455) When underlying store becomes available, the queued modifications are not been written
by Ryan Emerson (Jira)
[ https://issues.jboss.org/browse/ISPN-9455?page=com.atlassian.jira.plugin.... ]
Ryan Emerson commented on ISPN-9455:
------------------------------------
[~dlovison] In your configuration you have `fail-silently=true` which means that the `AsyncCacheWriter` will not wait for the underlying store to become available, instead it just attempts the write `connection-attempts` number of times. If the behaviour you describe occurs with `fail-silently=false`, then this would be an issue.
> When underlying store becomes available, the queued modifications are not been written
> --------------------------------------------------------------------------------------
>
> Key: ISPN-9455
> URL: https://issues.jboss.org/browse/ISPN-9455
> Project: Infinispan
> Issue Type: Bug
> Reporter: Diego Lovison
> Assignee: Ryan Emerson
> Priority: Critical
>
> In order to reproduce this issue, you will need to do the following.
> 1) Start a remote Infinispan server using: ./standalone.sh -c clustered.xml
> 2) Add a breakpoint in AsynCacheWriter line 423. The line is: "retryWork(configuration.connectionAttempts());" into the "run" method
> 3) Run the application
> 4) When the breakpoint stops in AsynCacheWriter::423, kill the remote server and then resume.
> 5) Wait for the message in the log: "ISPN000053: Unable to process some async modifications after 5 retries!"
> 6) After the message, start again the remote server.
> 7) After 120 seconds we will double check in the remote store if the data is available. It will fail. There is no data in the remote store. Based on https://issues.jboss.org/browse/JDG-1051 "Once the underlying store becomes available, the queued modifications should be written and then the cache should become available."
> Application
> {code:java}
> public class ConfigurationJdbcStoreFileCacheExample {
> public static void main(String[] args) throws InterruptedException, IOException, SQLException {
> EmbeddedCacheManager cacheManager = new DefaultCacheManager("cache-store.xml");
> ExecutorService executorService = Executors.newFixedThreadPool(10);
> try {
> Cache<String, String> cache = cacheManager.getCache("myCache");
> List<Future<String>> keys = new ArrayList<>();
> for (int i = 0; i < 10; i++) {
> keys.add(executorService.submit(() -> {
> String key = UUID.randomUUID().toString();
> try {
> cache.put(key, key);
> System.out.println("Done: " + key);
> } catch (Throwable e) {
> e.printStackTrace();
> }
> return key;
> }));
> }
> TimeUnit.SECONDS.sleep(120);
> RemoteCacheManager remoteCacheManager = new RemoteCacheManager(new ConfigurationBuilder()
> .addServer()
> .host("localhost")
> .port(11222)
> .build());
> RemoteCache<String, String> remoteCache =
> remoteCacheManager.administration().getOrCreateCache("default", (String) null);
> keys.forEach(f -> {
> try {
> String key = f.get();
> Assert.assertNotNull(remoteCache.get(key));
> } catch (InterruptedException e) {
> throw new IllegalStateException(e);
> } catch (ExecutionException e) {
> throw new IllegalStateException(e);
> }
> });
> } finally {
> cacheManager.stop();
> executorService.shutdownNow();
> }
> }
> }
> {code}
> Configuration
> {code:xml}
> <?xml version="1.0" ?>
> <infinispan>
> <jgroups>
> <stack-file name="external-file" path="default-jgroups-tcp.xml"/>
> </jgroups>
> <cache-container name="myCacheContainer" default-cache="myCache" statistics="true">
> <transport cluster="WeatherApp" stack="external-file" />
> <distributed-cache owners="2" mode="SYNC" remote-timeout="15000" name="myCache">
> <transaction mode="NONE"/>
> <persistence availability-interval="1000" connection-attempts="5" connection-interval="1000">
> <remote-store cache="default" raw-values="true">
> <remote-server host="localhost" port="11222" />
> <write-behind modification-queue-size="100" thread-pool-size="20" fail-silently="true"/>
> </remote-store>
> </persistence>
> </distributed-cache>
> </cache-container>
> </infinispan>
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (ISPN-9455) When underlying store becomes available, the queued modifications are not been written
by Ryan Emerson (Jira)
[ https://issues.jboss.org/browse/ISPN-9455?page=com.atlassian.jira.plugin.... ]
Ryan Emerson reassigned ISPN-9455:
----------------------------------
Assignee: Ryan Emerson
> When underlying store becomes available, the queued modifications are not been written
> --------------------------------------------------------------------------------------
>
> Key: ISPN-9455
> URL: https://issues.jboss.org/browse/ISPN-9455
> Project: Infinispan
> Issue Type: Bug
> Reporter: Diego Lovison
> Assignee: Ryan Emerson
> Priority: Critical
>
> In order to reproduce this issue, you will need to do the following.
> 1) Start a remote Infinispan server using: ./standalone.sh -c clustered.xml
> 2) Add a breakpoint in AsynCacheWriter line 423. The line is: "retryWork(configuration.connectionAttempts());" into the "run" method
> 3) Run the application
> 4) When the breakpoint stops in AsynCacheWriter::423, kill the remote server and then resume.
> 5) Wait for the message in the log: "ISPN000053: Unable to process some async modifications after 5 retries!"
> 6) After the message, start again the remote server.
> 7) After 120 seconds we will double check in the remote store if the data is available. It will fail. There is no data in the remote store. Based on https://issues.jboss.org/browse/JDG-1051 "Once the underlying store becomes available, the queued modifications should be written and then the cache should become available."
> Application
> {code:java}
> public class ConfigurationJdbcStoreFileCacheExample {
> public static void main(String[] args) throws InterruptedException, IOException, SQLException {
> EmbeddedCacheManager cacheManager = new DefaultCacheManager("cache-store.xml");
> ExecutorService executorService = Executors.newFixedThreadPool(10);
> try {
> Cache<String, String> cache = cacheManager.getCache("myCache");
> List<Future<String>> keys = new ArrayList<>();
> for (int i = 0; i < 10; i++) {
> keys.add(executorService.submit(() -> {
> String key = UUID.randomUUID().toString();
> try {
> cache.put(key, key);
> System.out.println("Done: " + key);
> } catch (Throwable e) {
> e.printStackTrace();
> }
> return key;
> }));
> }
> TimeUnit.SECONDS.sleep(120);
> RemoteCacheManager remoteCacheManager = new RemoteCacheManager(new ConfigurationBuilder()
> .addServer()
> .host("localhost")
> .port(11222)
> .build());
> RemoteCache<String, String> remoteCache =
> remoteCacheManager.administration().getOrCreateCache("default", (String) null);
> keys.forEach(f -> {
> try {
> String key = f.get();
> Assert.assertNotNull(remoteCache.get(key));
> } catch (InterruptedException e) {
> throw new IllegalStateException(e);
> } catch (ExecutionException e) {
> throw new IllegalStateException(e);
> }
> });
> } finally {
> cacheManager.stop();
> executorService.shutdownNow();
> }
> }
> }
> {code}
> Configuration
> {code:xml}
> <?xml version="1.0" ?>
> <infinispan>
> <jgroups>
> <stack-file name="external-file" path="default-jgroups-tcp.xml"/>
> </jgroups>
> <cache-container name="myCacheContainer" default-cache="myCache" statistics="true">
> <transport cluster="WeatherApp" stack="external-file" />
> <distributed-cache owners="2" mode="SYNC" remote-timeout="15000" name="myCache">
> <transaction mode="NONE"/>
> <persistence availability-interval="1000" connection-attempts="5" connection-interval="1000">
> <remote-store cache="default" raw-values="true">
> <remote-server host="localhost" port="11222" />
> <write-behind modification-queue-size="100" thread-pool-size="20" fail-silently="true"/>
> </remote-store>
> </persistence>
> </distributed-cache>
> </cache-container>
> </infinispan>
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (ISPRK-58) Support for different data formats
by Gustavo Fernandes (Jira)
Gustavo Fernandes created ISPRK-58:
--------------------------------------
Summary: Support for different data formats
Key: ISPRK-58
URL: https://issues.jboss.org/browse/ISPRK-58
Project: Infinispan Spark
Issue Type: Feature Request
Components: RDD, SQL, Streaming
Affects Versions: 0.8
Reporter: Gustavo Fernandes
Assignee: Gustavo Fernandes
Fix For: 0.9
Infinispan supports reading/writing to remote caches in different data formats specified by a Media Type. This should be exposed to the Spark connector via configuration.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (ISPN-3918) Inconsistent view of the cache with putIfAbsent in a non-tx cache during state transfer
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-3918?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-3918:
----------------------------------
Fix Version/s: 9.4.1.Final
(was: 9.4.0.Final)
> Inconsistent view of the cache with putIfAbsent in a non-tx cache during state transfer
> ---------------------------------------------------------------------------------------
>
> Key: ISPN-3918
> URL: https://issues.jboss.org/browse/ISPN-3918
> Project: Infinispan
> Issue Type: Bug
> Components: Core, State Transfer
> Affects Versions: 6.0.0.Final
> Reporter: Dan Berindei
> Priority: Major
> Labels: consistency
> Fix For: 9.4.1.Final
>
> Attachments: NonTxPutIfAbsentDuringLeaveStressTest.testNodeLeavingDuringPutIfAbsent_8.log.gz, NonTxPutIfAbsentDuringRebalanceStressTest.testPutIfAbsentDuringJoin_1.log.gz, ntpiadjst.log.gz
>
>
> In a non-tx cache, sometimes it's possible for a {{get(k)}} to return {{null}} even though a previous {{putIfAbsent(k, v)}} returned a non-null value and the only concurrent operations on the cache are concurrent putIfAbsent calls.
> Say \[B, A, C] are the owners of k (C just joined)
> 1. A starts a {{putIfAbsent(k, v1)}} command, sends it to B
> 2. B forwards the command to A and C
> 3. C writes {{k=v1}}
> 4. C becomes the primary owner of k (owners are now \[C, A])
> 5. A/B see the new topology before committing and throw an outdatedTopologyException
> 6. A retries the command, sends it to C
> 7. C forwards the command to A, which writes {{k=v1}}
> 8. C doesn't have to update the entry, returns null
> If, between steps 3 and 7, another thread on A starts a {{putIfAbsent(k, v2)}} command, the command will fail and return {{v1}} (because the primary owner already has a value). However, a subsequent {{get(k)}} command will return {{null}}, because A is an owner and doesn't have the value.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (ISPN-3835) Index Update command is processed before the registry listener is triggered
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-3835?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-3835:
----------------------------------
Fix Version/s: 9.4.1.Final
(was: 9.4.0.Final)
> Index Update command is processed before the registry listener is triggered
> ---------------------------------------------------------------------------
>
> Key: ISPN-3835
> URL: https://issues.jboss.org/browse/ISPN-3835
> Project: Infinispan
> Issue Type: Bug
> Components: Embedded Querying
> Affects Versions: 6.0.0.Final
> Reporter: Sanne Grinovero
> Priority: Critical
> Labels: 64QueryBlockers
> Fix For: 9.4.1.Final
>
>
> When using the InfinispanIndexManager backend the master node might receive an index update command about an index which it hasn't defined yet.
> Index definitions are triggered by the type registry, which in turn is driven by the ClusterRegistry and an event listener on the ClusterRegistry. It looks like slaves are sending update requests before the master has processed the configuration event.
> This leads to index update commands to be lost (with a stacktrace logged)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (ISPN-2575) Key Transformer registration is required on all nodes of the cluster, in case of custom keys
by Tristan Tarrant (Jira)
[ https://issues.jboss.org/browse/ISPN-2575?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-2575:
----------------------------------
Fix Version/s: 9.4.1.Final
(was: 9.4.0.Final)
> Key Transformer 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: Embedded Querying
> Affects Versions: 5.2.0.Beta5
> Reporter: Anna Manukyan
> Assignee: Adrian Nistor
> Priority: Minor
> Fix For: 9.4.1.Final
>
> 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 was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months