April 2012 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2018) Add trace to buffer size predictor

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-2018: -------------------------------------- Summary: Add trace to buffer size predictor Key: ISPN-2018 URL: https://issues.jboss.org/browse/ISPN-2018 Project: Infinispan Issue Type: Enhancement Components: Marshalling Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.1.x Add trace logging to AdaptiveBufferSizePredictor to get a better idea of the objects for which size prediction is invoked and the size that is returned. -- 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, 12 months

2
4
0 / 0

[JBoss JIRA] Created: (ISPN-893) Addtional attribute on @CacheEntryCreated to get on pre notifications only

by Sudheer Krishna (JIRA)

Addtional attribute on @CacheEntryCreated to get on pre notifications only ----------------------------------------------------------------------------- Key: ISPN-893 URL: https://issues.jboss.org/browse/ISPN-893 Project: Infinispan Issue Type: Enhancement Components: Listeners Affects Versions: 4.2.0.Final Environment: ALL Reporter: Sudheer Krishna Assignee: Manik Surtani Priority: Minor I may have usescases where i need notifications only when isPre = true. I was expecting a parameter to be taken by @CacheEntryCreated. But this doesnt seem to take any parametres. Aslo i would like similar values on @CacheEntryremoved also. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 12 months

4
17
0 / 0

[JBoss JIRA] (ISPN-2017) Allow a org.jboss.marshalling.ClassTable to be specified in SerializationConfigurationBuilder

by Stuart Douglas (JIRA)

Stuart Douglas created ISPN-2017: ------------------------------------ Summary: Allow a org.jboss.marshalling.ClassTable to be specified in SerializationConfigurationBuilder Key: ISPN-2017 URL: https://issues.jboss.org/browse/ISPN-2017 Project: Infinispan Issue Type: Feature Request Components: Marshalling Affects Versions: 5.1.4.FINAL Reporter: Stuart Douglas Assignee: Galder Zamarreño This would allow AS7 to provide a ClassTable implementation that would mean we would not need to serialise the full class name and module for some common AS7 classes that are present in session replication (namely org.jboss.as.clustering.web.DistributableSessionMetadata, org.jboss.as.clustering.SimpleMarshalledValue and org.infinispan.context.Flag). -- 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
4
0 / 0

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

by Manik Surtani (JIRA)

Support eventual consistency ---------------------------- Key: ISPN-999 URL: https://issues.jboss.org/browse/ISPN-999 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache, Locking and Concurrency Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.1.0.BETA1, 5.1.0.Final 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 is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

4
8
0 / 0

[JBoss JIRA] (ISPN-1924) Switch Infinispan internals to use new configuration

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-1924: -------------------------------------- Summary: Switch Infinispan internals to use new configuration Key: ISPN-1924 URL: https://issues.jboss.org/browse/ISPN-1924 Project: Infinispan Issue Type: Task Components: Configuration Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.2.0.ALPHA1, 5.2.0.FINAL This avoids reliance on old configuration and avoids the need to add new options to old configuration. I had originally planned to do this as part of ISPN-1367 but it's better splitted out. -- 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

1
2
0 / 0

[JBoss JIRA] (ISPN-1997) JDBC test suite fails with recent H2 driver

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-1997: ------------------------------------- Summary: JDBC test suite fails with recent H2 driver Key: ISPN-1997 URL: https://issues.jboss.org/browse/ISPN-1997 Project: Infinispan Issue Type: Bug Components: Test Suite Affects Versions: 5.1.4.CR1 Reporter: Tristan Tarrant Assignee: Tristan Tarrant Priority: Minor Fix For: 5.1.4.FINAL The binary JDBC cache store expects the ID column to be of type INT but the unit tests create an ID column of type VARCHAR(255). Recent versions of H2 (1.3.x) fail to interpret this correctly. -- 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
8
0 / 0

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

by Galder Zamarreño (JIRA)

Investigate possibility of doing manual rehashing ------------------------------------------------- Key: ISPN-1394 URL: https://issues.jboss.org/browse/ISPN-1394 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache Reporter: Galder Zamarreño Assignee: Manik Surtani Fix For: 5.2.0.FINAL 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 is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

5
4
0 / 0

[JBoss JIRA] (ISPN-2005) Memcached server throwing UnknownOperationException with many clients

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-2005: -------------------------------------- Summary: Memcached server throwing UnknownOperationException with many clients Key: ISPN-2005 URL: https://issues.jboss.org/browse/ISPN-2005 Project: Infinispan Issue Type: Bug Components: Cache Server Affects Versions: 5.1.3.FINAL Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.1.4.FINAL With native memcached out of the box, I can execute such a test without any problems: 1000 clients (threads), 400 operations per thread, 34% writes However, running Infinispan Memcached distribution with 1000 worker threads results in exceptions such as: {code}2012-04-23 16:46:59,893 ERROR (MemcachedServerWorker-1-957) [org.infinispan.server.memcached.MemcachedDecoder] ISPN005003: Exception reported org.infinispan.server.core.UnknownOperationException: Unknown operation: at org.infinispan.server.memcached.RequestResolver$.toRequest(MemcachedDecoder.scala:659) at org.infinispan.server.memcached.MemcachedDecoder.readHeader(MemcachedDecoder.scala:73) at org.infinispan.server.core.AbstractProtocolDecoder.decodeHeader(AbstractProtocolDecoder.scala:92) at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:69) at org.infinispan.server.core.AbstractProtocolDecoder.decode(AbstractProtocolDecoder.scala:45) at org.infinispan.server.core.transport.CustomReplayingDecoder.callDecode(CustomReplayingDecoder.java:250) at org.infinispan.server.core.transport.CustomReplayingDecoder.messageReceived(CustomReplayingDecoder.java:223) at org.infinispan.server.core.AbstractProtocolDecoder.messageReceived(AbstractProtocolDecoder.scala:360) at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:274) at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:261) at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:351) at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:282) at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:202) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:680){code} Client shows: {code}2012-04-23 16:46:28.742 INFO net.spy.memcached.MemcachedConnection: Reconnecting due to exception on {QA sa=/127.0.0.1:11211, #Rops=0, #Wops=0, #iq=0, topRop=null, topWop=null, toWrite=0, interested=0} java.net.SocketException: Connection reset by peer at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method) at sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:567) at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:369) at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:242) at net.spy.memcached.MemcachedConnection.run(MemcachedConnection.java:833){code} -- 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
10
0 / 0

[JBoss JIRA] (ISPN-2019) Allow HotRod to ues String keys for interoperability with REST and Memcached

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-2019: ------------------------------------- Summary: Allow HotRod to ues String keys for interoperability with REST and Memcached Key: ISPN-2019 URL: https://issues.jboss.org/browse/ISPN-2019 Project: Infinispan Issue Type: Feature Request Components: Cache Server Affects Versions: 5.1.4.FINAL Reporter: Tristan Tarrant Assignee: Manik Surtani Priority: Trivial In JDG multiple server protocols can be mapped to the same caches. Since HotRod uses ByteArrayKey keys, it is not possible to read/write keys which need to be accessed via REST and/or Memcached. Maybe add a flag so that a key is interpreted as a String. -- 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

1
0
0 / 0

[JBoss JIRA] Created: (ISPN-1147) Programmatically creating cache should be automatically reflected throughout the cluster

by Randall Hauch (JIRA)

Programmatically creating cache should be automatically reflected throughout the cluster ---------------------------------------------------------------------------------------- Key: ISPN-1147 URL: https://issues.jboss.org/browse/ISPN-1147 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache, State transfer Affects Versions: 4.2.1.FINAL Reporter: Randall Hauch Assignee: Manik Surtani Consider a symmetric cluster of two nodes (N1 and N2) each with a single cache (C1). Currently, a new cache (C2) must be programmatically created _on all all nodes in the cluster_ (if REPL, or all appropriate nodes if DIST) _before_ that new cache can even be _used_. Ideally, when a new cache (C2) is created on one node (N1), Infinispan should automatically propagate that creation to the appropriate nodes in the cluster so that the new cache can be used immediately. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

7
9
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2012