[JBoss JIRA] (ISPN-8396) Add interceptor preventing going out of memory
by Sebastian Łaskawiec (JIRA)
[ https://issues.jboss.org/browse/ISPN-8396?page=com.atlassian.jira.plugin.... ]
Sebastian Łaskawiec commented on ISPN-8396:
-------------------------------------------
[~william.burns]
{quote}
Sorry why are transactional caches an issue?
{quote}
Sorry, my mistake... you mentioned that will *might not* work correctly in non-tx caches. So if the user configured this type of eviction and a non-tx cache, maybe we should emit a warning - "MEMORY-EXCEPTION was designed to work with transactional caches. Data loss might occur in case of OOM".. or something like that..
> 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, 1 month
[JBoss JIRA] (ISPN-8396) Add interceptor preventing going out of memory
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-8396?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-8396:
------------------------------------
[~william.burns] I was thinking of implementing this at the data container level, but transactions would indeed be a problem in that case: the data container only sees the write during commit, when it's too late to throw an exception. Using an interceptor we can make the prepare command reserve the memory, and the only downside is some extra failures when the container is at the limit and concurrent prepares processed in a different order on each owner make each other fail.
WRT functional commands, you can know how big the value is, you just have to check it after {{command.perform()}} wrote the new value in the context.
The only problem I see is that each node decides what values to write independently, which means not all owners will see the same value. So maybe we should only allow MEMORY-EXCEPTION for transactional caches :)
> 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, 1 month
[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 commented on ISPN-8396:
-------------------------------------
Also while working on this I can estimate how large most objects are. But things like functional commands and other lambda based operations I can't know how large the value is.Thus I am not sure what count we want to put for a value that we can't calculate.
There are a few things I can think of:
# Add this to config, but that seems a bit burdensome.
# We could just use a hardcoded value, but that isn't very good either.
# Try to take an average of values seen before? Not sure if this is possible or not.
> 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, 1 month
[JBoss JIRA] (ISPN-5188) Indexing of JSON values
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-5188?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes resolved ISPN-5188.
-------------------------------------
Fix Version/s: 9.2.0.Beta1
Resolution: Out of Date
This is possible with 9.2.0.Beta1 by having an indexed cache in the server, sending documents with "Content-Type: json" will convert them on-the-fly to protobuf and they'll be indexed.
On top of that query via rest endpoint has also been implemented.
> Indexing of JSON values
> -----------------------
>
> Key: ISPN-5188
> URL: https://issues.jboss.org/browse/ISPN-5188
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote Protocols, Remote Querying
> Reporter: Tristan Tarrant
> Assignee: Gustavo Fernandes
> Fix For: 9.2.0.Beta1
>
>
> Introduce a JSON marshaller so that JSON values can be indexed and queried using the ProtoBuf schemas.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (ISPN-5188) Indexing of JSON values
by Gustavo Fernandes (JIRA)
[ https://issues.jboss.org/browse/ISPN-5188?page=com.atlassian.jira.plugin.... ]
Gustavo Fernandes edited comment on ISPN-5188 at 11/13/17 1:17 PM:
-------------------------------------------------------------------
This is possible with 9.2.0.Beta1 by having an indexed cache in the server, and sending documents with "Content-Type: application/json" will convert them on-the-fly to protobuf and they'll be indexed.
On top of that query via rest endpoint has also been implemented.
was (Author: gustavonalle):
This is possible with 9.2.0.Beta1 by having an indexed cache in the server, sending documents with "Content-Type: json" will convert them on-the-fly to protobuf and they'll be indexed.
On top of that query via rest endpoint has also been implemented.
> Indexing of JSON values
> -----------------------
>
> Key: ISPN-5188
> URL: https://issues.jboss.org/browse/ISPN-5188
> Project: Infinispan
> Issue Type: Feature Request
> Components: Remote Protocols, Remote Querying
> Reporter: Tristan Tarrant
> Assignee: Gustavo Fernandes
> Fix For: 9.2.0.Beta1
>
>
> Introduce a JSON marshaller so that JSON values can be indexed and queried using the ProtoBuf schemas.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (ISPN-8530) Default value of "merge-policy" xsd attribute has an unstable name like org.infinispan.conflict.MergePolicies$$Lambda$72/520956294
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-8530?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-8530:
------------------------------------
The default value from XSD is only for the editor's information, the parser doesn't use it.
Since the parser uses {{Parser.MergePolicy.toString()}} first, and only tries to parse the attribute value as a class name if it's not one of the enum values, we should make {{MergePolicies}} constants reference {{Parser.MergePolicy}} values in their {{toString()}} implementation. Or maybe merge the two...
> Default value of "merge-policy" xsd attribute has an unstable name like org.infinispan.conflict.MergePolicies$$Lambda$72/520956294
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-8530
> URL: https://issues.jboss.org/browse/ISPN-8530
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.1.0.Final
> Reporter: Adrian Nistor
> Assignee: Ryan Emerson
> Fix For: 9.2.0.Final
>
>
> A different lambda name gets generated during each build.
> So an xsd created and deployed to http://docs.jboss.org/infinispan/schemas/ becomes out of sync after next build. We can fix that by redeploying the schema but we cannot assume users will always re-fetch it.
> Using static inner classes (non-anonymous) would be preferable in this case even though the lambda code looks nicer. This solution maintains backward compat with 9.1 too.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month
[JBoss JIRA] (ISPN-8530) Default value of "merge-policy" xsd attribute has an unstable name like org.infinispan.conflict.MergePolicies$$Lambda$72/520956294
by Adrian Nistor (JIRA)
[ https://issues.jboss.org/browse/ISPN-8530?page=com.atlassian.jira.plugin.... ]
Adrian Nistor updated ISPN-8530:
--------------------------------
Summary: Default value of "merge-policy" xsd attribute has an unstable name like org.infinispan.conflict.MergePolicies$$Lambda$72/520956294 (was: Default value of "merge-policy" attroibute is xsd has an unstable name like org.infinispan.conflict.MergePolicies$$Lambda$72/520956294)
> Default value of "merge-policy" xsd attribute has an unstable name like org.infinispan.conflict.MergePolicies$$Lambda$72/520956294
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-8530
> URL: https://issues.jboss.org/browse/ISPN-8530
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 9.1.0.Final
> Reporter: Adrian Nistor
> Assignee: Ryan Emerson
> Fix For: 9.2.0.Final
>
>
> A different lambda name gets generated during each build.
> So an xsd created and deployed to http://docs.jboss.org/infinispan/schemas/ becomes out of sync after next build. We can fix that by redeploying the schema but we cannot assume users will always re-fetch it.
> Using static inner classes (non-anonymous) would be preferable in this case even though the lambda code looks nicer. This solution maintains backward compat with 9.1 too.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 1 month