October 2010 - infinispan-issues - Jboss List Archives

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

by Manik Surtani (JIRA)

Allow LAN RPCs to be SYNC while WAN RPCs to be ASYNC ---------------------------------------------------- Key: ISPN-573 URL: https://jira.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 Fix For: 5.1.0.BETA1, 5.1.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 contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

2
3
0 / 0

[JBoss JIRA] Created: (ISPN-129) Ability to manage cluster-wide configuration via a central management console

by Manik Surtani (JIRA)

Ability to manage cluster-wide configuration via a central management console ----------------------------------------------------------------------------- Key: ISPN-129 URL: https://jira.jboss.org/jira/browse/ISPN-129 Project: Infinispan Issue Type: Feature Request Components: JMX, reporting and management Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.0.0.GA Perhaps a lightweight form of JBoss AS' profile service, or something similar. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
2
0 / 0

[JBoss JIRA] Created: (ISPN-127) Ability to bring up/take down nodes based on SLAs

by Manik Surtani (JIRA)

Ability to bring up/take down nodes based on SLAs ------------------------------------------------- Key: ISPN-127 URL: https://jira.jboss.org/jira/browse/ISPN-127 Project: Infinispan Issue Type: Feature Request Components: JMX and reporting Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.GA Need to look at what JOPR can provide by way of bringing up or killing instances based on overall load. Perhaps other metrics such as time of day could be used as well. Would be very useful to help build out a truly 'elastic' data grid. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
3
0 / 0

[JBoss JIRA] Created: (ISPN-126) Management console to graph nodes visually

by Manik Surtani (JIRA)

Management console to graph nodes visually ------------------------------------------ Key: ISPN-126 URL: https://jira.jboss.org/jira/browse/ISPN-126 Project: Infinispan Issue Type: Feature Request Components: JMX and reporting Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.GA This should also include colour coded visuals to report activity, status, health etc. Need to investigate what JOPR can provide here, via the agent. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
3
0 / 0

[JBoss JIRA] Created: (ISPN-741) Implement Continuous Query on Infinispan

by Mircea Markus (JIRA)

Implement Continuous Query on Infinispan ---------------------------------------- Key: ISPN-741 URL: https://jira.jboss.org/browse/ISPN-741 Project: Infinispan Issue Type: Feature Request Reporter: Mircea Markus Assignee: Mircea Markus Fix For: 5.1.0.Final Implement continuous query on infinispan based on the tech preview: http://github.com/mmarkus/infinispan-continuous-query. Documentation on API and functionality: http://community.jboss.org/wiki/ContinuousQuerywithInfinispan -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

2
2
0 / 0

[JBoss JIRA] Created: (ISPN-121) Create a cache store to work with GAE/J's JPA implementation

by Manik Surtani (JIRA)

Create a cache store to work with GAE/J's JPA implementation ------------------------------------------------------------ Key: ISPN-121 URL: https://jira.jboss.org/jira/browse/ISPN-121 Project: Infinispan Issue Type: Feature Request Components: Loaders and Stores Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.BETA1, 4.1.0.GA A cache store that could store state on Google AppEngine for Java's JPA backend. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

1
4
0 / 0

[JBoss JIRA] Created: (ISPN-720) Replace CacheEntryEvictedEvent with CacheEntriesEvictedEvent (note the plural)

by Trustin Lee (JIRA)

Replace CacheEntryEvictedEvent with CacheEntriesEvictedEvent (note the plural) ------------------------------------------------------------------------------ Key: ISPN-720 URL: https://jira.jboss.org/browse/ISPN-720 Project: Infinispan Issue Type: Task Components: Core API Affects Versions: 4.2.0.Final Reporter: Trustin Lee Assignee: Trustin Lee Fix For: 5.0.0.BETA1 CacheEntryEvictedEvent should be replaced with CacheEntriesEvictedEvent to fully utilize the improvements in EvictionListener (see ISPN-718). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

4
18
0 / 0

[JBoss JIRA] Created: (ISPN-663) Eviction with passivation using JdbmCacheStore is 100 times slower in 4.1 vs 4.0

by Paul Nardone (JIRA)

Eviction with passivation using JdbmCacheStore is 100 times slower in 4.1 vs 4.0 -------------------------------------------------------------------------------- Key: ISPN-663 URL: https://jira.jboss.org/browse/ISPN-663 Project: Infinispan Issue Type: Bug Components: Eviction, Loaders and Stores Affects Versions: 4.1.0.Final Environment: Win32 JRE 1.6.0_21 Reporter: Paul Nardone Assignee: Manik Surtani Attachments: InfinispanPassivationTest.java Eviction with passivation enabled using the JdbmCacheStore appears to be significantly slower in 4.1.0.FINAL vs 4.0.0.FINAL. The degredation in performance is so signficant to make it impossible to use The performance issue seems to due as the JdbmCacheStore synching the filesystem via FileDescriptor.sync() or similar which occurs during every object passivation and each passivation occurs as a new object is added beyond the EvictionMaxEntries capacity. The attached test inserts 1000 values into two caches Both caches use a JdbmCacheStore and LRU PASSIVATIONLRU10 runs with cache with EvictionMaxEntries 10 PASSIVATIONLRU1000 runs with cache with EvictionMaxEntries 1000 4.1.0.FINAL PASSIVATIONLRU10 Time Taken : 51704 PASSIVATIONLRU1000 Time Taken : 4484 4.0.0.FINAL PASSIVATIONLRU10 Time Taken : 281 PASSIVATIONLRU1000 Time Taken : 141 4.2.0.ALPHA2 PASSIVATIONLRU10 Time Taken : 51047 PASSIVATIONLRU1000 Time Taken : 5156 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

5
36
0 / 0

[JBoss JIRA] Created: (ISPN-721) Change CacheStore.store() to return the previous value instead of void.

by Trustin Lee (JIRA)

Change CacheStore.store() to return the previous value instead of void. ----------------------------------------------------------------------- Key: ISPN-721 URL: https://jira.jboss.org/browse/ISPN-721 Project: Infinispan Issue Type: Task Components: Core API Affects Versions: 4.2.0.Final Reporter: Trustin Lee Assignee: Trustin Lee Fix For: 5.0.0.BETA1 Cache.put(key, value) operation returns a previous value. However, CacheStore.store() does not return a previous value but void. To overcome the impedance mismatch, the current implementation calls CacheStore.load() to simply get the previous value. CacheStore.store() could be improved to reduce this unnecessary round trip. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

4
10
0 / 0

[JBoss JIRA] Created: (ISPN-360) create NodeJoined event

by Mircea Markus (JIRA)

create NodeJoined event ----------------------- Key: ISPN-360 URL: https://jira.jboss.org/jira/browse/ISPN-360 Project: Infinispan Issue Type: Feature Request Components: Listeners, State transfer Reporter: Mircea Markus Assignee: Manik Surtani In relation to http://community.jboss.org/message/529547#529547 It's an well known scenario to start a cluster, and only after the ENTIRE cluster is started to start and do work. Right now, we have CacheStarted and ViewChanged notifications. First only tells us that the local node is started but other nodes might still be in the process of starting. Second one tells us that the view has changed, but not that the cluster has started, i.e. the cache might be in the process of rebalancing state etc. A possible solution would be to have an NodeJoined event, that would be called whenever a new node finished joining the cluster. Finished joining means state transfer happened and that node is started. For a possible workaround to this feature see the forum post. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 7 months

4
12
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2010