[JBoss JIRA] (ISPN-11024) Unable to use binary memory eviction with protobuf
by Tristan Tarrant (Jira)
[ https://issues.redhat.com/browse/ISPN-11024?page=com.atlassian.jira.plugi... ]
Tristan Tarrant updated ISPN-11024:
-----------------------------------
Fix Version/s: 11.0.5.Final
(was: 11.0.4.Final)
> Unable to use binary memory eviction with protobuf
> --------------------------------------------------
>
> Key: ISPN-11024
> URL: https://issues.redhat.com/browse/ISPN-11024
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 10.0.1.Final
> Reporter: Jens Reimann
> Assignee: Will Burns
> Priority: Critical
> Fix For: 11.0.5.Final
>
>
> Enabling binary eviction, e.g.:
> {code:xml}
> <memory>
> <binary strategy="REMOVE" size="134217728" eviction="MEMORY"/>
> </memory>
> {code}
> When storing protobuf based types, throws the following exception:
> {code}
> 15:36:29,859 ERROR [org.infinispan.interceptors.impl.InvocationContextInterceptor] (async-thread--p2-t18) ISPN000136: Error executing command PrepareCommand on Cache 'devices', writing keys []: java.lang.IllegalArgumentException: Size of Class class org.infinispan.query.remote.impl.indexing.ProtobufValueWrapper cannot be determined using given entry size calculator :class org.infinispan.container.entries.PrimitiveEntrySizeCalculator
> {code}
> As protobuf produces a binary representation of the data, it is possible to calculate a size for that object.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 7 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.5.Final
(was: 11.0.4.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.5.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)
3 years, 7 months
[JBoss JIRA] (ISPN-12222) Infinispan Backup Operator Integration
by Ryan Emerson (Jira)
[ https://issues.redhat.com/browse/ISPN-12222?page=com.atlassian.jira.plugi... ]
Ryan Emerson updated ISPN-12222:
--------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/infinispan/infinispan-operator/pull/596
> Infinispan Backup Operator Integration
> --------------------------------------
>
> Key: ISPN-12222
> URL: https://issues.redhat.com/browse/ISPN-12222
> Project: Infinispan
> Issue Type: Enhancement
> Components: Operator
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
>
> In kubernetes environments the operator can be used to automate the steps required by a user to perform a backup of container content.
> Typically an Infinispan pod will have a minimal volume size in order to prevent excessive resource allocation, say 1GB. However, if a cluster is large then it's very likely that it's in-memory content will exceed this amount. Therefore, during a cluster backup it's necessary to mount a volume with sufficient capacity to accomodate the created backup file. To automate this process we should create a backup CRD.
> h3. Workflow
> The operator provisions an additional pod with a mounted volume for storing the final backup. This pod joins the Infinispan cluster with {{zero-capacity-node=true}} so that no state-transfer is performed when joining. The operator then initiates the backup procedure on this node, via this node's REST endpoint, using the path of the mounted volume as the backups final destination. On completion, the pod of the zero-capacity-node is terminated.
> h4. Restore
> The same workflow can be used for restoring a backup from an existing volume.
> h3. CR Parameters:
> * Backup path
> * Resources to include
> * Existing volume to mount
> * Create volume with x capacity, x could be automatically determined by inspecting the container content
> * Shutdown cluster on completion?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 7 months
[JBoss JIRA] (ISPN-12222) Infinispan Backup Operator Integration
by Ryan Emerson (Jira)
[ https://issues.redhat.com/browse/ISPN-12222?page=com.atlassian.jira.plugi... ]
Ryan Emerson updated ISPN-12222:
--------------------------------
Status: Open (was: New)
> Infinispan Backup Operator Integration
> --------------------------------------
>
> Key: ISPN-12222
> URL: https://issues.redhat.com/browse/ISPN-12222
> Project: Infinispan
> Issue Type: Enhancement
> Components: Operator
> Reporter: Ryan Emerson
> Assignee: Ryan Emerson
> Priority: Major
>
> In kubernetes environments the operator can be used to automate the steps required by a user to perform a backup of container content.
> Typically an Infinispan pod will have a minimal volume size in order to prevent excessive resource allocation, say 1GB. However, if a cluster is large then it's very likely that it's in-memory content will exceed this amount. Therefore, during a cluster backup it's necessary to mount a volume with sufficient capacity to accomodate the created backup file. To automate this process we should create a backup CRD.
> h3. Workflow
> The operator provisions an additional pod with a mounted volume for storing the final backup. This pod joins the Infinispan cluster with {{zero-capacity-node=true}} so that no state-transfer is performed when joining. The operator then initiates the backup procedure on this node, via this node's REST endpoint, using the path of the mounted volume as the backups final destination. On completion, the pod of the zero-capacity-node is terminated.
> h4. Restore
> The same workflow can be used for restoring a backup from an existing volume.
> h3. CR Parameters:
> * Backup path
> * Resources to include
> * Existing volume to mount
> * Create volume with x capacity, x could be automatically determined by inspecting the container content
> * Shutdown cluster on completion?
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
3 years, 7 months