July 2013 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-573) Allow LAN RPCs to be SYNC while WAN RPCs to be ASYNC

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-573?page=com.atlassian.jira.plugin.s... ] Mircea Markus resolved ISPN-573. -------------------------------- Resolution: Out of Date covered by xsite functionality. > Allow LAN RPCs to be SYNC while WAN RPCs to be ASYNC > ---------------------------------------------------- > > Key: ISPN-573 > URL: https://issues.jboss.org/browse/ISPN-573 > Project: Infinispan > Issue Type: Feature Request > Components: RPC > Affects Versions: 4.1.0.CR2 > Reporter: Manik Surtani > Assignee: Manik Surtani > Labels: datacentre_replication, wan, wan_replication > Fix For: 6.0.0.Final > > > This will allow for interesting WAN architectures where RPC messages to members within the same LAN would be sent synchronously and RPC messages to remote members across a WAN to be sent asynchronously. This will allow for a cluster to span 2 data centres, (configured using TCP, for example), while allowing for *some* backups to be in the same data centre while others reside in a remote data centre. > From an email thread: > "So even if you have 4 owners, 2 in each DC, the "local" replication, > there will be no way to write to the local backup synchronously and > the remote backups asynchronously. I.e., either all comms are sync or > all comms are async. > Maybe this is something we can add in Infinispan. I.e., with node > hints (https://jira.jboss.org/browse/ISPN-180) (*) we could detect > which recipients are local and which are remote, and accordingly split > the RPC into 2: a sync local RPC and an async remote RPC. > (*) Node hinting isn't strictly necessary; the naming convention you > mentioned earlier would work in this regard as well, although I think > these hints is probably a better universal solution since we need this > for other things anyway." -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-58) Create a TaskQueueExecutorFactory and TaskQueueScheduledExecutorFactory

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-58?page=com.atlassian.jira.plugin.sy... ] Mircea Markus updated ISPN-58: ------------------------------ Priority: Optional (was: Major) > Create a TaskQueueExecutorFactory and TaskQueueScheduledExecutorFactory > ----------------------------------------------------------------------- > > Key: ISPN-58 > URL: https://issues.jboss.org/browse/ISPN-58 > Project: Infinispan > Issue Type: Sub-task > Reporter: Manik Surtani > Assignee: Manik Surtani > Priority: Optional > > These executors will not spawn separate threads, but hook in to Google's TaskQueue API > http://code.google.com/appengine/docs/java/taskqueue/overview.html > This will enable Infinispan to run without spawning any additional threads, thereby enabling it to run on Google's App Engine runtime. > Will need to expose a URI (/taskqueueexecutor ?) which is invoked to process arbitrary Callable/Runnables. May need to use the DataStore to store the actual Callable/Runnable, and pass the taskqueueexecutor the key of the stored object. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1349) Create B+ tree indexing (with cache mode distributed) and use this index in distributed queries

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1349?page=com.atlassian.jira.plugin.... ] Mircea Markus resolved ISPN-1349. --------------------------------- Fix Version/s: (was: 6.0.0.Final) Resolution: Rejected interesting idea. We currently don't have any performance issues with Lucene indexing, if that will be the case we can consider implementing our own indexing and reopen the JIRA. > Create B+ tree indexing (with cache mode distributed) and use this index in distributed queries > ------------------------------------------------------------------------------------------------ > > Key: ISPN-1349 > URL: https://issues.jboss.org/browse/ISPN-1349 > Project: Infinispan > Issue Type: Feature Request > Components: Querying > Reporter: Magnus Magnus > Assignee: Manik Surtani > > Create possibility to use B+ tree indexing instead of Lucene. Indexing should work with distributed cache mode. > Indexing should happen locally included backups. Map-reduce like distributed query could be run which can use the local indexes and merge the results from the nodes. Sorting and limit(from, to) should be supported. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-58) Create a TaskQueueExecutorFactory and TaskQueueScheduledExecutorFactory

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-58?page=com.atlassian.jira.plugin.sy... ] Mircea Markus updated ISPN-58: ------------------------------ Fix Version/s: (was: 6.0.0.Final) > Create a TaskQueueExecutorFactory and TaskQueueScheduledExecutorFactory > ----------------------------------------------------------------------- > > Key: ISPN-58 > URL: https://issues.jboss.org/browse/ISPN-58 > Project: Infinispan > Issue Type: Sub-task > Reporter: Manik Surtani > Assignee: Manik Surtani > > These executors will not spawn separate threads, but hook in to Google's TaskQueue API > http://code.google.com/appengine/docs/java/taskqueue/overview.html > This will enable Infinispan to run without spawning any additional threads, thereby enabling it to run on Google's App Engine runtime. > Will need to expose a URI (/taskqueueexecutor ?) which is invoked to process arbitrary Callable/Runnables. May need to use the DataStore to store the actual Callable/Runnable, and pass the taskqueueexecutor the key of the stored object. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-825) Consider staggering remote get requests when using DIST

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-825?page=com.atlassian.jira.plugin.s... ] Mircea Markus updated ISPN-825: ------------------------------- Fix Version/s: 6.0.0.Final (was: 6.0.0.Alpha1) > Consider staggering remote get requests when using DIST > ------------------------------------------------------- > > Key: ISPN-825 > URL: https://issues.jboss.org/browse/ISPN-825 > Project: Infinispan > Issue Type: Feature Request > Components: RPC > Affects Versions: 4.1.0.Final > Reporter: Manik Surtani > Assignee: Mircea Markus > Priority: Critical > Labels: optimization, performance > Fix For: 6.0.0.Final > > > In DIST mode, when a request is made on a key that is not mapped locally, a remote get is sent to all data owners of that key and the first response is used. This can add unnecessary load on the network as all nodes still eventually respond, and if values are large this can cause a lot of unnecessary network traffic. > The purpose of broadcasting to all data owners is so that (1) if one is down, another could still respond (2) if one is overloaded, others may respond faster. > A solution around this could be based on either (or both) of: > * Provide a configurable stagger timeout, e.g. 100ms. E.g., RPC to (random) Owner1. Wait for timeout t. If no response, RPC to Owner2. etc. > * Always broadcast to a (configurable) subset of owners, e.g., always 2 even if numOwners is 5. > Needs careful thought and design. -- 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, 9 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: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > 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 > > 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-2189) Compact buffers of ExpandableMarshalledValueByteStream to save memory on long term storage

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2189?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2189: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Compact buffers of ExpandableMarshalledValueByteStream to save memory on long term storage > ------------------------------------------------------------------------------------------ > > Key: ISPN-2189 > URL: https://issues.jboss.org/browse/ISPN-2189 > Project: Infinispan > Issue Type: Enhancement > Affects Versions: 5.1.5.FINAL > Reporter: Sanne Grinovero > Assignee: Manik Surtani > > Buffers allocated by org.infinispan.io.ExpandableMarshalledValueByteStream grow by approximation, but in > {code}org.infinispan.marshall.MarshalledValue.serialize0(){code} > we know when the buffer won't grow any longer as it's going to be treated as effectively immutable. At this point we should shrink the buffer to potentially save memory on each entry in the datagrid. > This likely needs to be optional as depending on configuration the buffer might be used for a temporary operation, in which case the effort of resizing should be avoided. -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1261) Complete the work on the event bridge between Infinispan and CDI

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1261?page=com.atlassian.jira.plugin.... ] Mircea Markus commented on ISPN-1261: ------------------------------------- [~kevinpollet] ping :-) > Complete the work on the event bridge between Infinispan and CDI > ---------------------------------------------------------------- > > Key: ISPN-1261 > URL: https://issues.jboss.org/browse/ISPN-1261 > Project: Infinispan > Issue Type: Task > Components: CDI integration > Reporter: Kevin Pollet > Assignee: Kevin Pollet > Fix For: 6.0.0.Final > > > The event bridge (for cache and cache manager) is already implemented in the code but some events are not supported and a deprecated one is used. The following work has to be done on the event bridge: > * Remove deprecated event > * Support all events > * Verify how cache and cache manager observers are registered > * Tests > * Doc -- 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, 9 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1261) Complete the work on the event bridge between Infinispan and CDI

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-1261?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-1261: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > Complete the work on the event bridge between Infinispan and CDI > ---------------------------------------------------------------- > > Key: ISPN-1261 > URL: https://issues.jboss.org/browse/ISPN-1261 > Project: Infinispan > Issue Type: Task > Components: CDI integration > Reporter: Kevin Pollet > Assignee: Kevin Pollet > > The event bridge (for cache and cache manager) is already implemented in the code but some events are not supported and a deprecated one is used. The following work has to be done on the event bridge: > * Remove deprecated event > * Support all events > * Verify how cache and cache manager observers are registered > * Tests > * Doc -- 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, 9 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: -------------------------------- Fix Version/s: (was: 6.0.0.Final) > 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 > 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, 9 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 July 2013