January 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-1414) Introduce a builder than can create an Infinispan CacheManager

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1414?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1414: -------------------------------- Component/s: Core > Introduce a builder than can create an Infinispan CacheManager > -------------------------------------------------------------- > > Key: ISPN-1414 > URL: https://issues.jboss.org/browse/ISPN-1414 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Pete Muir > Assignee: Manik Surtani > > Provide a builder class that allows passing in of SPI instances, rather than doing lookup. This allows for much easier integration, as context from the app server bootstrap can be easily passed in. > For example: > {code} > public class CacheManagerBuilder { > void setClassLoader(ClassLoader cl); > void setTransport(Transport t); > ... > Cache start(); > } > {code} > We would still want to offer a wrapper around this for Java SE users that would expose a create a CacheManager easily. This factory would want to use a CacheManagerBuilder internally to create the cache, but offer a simplified API. You would want to expose the Builder from the factory as well, offering a sensible set of defaults for SE. > This would break backwards compatibility, as doing new EmbeddedCacheManager etc. would no longer be possible. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2069) Implement a caching servlet filter

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2069?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2069: -------------------------------- Component/s: Server > Implement a caching servlet filter > ---------------------------------- > > Key: ISPN-2069 > URL: https://issues.jboss.org/browse/ISPN-2069 > Project: Infinispan > Issue Type: Feature Request > Components: Server > Reporter: NadirX > Assignee: Tristan Tarrant > Priority: Minor > > Implement a servlet filter for caching web requests keyed on servlet path, parameters and headers. Look into support for web caching standards such as ESI. Possibly include a JSP tag library -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1413) CacheManager per application to provide "Session style" construct

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1413?page=com.atlassian.jira.plugin.... ] Mircea Markus resolved ISPN-1413. --------------------------------- Resolution: Rejected see my last comment. > CacheManager per application to provide "Session style" construct > ----------------------------------------------------------------- > > Key: ISPN-1413 > URL: https://issues.jboss.org/browse/ISPN-1413 > Project: Infinispan > Issue Type: Feature Request > Reporter: Pete Muir > Assignee: Manik Surtani > Attachments: Cache Manager per Application.gliffy, Cache Manager per Application.png > > > This solves a problem with classloading, as Infinispan will know exactly what classloader to use for a cache manager and any deserialized cached objects, events etc. > However, it does require support for asymmetric clusters. > Open issues are: > * how do we handle EARs > * how do we handle shared 2nd level caches > * needs support for asymmetric clusters > * needs to mux JGroups channels > * needs consideration of how to handle shared thread pools -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

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

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2130?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2130: -------------------------------- Component/s: JMX, reporting and management > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2201) Make a distinction between user-level and internal flags

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2201?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2201: -------------------------------- Component/s: Core > Make a distinction between user-level and internal flags > -------------------------------------------------------- > > Key: ISPN-2201 > URL: https://issues.jboss.org/browse/ISPN-2201 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > > This confusion is highlighted by ISPN-2187. > User-level flags, i.e. FORCE_WRITE_LOCK, should be separated from those that are purely internal, i.e. PUT_FOR_EXTERNAL_READ. > Obviously, user-level flags might be used for internal purpouses, but by making the separation and putting the internal-only flags separately, we should avoid misuse. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2198) Cluster with non-shared JDBC cache store has too much entries after node failure

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2198?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2198: -------------------------------- Component/s: Loaders and Stores > Cluster with non-shared JDBC cache store has too much entries after node failure > -------------------------------------------------------------------------------- > > Key: ISPN-2198 > URL: https://issues.jboss.org/browse/ISPN-2198 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores > Affects Versions: 5.1.5.FINAL > Reporter: Radim Vansa > Assignee: Mircea Markus > Attachments: cache_entries.csv, logs.zip, sfout.txt > > > In resilience test with 4-node cluster where one node is killed a weird situation appears. Before the node kill have this number of entries: > 210602;215820;209400;203038 = 838860 entries > After the kill the number of entries changes for a while: > 210602;null;209400;203038 > 250602;null;269400;243038 > 290602;null;269400;273038 > 300602;null;289400;293038 > 300602;null;289400;293038 > 321218;null;296035;293038 > But then it stabilizes on > 326899;null;305039;314165 = 946103 entries > When the node02 is restarted it complains about duplicit entries: > ERROR [org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore] (OOB-124,null) ISPN008024: Error while storing string key to database; key: '8Az4Ia2V5NzYzNDI=', buffer size of value: 1050 bytes: com.mysql.jdbc.exceptions.jdbc4.MySQLIntegrityConstraintViolationException: Duplicate entry '?8Az4Ia2V5NzYzNDI=' for key 'PRIMARY' > Is this a bug or wrong configuration? > Here is an excerpt from configuration (sorry for no formatting): > <distributed-cache batching="false" indexing="NONE" l1-lifespan="0" mode="SYNC" name="memcachedCache" owners="2" remote-timeout="60000" start="EAGER" virtual-nodes="512"> > <locking acquire-timeout="3000" concurrency-level="1000" isolation="REPEATABLE_READ" striping="false"/> > <transaction mode="NONE"/> > <state-transfer enabled="true" timeout="600000"/> > <eviction max-entries="-1" strategy="NONE"/> > <string-keyed-jdbc-store datasource="java:jboss/datasources/JdbcDS" passivation="false" preload="false" purge="true" shared="false"> > <property name="databaseType">MYSQL</property> > <string-keyed-table prefix="node01"> > <id-column name="id" type="VARCHAR(100)"/> > <data-column name="value" type="BLOB(1200)"/> > </string-keyed-table> > </string-keyed-jdbc-store> > </distributed-cache> -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2244) Transparently hold serialized representations of keys and values

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2244?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2244: -------------------------------- Component/s: Core > Transparently hold serialized representations of keys and values > ---------------------------------------------------------------- > > Key: ISPN-2244 > URL: https://issues.jboss.org/browse/ISPN-2244 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Robert Stupp > Assignee: Mircea Markus > > Serialization/deserialization might become very expensive when working with cached large java objects that are created and used on many different nodes. > At the moment, the setting storeAsBinary() allows you to "die" either one: > * serialize/deserialize when the cache is accessed > * serialize/deserialize when L1 is filled or invalidated, object fetched from other node, object is replicated on put > It might be a good solution to add a third mode: > * At a put() operation, the Java object is put into the cache > * When the serialized representation is required first, it is created from the Java object (or during the put() operation) > * The serialized representation is reused every time when needed. > Means: cache the serialized representation of keys and values. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2133) Provide a context for object de-serialization

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2133?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2133: -------------------------------- Component/s: Core > Provide a context for object de-serialization > --------------------------------------------- > > Key: ISPN-2133 > URL: https://issues.jboss.org/browse/ISPN-2133 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Sanne Grinovero > Assignee: Manik Surtani > > See proposal description at > http://lists.jboss.org/pipermail/infinispan-dev/2012-June/010925.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

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

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2130?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2130: -------------------------------- Priority: Minor (was: Major) > Common management interface for Infinispan and GlusterFS > -------------------------------------------------------- > > Key: ISPN-2130 > URL: https://issues.jboss.org/browse/ISPN-2130 > Project: Infinispan > Issue Type: Feature Request > 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 is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2905) StateTransferLockImpl.waitForTransactionData should be able to time-out

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2905?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2905: -------------------------------- Component/s: Test Suite - Core > StateTransferLockImpl.waitForTransactionData should be able to time-out > ----------------------------------------------------------------------- > > Key: ISPN-2905 > URL: https://issues.jboss.org/browse/ISPN-2905 > Project: Infinispan > Issue Type: Feature Request > Components: Test Suite - Core > Affects Versions: 5.2.4.Final > Reporter: Radim Vansa > Assignee: Dan Berindei > > During a topology change a lot of threads can get stuck in {{StateTransferLockImpl.waitForTransactionData}} indefinitely, due to ISPN-2808 fill up the OOB threadpool and block the topology change. > These operations should timeout after a period. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 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 January 2014