December 2013 - infinispan-issues

[JBoss JIRA] (ISPN-2857) Support asynchronous listeners and events with old values for JSR-107

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-2857?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-2857: ------------------------------- Fix Version/s: 7.0.0.Alpha1 (was: 6.0.1.Final) > Support asynchronous listeners and events with old values for JSR-107 > ---------------------------------------------------------------------- > > Key: ISPN-2857 > URL: https://issues.jboss.org/browse/ISPN-2857 > Project: Infinispan > Issue Type: Sub-task > Components: JCache, Listeners > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Alpha1 > > > These parts of the JSR-107 listener section are not currently tested by the TCK (version 0.6) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3244) TopologyAwareSyncConsistentHashFactory should limit the number of segments per node

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3244?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3244: ------------------------------- Fix Version/s: 7.0.0.Alpha1 (was: 6.0.1.Final) > TopologyAwareSyncConsistentHashFactory should limit the number of segments per node > ----------------------------------------------------------------------------------- > > Key: ISPN-3244 > URL: https://issues.jboss.org/browse/ISPN-3244 > Project: Infinispan > Issue Type: Bug > Components: State transfer > Affects Versions: 5.2.6.Final, 5.3.0.CR2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 7.0.0.Alpha1 > > > Let's say we have a cluster with 5 nodes: A(r1), B(r2), C(r2), D(r3), E(r3) > TopologyAwareConsistentSyncHashFactory will spread the segments equally on each rack, meaning A will own 2x segments compared to the other nodes. > TopologyAwareConsistentHashFactory limits the maximum number per node, so that A owns just as many segments as the other nodes. With a slight limitation: the number of racks must be greater than numOwners, otherwise each rack must hold (at least) one copy of all the data. > TopologyAwareConsistentSyncHashFactory is a little random, so we can't distribute the data perfectly, but we can limit the number of segments on each node to something like 1.5x the average number of segments. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3229) L1 cache entries should not be passivated

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3229?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3229: ------------------------------- Fix Version/s: 7.0.0.Alpha1 (was: 6.0.1.Final) > L1 cache entries should not be passivated > ----------------------------------------- > > Key: ISPN-3229 > URL: https://issues.jboss.org/browse/ISPN-3229 > Project: Infinispan > Issue Type: Bug > Affects Versions: 5.2.6.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Alpha1 > > Attachments: DistSyncL1PassivationFuncTest.java > > > L1 entries are stored in the same data container as the real entries. These can be evicted which is fine, however we don't want them to be passivated as this could be costly to write/read from the cache store. We should either prevent L1 cache entries from being passivated or have an option to allow for it. > Currently L1 entries are not differentiated from other entries except through the fact that they are mortal, which is used for other operations as well, which means they would need a placeholder of some kind to tell the container this is a L1 entry. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3181) Retrieving entries via REST doesn't work

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3181?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3181: ------------------------------- Fix Version/s: 7.0.0.Alpha1 (was: 6.0.1.Final) > Retrieving entries via REST doesn't work > ---------------------------------------- > > Key: ISPN-3181 > URL: https://issues.jboss.org/browse/ISPN-3181 > Project: Infinispan > Issue Type: Bug > Components: Server > Affects Versions: 5.3.0.Final > Reporter: Jakub Markos > Assignee: Tristan Tarrant > Fix For: 7.0.0.Alpha1 > > Attachments: console_output.txt, server.log, standalone-dist.xml > > > Retrieving an entry stored via REST fails with 404 http response. > The test is located here: > https://code.engineering.redhat.com/gerrit/gitweb?p=jdg-functional-tests.... > {code:java} > String fullPathKey = fullPathKey(KEY_A); > post(fullPathKey, "data", "application/text"); > HttpResponse resp = get(fullPathKey, "data"); > {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3159) Implementing SERIALIZABLE isolation level based on GMU

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3159?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3159: ------------------------------- Fix Version/s: 7.0.0.Alpha1 (was: 6.0.1.Final) > Implementing SERIALIZABLE isolation level based on GMU > ------------------------------------------------------ > > Key: ISPN-3159 > URL: https://issues.jboss.org/browse/ISPN-3159 > Project: Infinispan > Issue Type: Feature Request > Components: Transactions > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 7.0.0.Alpha1 > > > Implementation based in GMU, a Cloud-TM project research (www.cloudtm.eu). > GMU is a muti-version scheme that provides Update Serializability. It allows the read-only transaction to proceed without blocking, but they can observe an old value (but always a consistent value). > This scheme relies in Vector Clock to manage the snapshots to read and the transaction dependencies in each node in the cluster. > Also, it is a genuine scheme, i.e., only the nodes involved in the transaction (that contains data read or write) are involved in the transaction commit. > A paper describing GMU can be found here: http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=62... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3047) Drop encoding from CLI once servers store raw values

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3047?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3047: ------------------------------- Fix Version/s: 7.0.0.Alpha1 (was: 6.0.1.Final) > Drop encoding from CLI once servers store raw values > ---------------------------------------------------- > > Key: ISPN-3047 > URL: https://issues.jboss.org/browse/ISPN-3047 > Project: Infinispan > Issue Type: Task > Components: CLI > Affects Versions: 5.3.0.Alpha1 > Reporter: NadirX > Assignee: Tristan Tarrant > Fix For: 7.0.0.Alpha1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3093) Design remote Map/Reduce functionality in Infinispan

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3093?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3093: ------------------------------- Fix Version/s: 7.0.0.Alpha1 (was: 6.0.1.Final) > Design remote Map/Reduce functionality in Infinispan > ---------------------------------------------------- > > Key: ISPN-3093 > URL: https://issues.jboss.org/browse/ISPN-3093 > Project: Infinispan > Issue Type: Task > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 7.0.0.Alpha1 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3529) Add support for the segment-based CH in the HotRod protocol

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3529?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3529: ------------------------------- Fix Version/s: 7.0.0.Alpha1 (was: 6.0.1.Final) > Add support for the segment-based CH in the HotRod protocol > ----------------------------------------------------------- > > Key: ISPN-3529 > URL: https://issues.jboss.org/browse/ISPN-3529 > Project: Infinispan > Issue Type: Feature Request > Components: Remote protocols > Affects Versions: 6.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: hotrod, hotrod-java-client > Fix For: 7.0.0.Alpha1 > > > The server CH changed in version 5.2 from virtual-nodes-based to segment-based, but the client CH stayed the same. The server is able to translate the server CH into a client CH, but the translation is imperfect: > 1. Sometimes the client CH computes a different primary owner than the server CH. > 2. The client CH gets slower as the number of segments increases, the server CH performance stays the same. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3480) Use protoparser lib instead of relying on binary descriptors generated by protoc

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3480?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3480: ------------------------------- Fix Version/s: 7.0.0.Alpha1 (was: 6.0.1.Final) > Use protoparser lib instead of relying on binary descriptors generated by protoc > -------------------------------------------------------------------------------- > > Key: ISPN-3480 > URL: https://issues.jboss.org/browse/ISPN-3480 > Project: Infinispan > Issue Type: Task > Components: Marshalling > Affects Versions: 6.0.0.Alpha4 > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 7.0.0.Alpha1 > > > Use protoparser [1] for obtaining type metadata rather than relying one the binary descriptors generated by Google Prootbuf's protoc tool. > [1] https://github.com/square/protoparser -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3402) Add JDBC Cache Store config to RHQ plugin

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-3402?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-3402: ------------------------------- Fix Version/s: 7.0.0.Alpha1 (was: 6.0.1.Final) > Add JDBC Cache Store config to RHQ plugin > ----------------------------------------- > > Key: ISPN-3402 > URL: https://issues.jboss.org/browse/ISPN-3402 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores, Server > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Alpha1 > > > ISPN-3350 was added to enhance some of the RHQ endpoints to allow for better runtime configuration support. However ISPN-3290 is also concurrently changing cache stores. Some changes for ISPN-3290 were mentioned to be possibly changing how the JDBC cache stores are configured and as such this has been excluded from ISPN-3350 to not implement it twice. > This is just to add in the support JDBC cache stores as they are missing. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 3 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 December 2013