February 2012 - infinispan-issues

[JBoss JIRA] Created: (ISPN-159) Extended coalesced logic to other parts

by Galder Zamarreno (JIRA)

Extended coalesced logic to other parts --------------------------------------- Key: ISPN-159 URL: https://jira.jboss.org/jira/browse/ISPN-159 Project: Infinispan Issue Type: Feature Request Components: RPC, Transactions Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.0.0.CR1 Reuse same coalesced async cache store logic to: - Reduce size of replicable commands where N modifications are sent so that only latest state is sent. - Manage the async replication queue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

3
9
0 / 0

[JBoss JIRA] Created: (ISPN-330) Separate scheduled/unscheduled async cache store configuration

by Galder Zamarreno (JIRA)

Separate scheduled/unscheduled async cache store configuration -------------------------------------------------------------- Key: ISPN-330 URL: https://jira.jboss.org/jira/browse/ISPN-330 Project: Infinispan Issue Type: Sub-task Components: Configuration, Loaders and Stores Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.BETA1 Implement configuration that allows differentiation between scheduled/unscheduled strategies: <async enabled="true"> <scheduled frequency="1000" /> </async> <async enabled="true"> <unscheduled poolsize="50" /> </async> This format allows for easier extension of properties in scheduled/unscheduled modes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 6 months

3
5
0 / 0

[JBoss JIRA] (ISPN-1842) Configuration schema is not included at expected location

by Sanne Grinovero (JIRA)

Sanne Grinovero created ISPN-1842: ------------------------------------- Summary: Configuration schema is not included at expected location Key: ISPN-1842 URL: https://issues.jboss.org/browse/ISPN-1842 Project: Infinispan Issue Type: Bug Reporter: Sanne Grinovero Assignee: Manik Surtani Fix For: 5.2.0.ALPHA1, 5.2.0.FINAL Just found these messages in my logs: {quote} 17:04:43,731 (main) DEBUG FileLookup:57 - Unable to find file schema/infinispan-config-5.1.xsd in classpath; searching for this file on the filesystem instead. 17:04:43,731 (main) DEBUG InfinispanConfiguration:389 - Could not find schema on path schema/infinispan-config-5.1.xsd, resolving infinispan.config.schema to http://www.infinispan.org/schemas/infinispan-config-5.1.xsd 17:04:43,911 (main) DEBUG InfinispanConfiguration:396 - Using schema http://www.infinispan.org/schemas/infinispan-config-5.1.xsd {quote} Indeed the schema is included in the jar, but is in the root of the jar, while it's searched for in *schema/infinispan-config-5.1.xsd* -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

5
13
0 / 0

[JBoss JIRA] Created: (ISPN-1103) Soft schema-based storage

by Manik Surtani (JIRA)

Soft schema-based storage ------------------------- Key: ISPN-1103 URL: https://issues.jboss.org/browse/ISPN-1103 Project: Infinispan Issue Type: Feature Request Components: Core API Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.1.0.BETA1, 5.1.0.Final This JIRA is about storing metadata alongside values. Perhaps encapsulating values as SchematicValues, which could be described as: {code} class SchematicValue { String jsonMetadata; String jsonObject; } {code} Metadata would allow for a few interesting features: * Extracting of lifespan and timestamp data if manipulated over a remote protocol (REST, HotRod, etc) * Content type for REST responses * Timestamps for REST headers, will affect HTTP content caches * Validation information (may not be processed by Infinispan, but can be used by client libs) * Classloader/marshaller/classdef version info * General structure of the information stored -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

8
22
0 / 0

[JBoss JIRA] Created: (ISPN-939) Index corruption when remote node dies during commit

by Tristan Tarrant (JIRA)

Index corruption when remote node dies during commit ---------------------------------------------------- Key: ISPN-939 URL: https://issues.jboss.org/browse/ISPN-939 Project: Infinispan Issue Type: Bug Components: Lucene Directory Affects Versions: 4.2.1.CR2 Reporter: Tristan Tarrant Assignee: Sanne Grinovero Using a scenario similar to the one described in ISPN-909: Infinispan: 3 caches: lockCache (replicated, volatile, no eviction), metadataCache (replicated, persisted, no eviction), dataCache (distributed, persisted, eviction, hash numOwners=2) Node 1: coordinator, IndexWriter open constantly and writing a stream of documents, committing after each one Node 2: opens a read-only IndexReader to perform queries, using reopen to keep in sync with the updates coming from node 1 If we "kill -9" node 2 (to simulate a crash), we get a SuspectException in node 1 during the pre-commit phase (within IndexWriter.commit()). Catching the Throwable we then close() the writer but from then on we get "Read past EOF" errors when trying to access the index (both with readers and writers). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

3
20
0 / 0

[JBoss JIRA] Created: (ISPN-1313) Execution timeout should not be linked to replication timeout

by Thomas Peuss (JIRA)

Execution timeout should not be linked to replication timeout ------------------------------------------------------------- Key: ISPN-1313 URL: https://issues.jboss.org/browse/ISPN-1313 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache Affects Versions: 5.0.0.CR8 Reporter: Thomas Peuss Assignee: Manik Surtani Currently the timeout of a distributed execution is linked to the settings for the replication timeout (we have set the timeout to <sync replTimeout="120000"/> as a workaround). For long running tasks this is really annoying because you get an error back from the framework but the distributed tasks runs till the end without a problem. There should be an extra timeout for the execution of distributed tasks. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

4
8
0 / 0

[JBoss JIRA] (ISPN-1513) Enhance distributed executor framework to be more topology aware

by David B (Created) (JIRA)

Enhance distributed executor framework to be more topology aware ---------------------------------------------------------------- Key: ISPN-1513 URL: https://issues.jboss.org/browse/ISPN-1513 Project: Infinispan Issue Type: Enhancement Components: Distributed Cache Affects Versions: 5.0.1.FINAL Reporter: David B Assignee: Manik Surtani Priority: Minor Our environment has 2 local infinispan/jgroups clusters with a jgroups relay cluster to handle geographic failover. Our sites are geographically distant over a WAN. Currently DistributedExecutorService's submitEverywhere() sends Callables to every node in both local clusters. We would rather have additional methods provided to DistributedExecutorService to constrain submission on Callables to the same/local site. Currently I have extended DefaultExecutorService with my own TopologyAwareExecutorService and added a submitSameSite() method using the TopologyAwareAddress.isSameSite(). I did need to patch DistributedRunnableFuture in DefaultExecutorService to mark it protected vs. private. This could be extended to also provide submitSameRack() & submitSameMachine() though currently we don't have a use case for that. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

6
8
0 / 0

[JBoss JIRA] (ISPN-1524) Make configuration of cache stores fluent

by Pete Muir (Created) (JIRA)

Make configuration of cache stores fluent ----------------------------------------- Key: ISPN-1524 URL: https://issues.jboss.org/browse/ISPN-1524 Project: Infinispan Issue Type: Feature Request Components: Configuration, Loaders and Stores Affects Versions: 5.1.0.BETA4 Reporter: Pete Muir Assignee: Manik Surtani Fix For: 5.2.0.FINAL -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

2
2
0 / 0

[JBoss JIRA] (ISPN-1827) De-couple cache view installation and state transfer (consistent hash installation)s

by Dan Berindei (JIRA)

Dan Berindei created ISPN-1827: ---------------------------------- Summary: De-couple cache view installation and state transfer (consistent hash installation)s Key: ISPN-1827 URL: https://issues.jboss.org/browse/ISPN-1827 Project: Infinispan Issue Type: Task Components: State transfer Affects Versions: 5.1.0.FINAL Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 5.2.0.FINAL We need to know the primary owner of a key in order to do pretty much anything, and every member of a cache view should compute the same primary owner at all times. So we need a 2PC cache view installation immediately after any leave to ensure that every node determines the primary owner in the same way - we can't coalesce leaves. However, it's highly desirable to coalesce state transfers caused by a node leaving - perhaps because we are shutting down half of the cluster to do an upgrade. So we should separate the state transfer from the cache view installation, and each one should have its own 2PC process. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (ISPN-1192) Map/Reduce over REST

by Manik Surtani (JIRA)

Map/Reduce over REST -------------------- Key: ISPN-1192 URL: https://issues.jboss.org/browse/ISPN-1192 Project: Infinispan Issue Type: Feature Request Components: Cache Server Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.2.0.Final Allow Map/Reduce tasks to be executed over REST -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 7 months

3
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2012