[JBoss JIRA] (ISPN-8396) Add interceptor preventing going out of memory
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-8396?page=com.atlassian.jira.plugin.... ]
William Burns edited comment on ISPN-8396 at 11/13/17 10:30 AM:
----------------------------------------------------------------
So here is my initial thoughts of how to do this in the core, which then could be used further up the stack
We would add a new "eviction" type currently we have (COUNT and MEMORY) - I can't think of a good name, maybe MEMORY-EXCEPTION. This would then add a new interceptor to the stack towards the top that only takes a WrappedBytes and checks the length and the OffHeapMemoryAllocator to see if it can allocate that much memory. If not it would throw an exception. This allows off heap to use the non bounded data container which is substantially faster than the bounded one. The only drawback is this wouldn't work with on heap.
We could add on heap (OBJECT storage would still not be supported), but it would require an additional wrapper around the DefaultDataContainer to count the byte[] coming in and out when using BINARY.
So the only issue I found with this approach is that nodes can vary on whether they think they can insert values or not. So if a node was to write a given entry, a backup might not have room but the primary does. This could cause an issue with the write in nontx mode as it could have been updated on some of the nodes. Maybe we always write if the primary says we should?
was (Author: william.burns):
So here is my initial thoughts of how to do this in the core, which then could be used further up the stack
We would add a new "eviction" type currently we have (COUNT and MEMORY) - I can't think of a good name, maybe MEMORY-EXCEPTION. This would then not actually add a new interceptor to the stack towards the top that only takes a WrappedBytes and checks the length and the OffHeapMemoryAllocator to see if it can allocate that much memory. If not it would throw an exception. This allows off heap to use the non bounded data container which is substantially faster than the bounded one. The only drawback is this wouldn't work with on heap.
We could add on heap (OBJECT storage would still not be supported), but it would require an additional wrapper around the DefaultDataContainer to count the byte[] coming in and out when using BINARY.
So the only issue I found with this approach is that nodes can vary on whether they think they can insert values or not. So if a node was to write a given entry, a backup might not have room but the primary does. This could cause an issue with the write in nontx mode as it could have been updated on some of the nodes. Maybe we always write if the primary says we should?
> Add interceptor preventing going out of memory
> ----------------------------------------------
>
> Key: ISPN-8396
> URL: https://issues.jboss.org/browse/ISPN-8396
> Project: Infinispan
> Issue Type: Feature Request
> Components: Cloud Integrations, Core
> Reporter: Sebastian Łaskawiec
> Assignee: William Burns
>
> We need an interceptor which will calculate the amount of required memory for PUT and report an error if that put will cause going out of memory.
> Note that this is strictly connected to eviction mechanism (we might want to evict some entries on write)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[JBoss JIRA] (ISPN-8529) REST Cache create and remove
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-8529?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-8529:
----------------------------------
Description:
Implement cache creation/removal over HTTP.
Since WebDAV (RFC-4918) describes operations over "collections", we can reuse the semantics of invocations and error messages. In particular:
https://tools.ietf.org/html/rfc4918#section-9.3
https://tools.ietf.org/html/rfc4918#section-9.6.1
Cache creation:
*MKCOL /{cacheName}[?template={template}]*
This will create the named cache, using the optionally supplied template name for configuration. If a template is not specified, then the configuration of the default cache defined on the cache container will be used.
Cache removal
*DELETE /[cacheName]*
This method's behaviour is affected by the presence and value of the `Depth` header.
The header can have the following values:
* infinity,noroot: deletes the contents of the cache. This is the default behaviour (for backwards compatibility this does not respect the behaviour described in link:https://tools.ietf.org/html/rfc4918#section-9.6.1[WebDAV RFC] regarding removal of collections). If successful this operation returns a status of 200.
* infinity: removes the cache from the system. If security is enabled, you will need ADMIN permissions. If successful, this operation returns a status of 204 (No Content). This method also understands <<rest:adminflags>>
was:
Implement cache creation/removal over HTTP.
Since WebDAV (RFC-4918) describes operations over "collections", we can reuse the semantics of invocations and error messages. In particular:
https://tools.ietf.org/html/rfc4918#section-9.3
https://tools.ietf.org/html/rfc4918#section-9.6.1
Cache creation:
{{MKCOL /{cacheName}[?template={template}]}}
This will create the named cache, using the optionally supplied template name for configuration. If a template is not specified, then the configuration of the default cache defined on the cache container will be used.
Cache removal
{{DELETE /[cacheName] }}
This method's behaviour is affected by the presence and value of the `Depth` header.
The header can have the following values:
* infinity,noroot: deletes the contents of the cache. This is the default behaviour (for backwards compatibility this does not respect the behaviour described in link:https://tools.ietf.org/html/rfc4918#section-9.6.1[WebDAV RFC] regarding removal of collections). If successful this operation returns a status of 200.
* infinity: removes the cache from the system. If security is enabled, you will need ADMIN permissions. If successful, this operation returns a status of 204 (No Content). This method also understands <<rest:adminflags>>
> REST Cache create and remove
> ----------------------------
>
> Key: ISPN-8529
> URL: https://issues.jboss.org/browse/ISPN-8529
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote Protocols, Server
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 9.2.0.Final
>
>
> Implement cache creation/removal over HTTP.
> Since WebDAV (RFC-4918) describes operations over "collections", we can reuse the semantics of invocations and error messages. In particular:
> https://tools.ietf.org/html/rfc4918#section-9.3
> https://tools.ietf.org/html/rfc4918#section-9.6.1
> Cache creation:
> *MKCOL /{cacheName}[?template={template}]*
> This will create the named cache, using the optionally supplied template name for configuration. If a template is not specified, then the configuration of the default cache defined on the cache container will be used.
> Cache removal
> *DELETE /[cacheName]*
> This method's behaviour is affected by the presence and value of the `Depth` header.
> The header can have the following values:
> * infinity,noroot: deletes the contents of the cache. This is the default behaviour (for backwards compatibility this does not respect the behaviour described in link:https://tools.ietf.org/html/rfc4918#section-9.6.1[WebDAV RFC] regarding removal of collections). If successful this operation returns a status of 200.
> * infinity: removes the cache from the system. If security is enabled, you will need ADMIN permissions. If successful, this operation returns a status of 204 (No Content). This method also understands <<rest:adminflags>>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years
[JBoss JIRA] (ISPN-8529) REST Cache create and remove
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-8529?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-8529:
----------------------------------
Description:
Implement cache creation/removal over HTTP.
Since WebDAV (RFC-4918) describes operations over "collections", we can reuse the semantics of invocations and error messages. In particular:
https://tools.ietf.org/html/rfc4918#section-9.3
https://tools.ietf.org/html/rfc4918#section-9.6.1
Cache creation:
{{MKCOL /{cacheName}[?template={template}]}}
This will create the named cache, using the optionally supplied template name for configuration. If a template is not specified, then the configuration of the default cache defined on the cache container will be used.
Cache removal
{{DELETE /[cacheName] }}
This method's behaviour is affected by the presence and value of the `Depth` header.
The header can have the following values:
* infinity,noroot: deletes the contents of the cache. This is the default behaviour (for backwards compatibility this does not respect the behaviour described in link:https://tools.ietf.org/html/rfc4918#section-9.6.1[WebDAV RFC] regarding removal of collections). If successful this operation returns a status of 200.
* infinity: removes the cache from the system. If security is enabled, you will need ADMIN permissions. If successful, this operation returns a status of 204 (No Content). This method also understands <<rest:adminflags>>
was:
Implement cache creation/removal over HTTP.
Since WebDAV (RFC-4918) describes operations over "collections", we can reuse the semantics of invocations and error messages. In particular:
https://tools.ietf.org/html/rfc4918#section-9.3
https://tools.ietf.org/html/rfc4918#section-9.6.1
Cache creation:
`MKCOL /{cacheName}[?template={template}]`
This will create the named cache, using the optionally supplied template name for configuration. If a template is not specified, then the configuration of the default cache defined on the cache container will be used.
Cache removal
`DELETE /{cacheName}`
This method's behaviour is affected by the presence and value of the `Depth` header.
The header can have the following values:
* infinity,noroot: deletes the contents of the cache. This is the default behaviour (for backwards compatibility this does not respect the behaviour described in link:https://tools.ietf.org/html/rfc4918#section-9.6.1[WebDAV RFC] regarding removal of collections). If successful this operation returns a status of 200.
* infinity: removes the cache from the system. If security is enabled, you will need ADMIN permissions. If successful, this operation returns a status of 204 (No Content). This method also understands <<rest:adminflags>>
> REST Cache create and remove
> ----------------------------
>
> Key: ISPN-8529
> URL: https://issues.jboss.org/browse/ISPN-8529
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote Protocols, Server
> Reporter: Tristan Tarrant
> Assignee: Tristan Tarrant
> Fix For: 9.2.0.Final
>
>
> Implement cache creation/removal over HTTP.
> Since WebDAV (RFC-4918) describes operations over "collections", we can reuse the semantics of invocations and error messages. In particular:
> https://tools.ietf.org/html/rfc4918#section-9.3
> https://tools.ietf.org/html/rfc4918#section-9.6.1
> Cache creation:
> {{MKCOL /{cacheName}[?template={template}]}}
> This will create the named cache, using the optionally supplied template name for configuration. If a template is not specified, then the configuration of the default cache defined on the cache container will be used.
> Cache removal
> {{DELETE /[cacheName] }}
> This method's behaviour is affected by the presence and value of the `Depth` header.
> The header can have the following values:
> * infinity,noroot: deletes the contents of the cache. This is the default behaviour (for backwards compatibility this does not respect the behaviour described in link:https://tools.ietf.org/html/rfc4918#section-9.6.1[WebDAV RFC] regarding removal of collections). If successful this operation returns a status of 200.
> * infinity: removes the cache from the system. If security is enabled, you will need ADMIN permissions. If successful, this operation returns a status of 204 (No Content). This method also understands <<rest:adminflags>>
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years