August 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3045) Drop wrappers from RemoteCacheStore once HotRod server supports raw keys/values

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3045?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3045: -------------------------------- Fix Version/s: 7.0.0.Beta2 (was: 7.0.0.Beta1) > Drop wrappers from RemoteCacheStore once HotRod server supports raw keys/values > ------------------------------------------------------------------------------- > > Key: ISPN-3045 > URL: https://issues.jboss.org/browse/ISPN-3045 > Project: Infinispan > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Remote Protocols > Reporter: NadirX > Assignee: Tristan Tarrant > Fix For: 7.0.0.Beta2 > > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

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

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3093?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3093: -------------------------------- Fix Version/s: 7.0.0.Beta2 (was: 7.0.0.Beta1) > Design remote Map/Reduce functionality in Infinispan > ---------------------------------------------------- > > Key: ISPN-3093 > URL: https://issues.jboss.org/browse/ISPN-3093 > Project: Infinispan > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Remote Protocols > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 7.0.0.Beta2 > > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

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

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3047?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3047: -------------------------------- Fix Version/s: 7.0.0.Beta2 (was: 7.0.0.Beta1) > 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 > Security Level: Public(Everyone can see) > Components: CLI > Affects Versions: 5.3.0.Alpha1 > Reporter: NadirX > Assignee: Tristan Tarrant > Fix For: 7.0.0.Beta2 > > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

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

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3159?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3159: -------------------------------- Fix Version/s: 7.0.0.Beta2 (was: 7.0.0.Beta1) > Implementing SERIALIZABLE isolation level based on GMU > ------------------------------------------------------ > > Key: ISPN-3159 > URL: https://issues.jboss.org/browse/ISPN-3159 > Project: Infinispan > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Transactions > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 7.0.0.Beta2 > > > 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 was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

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

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3181?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3181: -------------------------------- Fix Version/s: 7.0.0.Beta2 (was: 7.0.0.Beta1) > Retrieving entries via REST doesn't work > ---------------------------------------- > > Key: ISPN-3181 > URL: https://issues.jboss.org/browse/ISPN-3181 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Server > Affects Versions: 5.3.0.Final > Reporter: Jakub Markos > Assignee: Tristan Tarrant > Fix For: 7.0.0.Beta2 > > 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 was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3160) RemoteCacheManager javadocs list wrong default pool size

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3160?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3160: -------------------------------- Fix Version/s: 7.0.0.Beta2 (was: 7.0.0.Beta1) > RemoteCacheManager javadocs list wrong default pool size > -------------------------------------------------------- > > Key: ISPN-3160 > URL: https://issues.jboss.org/browse/ISPN-3160 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Remote Protocols > Affects Versions: 5.1.8.Final > Reporter: Dennis Reed > Assignee: Tristan Tarrant > Priority: Minor > Fix For: 7.0.0.Beta2 > > > RemoteCacheManager javadocs list the default pool size as 10: > "infinispan.client.hotrod.default_executor_factory.pool_size, default = 10." > However, the default is actually 99: > org/infinispan/client/hotrodimpl/ConfigurationProperties.java: return props.getIntProperty(DEFAULT_EXECUTOR_FACTORY_POOL_SIZE, 99); -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3337) Define an approach to allow the injection of Configuration and GlobalConfiguration beans for overriding

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3337?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3337: -------------------------------- Fix Version/s: 7.0.0.Beta2 (was: 7.0.0.Beta1) > Define an approach to allow the injection of Configuration and GlobalConfiguration beans for overriding > ------------------------------------------------------------------------------------------------------- > > Key: ISPN-3337 > URL: https://issues.jboss.org/browse/ISPN-3337 > Project: Infinispan > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Spring Integration > Reporter: Navin Surtani > Assignee: Gustavo Fernandes > Fix For: 7.0.0.Beta2 > > > ISPN-3279 removed the ConfigurationOverrides and GlobalConfigurationOverrides classes in the Spring module. These classes contained older set() calls in order to override Cache configurations and given the way that programmatic Configuration currently works in Infinispan, that approach is not maintainable. > We hence need a clean way to provide (Global) Configuration beans as a newer, cleaner approach. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3336) Extended Statistics check list

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3336?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3336: -------------------------------- Fix Version/s: 7.0.0.Beta2 (was: 7.0.0.Beta1) > Extended Statistics check list > ------------------------------ > > Key: ISPN-3336 > URL: https://issues.jboss.org/browse/ISPN-3336 > Project: Infinispan > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Core > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Priority: Critical > Labels: core > Fix For: 7.0.0.Beta2 > > > * add documentation > * check for duplicate stats; > * check for not exposed statistics > * try to improve the code (reduce the number of access to the CHM) > * add tests to check if they are exported via JMX correctly > * failing test: OptimisticLockingTxClusterExtendedStatisticLogicTest.testWriteSkewOnNonOwner > * failing test: PessimisticLockingTxClusterExtendedStatisticLogicTest.testDeadlockOnNonOwnerWithRemoteTx -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3273) Dist L1 owners that aren't primary don't respect assumeOriginKeptEntryInL1

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3273?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3273: -------------------------------- Fix Version/s: 7.0.0.Beta2 (was: 7.0.0.Beta1) > Dist L1 owners that aren't primary don't respect assumeOriginKeptEntryInL1 > -------------------------------------------------------------------------- > > Key: ISPN-3273 > URL: https://issues.jboss.org/browse/ISPN-3273 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Beta2 > > Attachments: DistSyncFuncTest.java > > > When a write operation occurs causing a L1 invalidation, there is a boolean to say assumeOriginKeptEntryInL1 which means the owner won't send an invalidation to the originating node that caused this update. This works fine for the primary owner, however any additional backups think the origin is the primary owner and such send invalidations to possibly the real origin. > -This affects both tx and non tx caches. Tx caches that are sync don't see the problem since locking prevents the invalidation, however it causes an unneeded network roundtrip which can cause delay.- > Actually this only affects non-tx caches, as tx caches send the prepare/commit directly to the owner(s) instead of having it relayed. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 months

1
0
0 / 0

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

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-3229?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-3229: -------------------------------- Fix Version/s: 7.0.0.Beta2 (was: 7.0.0.Beta1) > L1 cache entries should not be passivated > ----------------------------------------- > > Key: ISPN-3229 > URL: https://issues.jboss.org/browse/ISPN-3229 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: L1 > Affects Versions: 5.2.6.Final > Reporter: William Burns > Assignee: William Burns > Fix For: 7.0.0.Beta2 > > 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 was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 8 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 August 2014