[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
12 years, 2 months
[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
12 years, 2 months
[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
12 years, 2 months
[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
12 years, 2 months
[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
12 years, 3 months