August 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-9457) Async caches should provide a way to track replication time stats

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-9457: ------------------------------------- Summary: Async caches should provide a way to track replication time stats Key: ISPN-9457 URL: https://issues.jboss.org/browse/ISPN-9457 Project: Infinispan Issue Type: Enhancement Components: Core Affects Versions: 9.3.1.Final Reporter: Tristan Tarrant Assignee: Pedro Ruivo Async caches should offer the capability of measuring replication time. This would probably involve the receiver sending an ack which would be used for stats accounting. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9456) When underlying store becomes available, the queued modifications are not been written

by Diego Lovison (JIRA)

Diego Lovison created ISPN-9456: ----------------------------------- Summary: When underlying store becomes available, the queued modifications are not been written Key: ISPN-9456 URL: https://issues.jboss.org/browse/ISPN-9456 Project: Infinispan Issue Type: Bug Reporter: Diego Lovison 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.5.0#75005)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9455) When underlying store becomes available, the queued modifications are not been written

by Diego Lovison (JIRA)

Diego Lovison created ISPN-9455: ----------------------------------- Summary: 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 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.5.0#75005)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9453) Document FORCE_WRITE_LOCK not working in non-tx caches

by Don Naro (JIRA)

[ https://issues.jboss.org/browse/ISPN-9453?page=com.atlassian.jira.plugin.... ] Don Naro updated ISPN-9453: --------------------------- Status: Open (was: New) > Document FORCE_WRITE_LOCK not working in non-tx caches > ------------------------------------------------------ > > Key: ISPN-9453 > URL: https://issues.jboss.org/browse/ISPN-9453 > Project: Infinispan > Issue Type: Task > Components: Documentation-Core > Affects Versions: 9.3.1.Final > Reporter: Radim Vansa > Assignee: Don Naro > Fix For: 9.4.0.Final > > > The user guide mentions {{Flag.FORCE_WRITE_LOCK}} in the context of pessimistic transactions but it does not say what this does in non-transactional caches. > In non-tx cache it does not work since when on backup owner, the {{get()}} just reads the value. It does not go to primary to lock there. When on non-owner, it reads from some other owner but not necessarily from the primary. The flag does not force the command to acquire locks remotely. > To put it in other words, it works only scarcely = it does not work. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9377) Enhance JdbcStringBasedStore to support segmentation

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-9377?page=com.atlassian.jira.plugin.... ] Ryan Emerson resolved ISPN-9377. -------------------------------- Fix Version/s: 9.4.0.CR1 (was: 9.4.0.Final) Resolution: Done > Enhance JdbcStringBasedStore to support segmentation > ---------------------------------------------------- > > Key: ISPN-9377 > URL: https://issues.jboss.org/browse/ISPN-9377 > Project: Infinispan > Issue Type: Sub-task > Components: Loaders and Stores > Reporter: William Burns > Assignee: William Burns > Fix For: 9.4.0.CR1 > > > Now with the introduction of segmented store interface, we can convert the RemoteStore to support segmentation. > We should be able to do this by adding a new int column named segment. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (HRJS-67) Support Infinispan 9.4 server

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/HRJS-67?page=com.atlassian.jira.plugin.sy... ] Galder Zamarreño updated HRJS-67: --------------------------------- Fix Version/s: 0.6.0 > Support Infinispan 9.4 server > ----------------------------- > > Key: HRJS-67 > URL: https://issues.jboss.org/browse/HRJS-67 > Project: Infinispan Javascript client > Issue Type: Sub-task > Affects Versions: 0.5.0 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 0.6.0 > > > 9 tests fail with 9.4.0.Beta1: > {code} > org.infinispan.commons.CacheException: java.lang.ClassCastException: > org.infinispan.commons.marshall.WrappedByteArray cannot be cast to java.lang.String > java.lang.ClassCastException: > org.infinispan.commons.marshall.WrappedByteArray cannot be cast to java.lang.String > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9454) Support @GeneratedValue in JpaStore

by Radim Vansa (JIRA)

Radim Vansa created ISPN-9454: --------------------------------- Summary: Support @GeneratedValue in JpaStore Key: ISPN-9454 URL: https://issues.jboss.org/browse/ISPN-9454 Project: Infinispan Issue Type: Enhancement Components: Loaders and Stores Affects Versions: 9.3.1.Final Reporter: Radim Vansa The JpaStore explicitly disallows {{@GeneratedValue}} annotations as this would not work for insertions - key must be known to cache before the value is persisted. However this could work if JpaStore works against existing database and never inserts new entities - only reads/updates/deletes existing ones. In such case we always know the id ahead - we only need a way to detect that the id was not set and fail in that case. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (HRJS-35) Enable clients to pass in String or native JSON objects

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/HRJS-35?page=com.atlassian.jira.plugin.sy... ] Galder Zamarreño updated HRJS-35: --------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/js-client/pull/27 > Enable clients to pass in String or native JSON objects > ------------------------------------------------------- > > Key: HRJS-35 > URL: https://issues.jboss.org/browse/HRJS-35 > Project: Infinispan Javascript client > Issue Type: Enhancement > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 0.6.0 > > > Implement Hot Rod protocol changes to enable JS client to read data from Hot Rod in a particular MIME type, e.g. JSON. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (HRJS-67) Support Infinispan 9.4 server

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/HRJS-67?page=com.atlassian.jira.plugin.sy... ] Galder Zamarreño updated HRJS-67: --------------------------------- Status: Open (was: New) > Support Infinispan 9.4 server > ----------------------------- > > Key: HRJS-67 > URL: https://issues.jboss.org/browse/HRJS-67 > Project: Infinispan Javascript client > Issue Type: Sub-task > Affects Versions: 0.5.0 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > > 9 tests fail with 9.4.0.Beta1: > {code} > org.infinispan.commons.CacheException: java.lang.ClassCastException: > org.infinispan.commons.marshall.WrappedByteArray cannot be cast to java.lang.String > java.lang.ClassCastException: > org.infinispan.commons.marshall.WrappedByteArray cannot be cast to java.lang.String > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (HRJS-67) Support Infinispan 9.4 server

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/HRJS-67?page=com.atlassian.jira.plugin.sy... ] Galder Zamarreño updated HRJS-67: --------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/js-client/pull/27 > Support Infinispan 9.4 server > ----------------------------- > > Key: HRJS-67 > URL: https://issues.jboss.org/browse/HRJS-67 > Project: Infinispan Javascript client > Issue Type: Sub-task > Affects Versions: 0.5.0 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > > 9 tests fail with 9.4.0.Beta1: > {code} > org.infinispan.commons.CacheException: java.lang.ClassCastException: > org.infinispan.commons.marshall.WrappedByteArray cannot be cast to java.lang.String > java.lang.ClassCastException: > org.infinispan.commons.marshall.WrappedByteArray cannot be cast to java.lang.String > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

5 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2018