[JBoss JIRA] (ISPN-10685) File stores locations do not respect the Global State persistent location
by Ryan Emerson (Jira)
[ https://issues.jboss.org/browse/ISPN-10685?page=com.atlassian.jira.plugin... ]
Ryan Emerson resolved ISPN-10685.
---------------------------------
Resolution: Done
> File stores locations do not respect the Global State persistent location
> --------------------------------------------------------------------------
>
> Key: ISPN-10685
> URL: https://issues.jboss.org/browse/ISPN-10685
> Project: Infinispan
> Issue Type: Bug
> Components: Loaders and Stores
> Affects Versions: 10.0.0.CR2
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Priority: Major
> Fix For: 10.0.0.CR3
>
>
> The file stores (Single, SoftIndex, RocksDB) should create files relative to the GlobalState persistent location unless specified.
> Additionally each of the file stores differs in the filesystem layout:
> * The SoftIndex store does not use the name of the cache in the file path, preventing sharing of directories between multiple caches.
> * The RocksDB store allows configuring data and expired locations to point to the same directory, which will result in data corruption
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ISPN-10669) MurmurHash3 should have a special case for WrappedBytes
by Nistor Adrian (Jira)
[ https://issues.jboss.org/browse/ISPN-10669?page=com.atlassian.jira.plugin... ]
Nistor Adrian commented on ISPN-10669:
--------------------------------------
True, but I would still fix it for the general case if possible. Current code works but in a non-obvious way with great potential for generating confusion.
> MurmurHash3 should have a special case for WrappedBytes
> -------------------------------------------------------
>
> Key: ISPN-10669
> URL: https://issues.jboss.org/browse/ISPN-10669
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 10.0.0.CR2
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 10.0.0.CR3
>
>
> {{MurmurHash3.hashCode(Object)}} has a special case for {{WrappedBytesArray}}, but not for other implementations of {{WrappedBytes}} like {{ProtobufValueWrapper}}.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (IPROTO-119) Introduce a customizable TypeId mapper to support changing type ids (and names) for schema evolution
by Nistor Adrian (Jira)
[ https://issues.jboss.org/browse/IPROTO-119?page=com.atlassian.jira.plugin... ]
Nistor Adrian commented on IPROTO-119:
--------------------------------------
This is fixed now, but I have second thoughts about it. Since we do not maintain any state in the WrappedMessageTypeMapper callback we cannot know if we are invoked by an old client that needs TypeId translation or not. Also, we need to introduce an option to discard the TypeId. A possible solution would be to return a negative value from WrappedMessageTypeMapper.mapTypeId. I also have second thought about WrappedMessageTypeMapper.mapTypeName. Type names should never change during schema evolution. We could allow that for more flexibility, but I'd rather remove that and keep things as simple as possible.
> Introduce a customizable TypeId mapper to support changing type ids (and names) for schema evolution
> ----------------------------------------------------------------------------------------------------
>
> Key: IPROTO-119
> URL: https://issues.jboss.org/browse/IPROTO-119
> Project: Infinispan ProtoStream
> Issue Type: Enhancement
> Reporter: Nistor Adrian
> Assignee: Nistor Adrian
> Priority: Major
> Fix For: 4.3.0.Alpha13
>
>
> This should be a simple interface for mapping type ids in and out. Should be specified in Configuration
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ISPN-10657) Handle async-xsite in parallel
by Pedro Ruivo (Jira)
[ https://issues.jboss.org/browse/ISPN-10657?page=com.atlassian.jira.plugin... ]
Pedro Ruivo updated ISPN-10657:
-------------------------------
Fix Version/s: 10.0.0.CR3
9.4.17.Final
> Handle async-xsite in parallel
> ------------------------------
>
> Key: ISPN-10657
> URL: https://issues.jboss.org/browse/ISPN-10657
> Project: Infinispan
> Issue Type: Enhancement
> Components: Cross-Site Replication
> Affects Versions: 10.0.0.CR2
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Priority: Major
> Fix For: 10.0.0.CR3, 9.4.17.Final
>
>
> Asynchronous cross-site replication relies on the ordering of the write operation to ensure data consistency. This ordering is provided by JGroups; it only delivers the next request after the first one is completed.
> This order contains updates for multiple caches and keys. What is proposed here is to handle different keys/cache updates in parallel.
> It should improve the response time, however, there is no free lunch. The following is expected:
> * An increase of CPU utilization: it may spawn new threads to handle different keys update in parallel
> * An increase in memory: it chains the updates (queue)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ISPN-10657) Handle async-xsite in parallel
by Pedro Ruivo (Jira)
[ https://issues.jboss.org/browse/ISPN-10657?page=com.atlassian.jira.plugin... ]
Pedro Ruivo updated ISPN-10657:
-------------------------------
Status: Pull Request Sent (was: Coding In Progress)
Git Pull Request: https://github.com/infinispan/infinispan/pull/7379
> Handle async-xsite in parallel
> ------------------------------
>
> Key: ISPN-10657
> URL: https://issues.jboss.org/browse/ISPN-10657
> Project: Infinispan
> Issue Type: Enhancement
> Components: Cross-Site Replication
> Affects Versions: 10.0.0.CR2
> Reporter: Pedro Ruivo
> Assignee: Pedro Ruivo
> Priority: Major
> Fix For: 10.0.0.CR3, 9.4.17.Final
>
>
> Asynchronous cross-site replication relies on the ordering of the write operation to ensure data consistency. This ordering is provided by JGroups; it only delivers the next request after the first one is completed.
> This order contains updates for multiple caches and keys. What is proposed here is to handle different keys/cache updates in parallel.
> It should improve the response time, however, there is no free lunch. The following is expected:
> * An increase of CPU utilization: it may spawn new threads to handle different keys update in parallel
> * An increase in memory: it chains the updates (queue)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ISPN-10697) Expiration reaper should be able to handle a huge number of expired entries
by Wolf-Dieter Fink (Jira)
[ https://issues.jboss.org/browse/ISPN-10697?page=com.atlassian.jira.plugin... ]
Wolf-Dieter Fink updated ISPN-10697:
------------------------------------
Security: (was: Red Hat Internal)
> Expiration reaper should be able to handle a huge number of expired entries
> ---------------------------------------------------------------------------
>
> Key: ISPN-10697
> URL: https://issues.jboss.org/browse/ISPN-10697
> Project: Infinispan
> Issue Type: Enhancement
> Affects Versions: 10.0.0.CR2
> Reporter: Wolf-Dieter Fink
> Assignee: Will Burns
> Priority: Critical
>
> A use case where a huge number of entries are added and expire in a short period the reaper is not able to handle that and will have increasing backlog which cause OOM error.
> The TRACE messages within the logfiles are
> TRACE [org.infinispan.expiration.impl.ClusterExpirationManager] (pool-9-thread-1) Purging data container of expired entries
> TRACE [org.infinispan.expiration.impl.ClusterExpirationManager] (pool-9-thread-1) Submitting expiration removal for key WrappedByteArray{...} which had lifespan of 480000
> ..... 1,900,000 more
> TRACE [org.infinispan.expiration.impl.ClusterExpirationManager] (pool-9-thread-1) Purging data container completed in 15.45 minutes
> As shown the reaper run for >15 minutes but the lifespan is set to 480sec==8min so there is a massive overlap and the reaper is not able to delete the entries fast enough from the cache
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ISPN-10697) Expiration reaper should be able to handle a huge number of expired entries
by Wolf-Dieter Fink (Jira)
[ https://issues.jboss.org/browse/ISPN-10697?page=com.atlassian.jira.plugin... ]
Wolf-Dieter Fink updated ISPN-10697:
------------------------------------
Priority: Major (was: Critical)
> Expiration reaper should be able to handle a huge number of expired entries
> ---------------------------------------------------------------------------
>
> Key: ISPN-10697
> URL: https://issues.jboss.org/browse/ISPN-10697
> Project: Infinispan
> Issue Type: Enhancement
> Affects Versions: 10.0.0.CR2
> Reporter: Wolf-Dieter Fink
> Assignee: Will Burns
> Priority: Major
>
> A use case where a huge number of entries are added and expire in a short period the reaper is not able to handle that and will have increasing backlog which cause OOM error.
> The TRACE messages within the logfiles are
> TRACE [org.infinispan.expiration.impl.ClusterExpirationManager] (pool-9-thread-1) Purging data container of expired entries
> TRACE [org.infinispan.expiration.impl.ClusterExpirationManager] (pool-9-thread-1) Submitting expiration removal for key WrappedByteArray{...} which had lifespan of 480000
> ..... 1,900,000 more
> TRACE [org.infinispan.expiration.impl.ClusterExpirationManager] (pool-9-thread-1) Purging data container completed in 15.45 minutes
> As shown the reaper run for >15 minutes but the lifespan is set to 480sec==8min so there is a massive overlap and the reaper is not able to delete the entries fast enough from the cache
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ISPN-10379) JCache tck-runner test failures are ignored in Jenkins
by Dan Berindei (Jira)
[ https://issues.jboss.org/browse/ISPN-10379?page=com.atlassian.jira.plugin... ]
Dan Berindei updated ISPN-10379:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan/pull/7378
> JCache tck-runner test failures are ignored in Jenkins
> ------------------------------------------------------
>
> Key: ISPN-10379
> URL: https://issues.jboss.org/browse/ISPN-10379
> Project: Infinispan
> Issue Type: Bug
> Components: Build, Test Suite - Core
> Affects Versions: 10.0.0.Beta3
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Labels: testsuite_stability
> Fix For: 10.0.0.CR3
>
>
> This build has 0 failures in Jenkins, but the console log says otherwise:
> https://ci.infinispan.org/job/Infinispan/job/PR-7110/1/
> {noformat}
> [2019-07-02T18:45:17.550Z] 18:45:16.738 [INFO] --- maven-failsafe-plugin:3.0.0-M3:integration-test (tck-embedded) @ infinispan-jcache-tck-runner ---
> [2019-07-02T18:45:17.550Z] 18:45:16.750 [INFO] Failsafe report directory: /home/infinispan/workspace/Infinispan_PR-7110/jcache/tck-runner/target/failsafe-reports-embedded
> ...
> [2019-07-02T18:45:53.348Z] 18:45:53.137 [ERROR] CacheExpiryTest.invokeAllReadThroughEnabledGetOnNonExistentEntry:1202
> [2019-07-02T18:45:53.348Z] Expected: is <0>
> [2019-07-02T18:45:53.348Z] but: was <5>
> [2019-07-02T18:45:53.348Z] 18:45:53.137 [ERROR] CacheExpiryTest.invokeGetValueWithReadThroughForNonExistentEntryShouldCallGetExpiryForCreatedEntry:1110
> [2019-07-02T18:45:53.348Z] Expected: is <0>
> [2019-07-02T18:45:53.348Z] but: was <1>
> [2019-07-02T18:45:53.348Z] 18:45:53.138 [ERROR] CacheWriterTest.shouldWriteThoughUsingPutAll_partialSuccess:688 expected:<2> but was:<3>
> [2019-07-02T18:45:53.348Z] 18:45:53.138 [INFO]
> [2019-07-02T18:45:53.348Z] 18:45:53.138 [ERROR] Tests run: 491, Failures: 3, Errors: 0, Skipped: 0
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years