November 2017 - infinispan-issues

[JBoss JIRA] (ISPN-8406) Use number of owners provided by the user in Shared Memory Service

by Pedro Zapata (JIRA)

[ https://issues.jboss.org/browse/ISPN-8406?page=com.atlassian.jira.plugin.... ] Pedro Zapata updated ISPN-8406: ------------------------------- Sprint: Sprint #4 Oct 16th - Nov 6th, Sprint #5 Nov 6th - Nov 24th, Sprint #5 Nov 6th - Nov 24th 2 (was: Sprint #4 Oct 16th - Nov 6th, Sprint #5 Nov 6th - Nov 24th) > Use number of owners provided by the user in Shared Memory Service > ------------------------------------------------------------------ > > Key: ISPN-8406 > URL: https://issues.jboss.org/browse/ISPN-8406 > Project: Infinispan > Issue Type: Enhancement > Components: Cloud Integrations > Reporter: Sebastian Łaskawiec > Assignee: Ryan Emerson > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8494) Clear is leaking transaction with Batching

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-8494?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-8494: ------------------------------ Issue Type: Bug (was: Feature Request) > Clear is leaking transaction with Batching > ------------------------------------------ > > Key: ISPN-8494 > URL: https://issues.jboss.org/browse/ISPN-8494 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 9.2.0.Final > > > When batching is enabled, the clear() tries to suspend the running transaction but it ends leaking the internal transaction used in the batch. > {code:java} > public void testClearInBatch() { > Cache<String, String> cache = createCache("testClearInBatch"); > cache.put("k2", "value2"); > cache.startBatch(); > cache.clear(); > cache.put("k1", "value1"); > cache.endBatch(true); > // the tx is leaked and it tries to execute the get() against a committed transaction. > AssertJUnit.assertEquals(null, cache.get("k2")); > AssertJUnit.assertEquals("value1", cache.get("k1")); > } > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8494) Clear is leaking transaction with Batching

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-8494?page=com.atlassian.jira.plugin.... ] Pedro Ruivo commented on ISPN-8494: ----------------------------------- fix notes: * CacheImpl should fetch the batch transaction when clear is invoked * BatchingInterceptor should ignore the clear operation * Test putForExternalRead. it may hit the same issue. > Clear is leaking transaction with Batching > ------------------------------------------ > > Key: ISPN-8494 > URL: https://issues.jboss.org/browse/ISPN-8494 > Project: Infinispan > Issue Type: Feature Request > Components: Transactions > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 9.2.0.Final > > > When batching is enabled, the clear() tries to suspend the running transaction but it ends leaking the internal transaction used in the batch. > {code:java} > public void testClearInBatch() { > Cache<String, String> cache = createCache("testClearInBatch"); > cache.put("k2", "value2"); > cache.startBatch(); > cache.clear(); > cache.put("k1", "value1"); > cache.endBatch(true); > // the tx is leaked and it tries to execute the get() against a committed transaction. > AssertJUnit.assertEquals(null, cache.get("k2")); > AssertJUnit.assertEquals("value1", cache.get("k1")); > } > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8494) Clear is leaking transaction with Batching

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-8494?page=com.atlassian.jira.plugin.... ] Pedro Ruivo edited comment on ISPN-8494 at 11/6/17 6:58 AM: ------------------------------------------------------------ fix notes: * CacheImpl shouldn't fetch the batch transaction when clear is invoked * BatchingInterceptor should ignore the clear operation * Test putForExternalRead. it may hit the same issue. was (Author: pruivo): fix notes: * CacheImpl should fetch the batch transaction when clear is invoked * BatchingInterceptor should ignore the clear operation * Test putForExternalRead. it may hit the same issue. > Clear is leaking transaction with Batching > ------------------------------------------ > > Key: ISPN-8494 > URL: https://issues.jboss.org/browse/ISPN-8494 > Project: Infinispan > Issue Type: Feature Request > Components: Transactions > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 9.2.0.Final > > > When batching is enabled, the clear() tries to suspend the running transaction but it ends leaking the internal transaction used in the batch. > {code:java} > public void testClearInBatch() { > Cache<String, String> cache = createCache("testClearInBatch"); > cache.put("k2", "value2"); > cache.startBatch(); > cache.clear(); > cache.put("k1", "value1"); > cache.endBatch(true); > // the tx is leaked and it tries to execute the get() against a committed transaction. > AssertJUnit.assertEquals(null, cache.get("k2")); > AssertJUnit.assertEquals("value1", cache.get("k1")); > } > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8494) Clear is leaking transaction with Batching

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-8494?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-8494: ------------------------------ Fix Version/s: 9.2.0.Final > Clear is leaking transaction with Batching > ------------------------------------------ > > Key: ISPN-8494 > URL: https://issues.jboss.org/browse/ISPN-8494 > Project: Infinispan > Issue Type: Feature Request > Components: Transactions > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 9.2.0.Final > > > When batching is enabled, the clear() tries to suspend the running transaction but it ends leaking the internal transaction used in the batch. > {code:java} > public void testClearInBatch() { > Cache<String, String> cache = createCache("testClearInBatch"); > cache.put("k2", "value2"); > cache.startBatch(); > cache.clear(); > cache.put("k1", "value1"); > cache.endBatch(true); > // the tx is leaked and it tries to execute the get() against a committed transaction. > AssertJUnit.assertEquals(null, cache.get("k2")); > AssertJUnit.assertEquals("value1", cache.get("k1")); > } > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8494) Clear is leaking transaction with Batching

by Pedro Ruivo (JIRA)

Pedro Ruivo created ISPN-8494: --------------------------------- Summary: Clear is leaking transaction with Batching Key: ISPN-8494 URL: https://issues.jboss.org/browse/ISPN-8494 Project: Infinispan Issue Type: Feature Request Components: Transactions Reporter: Pedro Ruivo Assignee: Pedro Ruivo When batching is enabled, the clear() tries to suspend the running transaction but it ends leaking the internal transaction used in the batch. {code:java} public void testClearInBatch() { Cache<String, String> cache = createCache("testClearInBatch"); cache.put("k2", "value2"); cache.startBatch(); cache.clear(); cache.put("k1", "value1"); cache.endBatch(true); // the tx is leaked and it tries to execute the get() against a committed transaction. AssertJUnit.assertEquals(null, cache.get("k2")); AssertJUnit.assertEquals("value1", cache.get("k1")); } {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8423) Remove metadata size integer in cases where we know the size

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-8423?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8423: ---------------------------------- Fix Version/s: (was: 9.1.3.Final) > Remove metadata size integer in cases where we know the size > ------------------------------------------------------------ > > Key: ISPN-8423 > URL: https://issues.jboss.org/browse/ISPN-8423 > Project: Infinispan > Issue Type: Sub-task > Reporter: William Burns > Assignee: William Burns > Fix For: 9.2.0.Beta1 > > > We store a type with the other metadata. This tells us whether the entry is IMMORTAL, MORTAL, TRANSIENT etc. In the case of known types we already know how large the metadata is. There is no reason to write an int stating this. This can remove 4 bytes in a lot of cases, especially now that rest uses a standard metadata. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8423) Remove metadata size integer in cases where we know the size

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-8423?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8423: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Remove metadata size integer in cases where we know the size > ------------------------------------------------------------ > > Key: ISPN-8423 > URL: https://issues.jboss.org/browse/ISPN-8423 > Project: Infinispan > Issue Type: Sub-task > Reporter: William Burns > Assignee: William Burns > Fix For: 9.2.0.Beta1, 9.1.3.Final > > > We store a type with the other metadata. This tells us whether the entry is IMMORTAL, MORTAL, TRANSIENT etc. In the case of known types we already know how large the metadata is. There is no reason to write an int stating this. This can remove 4 bytes in a lot of cases, especially now that rest uses a standard metadata. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6879) Calculate (and expose) minimum number of nodes for data in Infinispan

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6879?page=com.atlassian.jira.plugin.... ] Dan Berindei commented on ISPN-6879: ------------------------------------ To be clear, killing one node at a time is still going to create a lot of unnecessary traffic as each rebalance will assign new segments to a node that is going to be killed in a few minutes anyway. So I'm all for a way to tell Infinispan to rebalance such that some nodes own 0 entries (similar to {{capacityFactor = 0}}, but dynamic) before shutting those nodes down. And that would even work with {{numOwners = 1}} > Calculate (and expose) minimum number of nodes for data in Infinispan > --------------------------------------------------------------------- > > Key: ISPN-6879 > URL: https://issues.jboss.org/browse/ISPN-6879 > Project: Infinispan > Issue Type: Feature Request > Components: Cloud Integrations, Server > Reporter: Sebastian Łaskawiec > Assignee: William Burns > > With Kubernetes autoscaling we need to be able to tell what is the minimum amount of nodes necessary for hosting data (probably some sort of size + number of nodes estimation). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6850) Add Infinispan images to Tiller/Helm

by Pedro Zapata (JIRA)

[ https://issues.jboss.org/browse/ISPN-6850?page=com.atlassian.jira.plugin.... ] Pedro Zapata updated ISPN-6850: ------------------------------- Priority: Minor (was: Major) > Add Infinispan images to Tiller/Helm > ------------------------------------ > > Key: ISPN-6850 > URL: https://issues.jboss.org/browse/ISPN-6850 > Project: Infinispan > Issue Type: Feature Request > Components: Cloud Integrations > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > Priority: Minor > Labels: hackathon > > [Helm and Tiller|http://helm.sh/] are client and server part of the same tool - package installer for Kubernetes. Currently there are no Infinispan images there. We need to fix it! -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2017