[JBoss JIRA] (ISPN-12029) Replace Blocking Executor with an EnhancedQueueExecutor
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-12029?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-12029:
-----------------------------------
Fix Version/s: 11.0.2.Final
(was: 11.0.1.Final)
> Replace Blocking Executor with an EnhancedQueueExecutor
> -------------------------------------------------------
>
> Key: ISPN-12029
> URL: https://issues.redhat.com/browse/ISPN-12029
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core
> Reporter: Will Burns
> Assignee: Will Burns
> Priority: Major
> Fix For: 12.0.0.Final, 11.0.2.Final
>
>
> The blocking executor today uses a simple ThreadPoolExecutor. Unfortunately, this means that we will eventually start all configured threads (since core = max and we require a queue). Setting core size to less than max is not desirable as well as it will enqueue additional tasks rather than spawn a thread.
>
> The EnhancedQueueExecutor does exactly what we want and also has some additional features. We should utilize this which will keep our blocking thread pool size down during times of less activity.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 6 months
[JBoss JIRA] (ISPN-12005) Store purge should ignore errors
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-12005?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-12005:
-----------------------------------
Fix Version/s: 11.0.2.Final
(was: 11.0.1.Final)
> Store purge should ignore errors
> --------------------------------
>
> Key: ISPN-12005
> URL: https://issues.redhat.com/browse/ISPN-12005
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Loaders and Stores
> Affects Versions: 10.1.5.Final, 11.0.0.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 12.0.0.Final, 11.0.2.Final
>
>
> Purging of expired entries from stores is a pretty involved process, especially with {{RocksDBStore}}. When there's a problem unmarshalling the expired bucket or deleting an expired key, the purge task bails out immediately, without processing the remaining keys. To make matters worse, the exception it not logged anywhere. The only sign that something is wrong is a growing store (in the case of {{RocksDBStore}}, a growing number of SST files).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 6 months
[JBoss JIRA] (ISPN-11992) Convert RemoteStore to use new SPI
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11992?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11992:
-----------------------------------
Fix Version/s: 11.0.2.Final
(was: 11.0.1.Final)
> Convert RemoteStore to use new SPI
> ----------------------------------
>
> Key: ISPN-11992
> URL: https://issues.redhat.com/browse/ISPN-11992
> Project: Infinispan
> Issue Type: Enhancement
> Components: Loaders and Stores
> Reporter: Will Burns
> Priority: Major
> Fix For: 12.0.0.Final, 11.0.2.Final
>
>
> The RemoteStore already uses a non blocking client. We should convert it to the new SPI to utilize this.
> We also need to add in a check for the old server to see how many segments it has. If the number is different than the current server we need to disable the segmentation characteristic and instead do the costlier iteration.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 6 months
[JBoss JIRA] (ISPN-11981) Stale immortal entry metadata
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11981?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11981:
-----------------------------------
Fix Version/s: 11.0.2.Final
(was: 11.0.1.Final)
> Stale immortal entry metadata
> -----------------------------
>
> Key: ISPN-11981
> URL: https://issues.redhat.com/browse/ISPN-11981
> Project: Infinispan
> Issue Type: Bug
> Components: Core
> Affects Versions: 11.0.0.CR1, 10.1.8.Final
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Priority: Major
> Fix For: 11.0.2.Final
>
>
> When an entry is updated, {{InternalEntryFactoryImpl}} tries to reuse the existing {{InternalCacheEntry}} instance instead of creating a new one. The condition is that both the new and the old entry have the same implementation implementation: immortal, immortal w/ external metadata, transient, transient w/ metadata etc.
> Because {{MetadataImmortalCacheEntry}} extends {{ImmortalCacheEntry}}, that logic is broken: when an immortal entry with external metadata is replaced with a new entry without external metadata, the external metadata is not removed.
> This impacts the anchored keys module, which I am changing to store the key location in the metadata (currently it is stored as a value, and it is broken with BINARY/OFF_HEAP storage). When a node leaves and an entry located on the leaver is updated, the key is written on the newest joiner. The joiner already has a local entry with {{RemoteMetadata}}, and is trying to write a value without any metadata.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
5 years, 6 months