March 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3546) Migrate mongodb cache store to the 6.0 cachestore API

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3546?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3546: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan-cachestore-mongodb/pull/8 > Migrate mongodb cache store to the 6.0 cachestore API > ----------------------------------------------------- > > Key: ISPN-3546 > URL: https://issues.jboss.org/browse/ISPN-3546 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: Mircea Markus > Fix For: 8.2.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3546) Migrate mongodb cache store to the 6.0 cachestore API

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3546?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-3546: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 8.2.0.Final Resolution: Done > Migrate mongodb cache store to the 6.0 cachestore API > ----------------------------------------------------- > > Key: ISPN-3546 > URL: https://issues.jboss.org/browse/ISPN-3546 > Project: Infinispan > Issue Type: Enhancement > Components: Loaders and Stores > Reporter: Mircea Markus > Fix For: 8.2.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2944) Simple Storm Bolt

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2944?page=com.atlassian.jira.plugin.... ] Tristan Tarrant reassigned ISPN-2944: ------------------------------------- Assignee: Gustavo Fernandes > Simple Storm Bolt > ----------------- > > Key: ISPN-2944 > URL: https://issues.jboss.org/browse/ISPN-2944 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Shane Johnson > Assignee: Gustavo Fernandes > Labels: hackathon > > Create a simple ISPN Storm bolt. There are currently simply bolts for Apache Cassandra, MongoDB, Apache HBase, and more. > https://github.com/nathanmarz/storm-contrib > Tighter integration with Big Data tools allows for hybrid architectures with ISPN. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-999) Support eventual consistency

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-999?page=com.atlassian.jira.plugin.s... ] Tristan Tarrant updated ISPN-999: --------------------------------- Fix Version/s: (was: 9.0.0.Final) > Support eventual consistency > ---------------------------- > > Key: ISPN-999 > URL: https://issues.jboss.org/browse/ISPN-999 > Project: Infinispan > Issue Type: Feature Request > Components: Core, Transactions > Reporter: Manik Surtani > Labels: eventual_consistency > Original Estimate: 1 minute > Remaining Estimate: 1 minute > > Essentially, it is about supporting eventual consistency in Infinispan. Currently Infinispan is strongly consistent when using synchronous distribution mode. Each data owner receives updates synchronously so anyone anywhere on the cluster doing a GET will see the correct value. The only exception is during a rehash (when a new node joins or leaves), that consistency is eventual since the GET may reach a new joiner who may not have applied state it receives from its neighbours yet. However this is hidden from users since the GET is sent to> 1 data owner and if an UnsureResponse is received (determined by the fact that a new joiner responds and the new joiner wouldn't have finished applying state), the caller thread waits for more definite responses. > However, there is a use case for being eventually consistent as well: the main benefits being speed and partition tolerance. E.g., if we use distribution in asynchronous mode, the writes become *much* faster. However, anyone anywhere doing a GET will have to perform the GET on all data owners, and compare the versions of the data received to determine which is the latest. And if there is a conflict, to pass back all values to the user. > So in terms of design, what I have in mind is: > * All cache entries are versioned using vector clocks. One vector clock per node. > * When a node performs a GET, the GET is sent to all data owners (concurrently), and the value + version is retrieved from each. > * If the versions are all the same (or they can be "fast forwarded"), the value is returned > * Otherwise, all potential values and their versions are returned > * A resolve() API should be provided where application code may provide a "hint" as to which version should be "correct" - which will cause an update. > * In terms of implementation, this will touch the DistributionInterceptor, InternalCacheEntry and relevant factories, some config code (since this should be consistency model should be configurable), and a new public interface. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-1394) Investigate possibility of doing manual rehashing

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-1394?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-1394. --------------------------------- Resolution: Duplicate Issue > Investigate possibility of doing manual rehashing > ------------------------------------------------- > > Key: ISPN-1394 > URL: https://issues.jboss.org/browse/ISPN-1394 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Galder Zamarreño > > Investigate the possibility of being able to do manual rehashing: > - Approach used Dynamo (and Cassandra) > - If you're adding 100 nodes, using manual rehashing could reduce traffic and make it more predictable > - Could be called via JMX > - But removing 10 nodes could be problematic. Unless number of owners is 11 or higher, which will guarantee that at least a copy of data is around -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2275) Migrate Cassandra Cache Store to CQL3

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2275?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-2275. --------------------------------- Resolution: Done > Migrate Cassandra Cache Store to CQL3 > ------------------------------------- > > Key: ISPN-2275 > URL: https://issues.jboss.org/browse/ISPN-2275 > Project: Infinispan > Issue Type: Task > Components: Loaders and Stores > Affects Versions: 5.2.0.Alpha3 > Reporter: NadirX > Priority: Minor > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2811) cassandraStore xml configuration gives parser error on attributes "username" and "password"

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2811?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-2811. --------------------------------- Resolution: Out of Date > cassandraStore xml configuration gives parser error on attributes "username" and "password" > ------------------------------------------------------------------------------------------- > > Key: ISPN-2811 > URL: https://issues.jboss.org/browse/ISPN-2811 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.2.0.Final > Reporter: Giovanni Mels > > This is because attributes "username" and "password" are in uppercase in [org.infinispan.loaders.cassandra.configuration.Attribute|https://github.c...], but in lowercase in the [schema|http://docs.jboss.org/infinispan/schemas/infinispan-cachestore-cas...]. > {quote} > org.infinispan.config.ConfigurationException: javax.xml.stream.XMLStreamException: ParseError at [row,col]:[37,142] > Message: Unexpected attribute 'password' encountered > at org.infinispan.configuration.parsing.ParseUtils.unexpectedAttribute(ParseUtils.java:76) > at org.infinispan.configuration.parsing.Parser52.parseCommonStoreAttributes(Parser52.java:696) > at org.infinispan.loaders.cassandra.configuration.CassandraCacheStoreConfigurationParser52.parseCassandraStoreAttributes(CassandraCacheStoreConfigurationParser52.java:180) > at org.infinispan.loaders.cassandra.configuration.CassandraCacheStoreConfigurationParser52.parseCassandraStore(CassandraCacheStoreConfigurationParser52.java:77) > at org.infinispan.loaders.cassandra.configuration.CassandraCacheStoreConfigurationParser52.readElement(CassandraCacheStoreConfigurationParser52.java:65) > at org.infinispan.loaders.cassandra.configuration.CassandraCacheStoreConfigurationParser52.readElement(CassandraCacheStoreConfigurationParser52.java:43) > at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) > at org.jboss.staxmapper.XMLExtendedStreamReaderImpl.handleAny(XMLExtendedStreamReaderImpl.java:69) > at org.infinispan.configuration.parsing.Parser52.parseLoaders(Parser52.java:588) > at org.infinispan.configuration.parsing.Parser52.parseCache(Parser52.java:180) > at org.infinispan.configuration.parsing.Parser52.parseDefaultCache(Parser52.java:145) > at org.infinispan.configuration.parsing.Parser52.readElement(Parser52.java:98) > at org.infinispan.configuration.parsing.Parser52.readElement(Parser52.java:75) > at org.jboss.staxmapper.XMLMapperImpl.processNested(XMLMapperImpl.java:110) > at org.jboss.staxmapper.XMLMapperImpl.parseDocument(XMLMapperImpl.java:69) > at org.infinispan.configuration.parsing.ParserRegistry.parse(ParserRegistry.java:77) > ... 28 more > {quote} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-6314) ClusterTopologyManager.waitForJoinerView can wait forever

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6314?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6314: ------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > ClusterTopologyManager.waitForJoinerView can wait forever > --------------------------------------------------------- > > Key: ISPN-6314 > URL: https://issues.jboss.org/browse/ISPN-6314 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 8.2.0.CR1 > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 8.2.0.Final > > > this method uses {{TimeService.remainingTime()}} to calculate the time it needs to wait, returning zero is the time is expired. However, zero timeout in {{Object.wait()}} will indicate to wait forever. Avoid invoke the {{wait()}} is time is already expired. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-3520) Cassandra Cache Store is read-only by default

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-3520?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-3520. --------------------------------- Resolution: Out of Date > Cassandra Cache Store is read-only by default > --------------------------------------------- > > Key: ISPN-3520 > URL: https://issues.jboss.org/browse/ISPN-3520 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 5.2.6.Final, 6.0.0.Alpha4 > Reporter: Giovanni Mels > Attachments: PassivationTest.java > > > It is impossible to store any data in the Cassandra cache store, because it is created as read-only, even when specifying {{ignoreModifications = false}}. See the attached test case: > [INFO ] ISPN000078: Starting JGroups Channel (org.infinispan.remoting.transport.jgroups.JGroupsTransport) > [INFO ] ISPN000088: Unable to use any JGroups configuration mechanisms provided in properties {}. Using default JGroups configuration! (org.infinispan.remoting.transport.jgroups.JGroupsTransport) > [INFO ] ISPN000094: Received new cluster view: [GNELA182-53637|0] [GNELA182-53637] (org.infinispan.remoting.transport.jgroups.JGroupsTransport) > [INFO ] ISPN000079: Cache local address is GNELA182-53637, physical addresses are [fe80:0:0:0:64f5:4fad:cd2e:b5cf:51350] (org.infinispan.remoting.transport.jgroups.JGroupsTransport) > [INFO ] ISPN000128: Infinispan version: Infinispan 'Delirium' 5.2.6.Final (org.infinispan.factories.GlobalComponentRegistry) > [DEBUG] automatically create keyspace (org.infinispan.loaders.cassandra.CassandraCacheStore) > [INFO ] ConnectionPool initialized. (net.dataforte.cassandra.pool.ConnectionPool) > [DEBUG] cleaning up expired entries... (org.infinispan.loaders.cassandra.CassandraCacheStore) > [TRACE] purgeInternal (org.infinispan.loaders.cassandra.CassandraCacheStore) > [INFO ] ConnectionPool initialized. (net.dataforte.cassandra.pool.ConnectionPool) > [DEBUG] started (org.infinispan.loaders.cassandra.CassandraCacheStore) > *[TRACE] Ignoring clear invocation (org.infinispan.loaders.decorators.ReadOnlyStore)* > [INFO ] ISPN000031: MBeans were successfully registered to the platform MBean server. (org.infinispan.jmx.CacheJmxRegistration) > [INFO ] creating test1 (com.agfa.aca.PassivationTest) > [DEBUG] Key 'entry_test1' not found (org.infinispan.loaders.cassandra.CassandraCacheStore) > *[TRACE] Ignoring removal of key (org.infinispan.loaders.decorators.ReadOnlyStore)* > [INFO ] created test1 (com.agfa.aca.PassivationTest) > [INFO ] creating test2 (com.agfa.aca.PassivationTest) > [DEBUG] Key 'entry_test2' not found (org.infinispan.loaders.cassandra.CassandraCacheStore) > [INFO ] passivating test1 (com.agfa.aca.PassivationTest) > *[TRACE] Ignoring store invocation (org.infinispan.loaders.decorators.ReadOnlyStore)* > [INFO ] passivated test1 (com.agfa.aca.PassivationTest) > *[TRACE] Ignoring removal of key (org.infinispan.loaders.decorators.ReadOnlyStore)* > [INFO ] created test2 (com.agfa.aca.PassivationTest) > [DEBUG] Key 'entry_test1' not found (org.infinispan.loaders.cassandra.CassandraCacheStore) > I tracked this bug down to the {{create}} method in {{CassandraCacheStoreConfigurationBuilder}} > {code} > @Override > public CassandraCacheStoreConfiguration create() { > List<CassandraServerConfiguration> remoteServers = new ArrayList<CassandraServerConfiguration>(); > for (CassandraServerConfigurationBuilder server : servers) { > remoteServers.add(server.create()); > } > return new CassandraCacheStoreConfiguration(autoCreateKeyspace, configurationPropertiesFile, entryColumnFamily, > expirationColumnFamily, framed, remoteServers, keyMapper, keySpace, password, sharedKeyspace, username, > readConsistencyLevel, writeConsistencyLevel, autoCreateKeyspace, sharedKeyspace, purgerThreads, framed, > autoCreateKeyspace, TypedProperties.toTypedProperties(properties), async.create(), singletonStore.create()); > } > {code} > Note how {{autoCreateKeyspace}} is used in stead of {{purgeInternal}} and {{ignoreModifications}}, so if you explicitly set {{autoCreateKeyspace = false}} you can work around the issue. > This is tested on 5.2.6, all versions from 5.2 on have the same error. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-2130) Common management interface for Infinispan and GlusterFS

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-2130?page=com.atlassian.jira.plugin.... ] Tristan Tarrant closed ISPN-2130. --------------------------------- Resolution: Won't Fix > Common management interface for Infinispan and GlusterFS > -------------------------------------------------------- > > Key: ISPN-2130 > URL: https://issues.jboss.org/browse/ISPN-2130 > Project: Infinispan > Issue Type: Feature Request > Components: JMX, reporting and management > Reporter: Vijay Bellur > Assignee: Vijay Bellur > Priority: Minor > > Evolve a common management interface for clustering, providing mapping between Infinispan modes and GlusterFS volumes. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2016