October 2010 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-738) Get operation doesn't work with explict locking under distribution mode

by Changgeng Li (JIRA)

Get operation doesn't work with explict locking under distribution mode ----------------------------------------------------------------------- Key: ISPN-738 URL: https://jira.jboss.org/browse/ISPN-738 Project: Infinispan Issue Type: Bug Environment: With the current 4.2.0-SNAPSHOT build. Reporter: Changgeng Li Assignee: Manik Surtani Priority: Blocker Fix For: 4.2.0.BETA1 Attachments: bug1.tgz The issue can be reproduced by following steps: 1) CacheA and CacheB in a distribute mode with numberOfOwners set to 1, so that an key can only be found on one node. 2) Use CacheA to put 100 entries using keys from Integer(0) to Integer(99) 2) Using CacheB make explicit locking on a key, and then get the value for that key, if the key is not on CacheB, it will return null. Unit test is attached -- 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

14 years, 1 month

2
4
0 / 0

[JBoss JIRA] Created: (ISPN-737) Provide logging of informational message for server modules

by Richard Achmatowicz (JIRA)

Provide logging of informational message for server modules ----------------------------------------------------------- Key: ISPN-737 URL: https://jira.jboss.org/browse/ISPN-737 Project: Infinispan Issue Type: Feature Request Components: Configuration Affects Versions: 4.1.0.Final Reporter: Richard Achmatowicz Assignee: Galder Zamarreño At present, there is precious little information on the server modules and their startup. The scala sources have a logging framework in place, there seems to be little in the way of information being logged. It would be very helpful if a server module could have some DEBUG information added to indicate: * the phases it does through when starting and confirmation of whether or not it has started * the configuration it is using and some basic details * similar for shutdown -- 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

14 years, 1 month

3
5
0 / 0

[JBoss JIRA] Created: (ISPN-719) BoundedConcurrentHashMap.EvictionListener should have a bulk entry listener method.

by Trustin Lee (JIRA)

BoundedConcurrentHashMap.EvictionListener should have a bulk entry listener method. ----------------------------------------------------------------------------------- Key: ISPN-719 URL: https://jira.jboss.org/browse/ISPN-719 Project: Infinispan Issue Type: Task Components: Core API Affects Versions: 4.1.0.Final Reporter: Trustin Lee Assignee: Manik Surtani Fix For: 4.2.0.BETA1 BoundedConcurrentHashMap.EvictionListener should have a bulk entry listener so that CacheStores can optimize passivation behavior. Current BoundedConcurrentHashMap notifies EvictionListener for every evicted entry. However, as you see from BoundedConcurrentHashMap.Segment.attemptEviction(..), eviction often happens in bulk. If these evicted entries are supposed to be passivated, it is often beneficial to begin a transaction because it often takes much less time to call commit() less often. If N entries are evicted: without bulk eviction: store.store(e1); -- each store implied a commit() store.store(..); store.store(eN); with bulk eviction: store.begin(mods(e1, ..., eN), tx, true); -- 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

14 years, 1 month

3
8
0 / 0

[JBoss JIRA] Created: (ISPN-729) Upgrade to Netty 3.2.3.Final

by Trustin Lee (JIRA)

Upgrade to Netty 3.2.3.Final ---------------------------- Key: ISPN-729 URL: https://jira.jboss.org/browse/ISPN-729 Project: Infinispan Issue Type: Thirdparty Change Components: Cache Server Reporter: Trustin Lee Assignee: Manik Surtani Priority: Minor Fix For: 4.2.0.BETA1 I've just released Netty 3.2.3.Final which includes the fix for a WebSocket bug which might affect ISPN websocket module. -- 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

14 years, 1 month

3
5
0 / 0

[JBoss JIRA] Created: (ISPN-747) Use *_HOME environment variables to determine java executable

by Tobias Sarnowski (JIRA)

Use *_HOME environment variables to determine java executable ------------------------------------------------------------- Key: ISPN-747 URL: https://jira.jboss.org/browse/ISPN-747 Project: Infinispan Issue Type: Feature Request Reporter: Tobias Sarnowski Assignee: Manik Surtani The startServer.sh script currently only invokes "java" directly. The well-known java environment variables like JAVA_HOME are ignored. This raises problems when having a default java installation like gnu gcj 1.42 in the system. Since the linux distribution packages are too old in general, I have e.g. the Oracle JDK unzipped under /opt with JAVA_HOME pointing to it. Having JAVA_HOME set in general indicates that this java should be used, so it should be respected. The following change would solve this issue: # diff startServer.sh startServer.sh.new 51c51,59 < java -cp $CP ${JVM_PARAMS} org.infinispan.server.core.Main ${*} --- > JAVA_EXE=java > if [ ! -z "$JAVA_HOME" ]; then > JAVA_EXE=$JAVA_HOME/bin/java > elif [ ! -z "$JDK_HOME" ]; then > JAVA_EXE=$JDK_HOME/bin/java > elif [ ! -z "$JRE_HOME" ]; then > JAVA_EXE=$JRE_HOME/bin/java > fi > $JAVA_EXE -cp $CP ${JVM_PARAMS} org.infinispan.server.core.Main ${*} -- 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

14 years, 1 month

2
6
0 / 0

[JBoss JIRA] Assigned: (ISPN-186) Smart L1 cache invalidation

by Trustin Lee (JIRA)

[ https://jira.jboss.org/browse/ISPN-186?page=com.atlassian.jira.plugin.sys... ] Trustin Lee reassigned ISPN-186: -------------------------------- Assignee: Trustin Lee (was: Darran Lofthouse) > Smart L1 cache invalidation > --------------------------- > > Key: ISPN-186 > URL: https://jira.jboss.org/browse/ISPN-186 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Cache > Reporter: Manik Surtani > Assignee: Trustin Lee > Fix For: 5.0.0.BETA1, 5.0.0.Final > > > Need to build a mechanism in which L1 invalidation is NOT multicast, but instead is unicast _if necessary_ to specific nodes that may have cached a given entry. This can be detected by maintaining a list of nodes who have requested a key via a remote get, but this would need to be relayed by all data owners. > Benefits would be performance by removing unnecessary invalidation where this is not needed, and by reducing noise in network stacks of most nodes. -- 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

14 years, 1 month

1
0
0 / 0

[JBoss JIRA] Commented: (ISPN-186) Smart L1 cache invalidation

by Darran Lofthouse (JIRA)

[ https://jira.jboss.org/browse/ISPN-186?page=com.atlassian.jira.plugin.sys... ] Darran Lofthouse commented on ISPN-186: --------------------------------------- Hi Trustin, I am not actively working on this at the moment so if you are ready to take over that is fine - I will have a look for some other issues. > Smart L1 cache invalidation > --------------------------- > > Key: ISPN-186 > URL: https://jira.jboss.org/browse/ISPN-186 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Cache > Reporter: Manik Surtani > Assignee: Darran Lofthouse > Fix For: 5.0.0.BETA1, 5.0.0.Final > > > Need to build a mechanism in which L1 invalidation is NOT multicast, but instead is unicast _if necessary_ to specific nodes that may have cached a given entry. This can be detected by maintaining a list of nodes who have requested a key via a remote get, but this would need to be relayed by all data owners. > Benefits would be performance by removing unnecessary invalidation where this is not needed, and by reducing noise in network stacks of most nodes. -- 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

14 years, 1 month

1
0
0 / 0

[JBoss JIRA] Work stopped: (ISPN-186) Smart L1 cache invalidation

by Darran Lofthouse (JIRA)

[ https://jira.jboss.org/browse/ISPN-186?page=com.atlassian.jira.plugin.sys... ] Work on ISPN-186 stopped by Darran Lofthouse. > Smart L1 cache invalidation > --------------------------- > > Key: ISPN-186 > URL: https://jira.jboss.org/browse/ISPN-186 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Cache > Reporter: Manik Surtani > Assignee: Darran Lofthouse > Fix For: 5.0.0.BETA1, 5.0.0.Final > > > Need to build a mechanism in which L1 invalidation is NOT multicast, but instead is unicast _if necessary_ to specific nodes that may have cached a given entry. This can be detected by maintaining a list of nodes who have requested a key via a remote get, but this would need to be relayed by all data owners. > Benefits would be performance by removing unnecessary invalidation where this is not needed, and by reducing noise in network stacks of most nodes. -- 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

14 years, 1 month

1
0
0 / 0

[JBoss JIRA] Assigned: (ISPN-39) Distributed executors

by Trustin Lee (JIRA)

[ https://jira.jboss.org/browse/ISPN-39?page=com.atlassian.jira.plugin.syst... ] Trustin Lee reassigned ISPN-39: ------------------------------- Assignee: Trustin Lee (was: Vladimir Blagojevic) > Distributed executors > --------------------- > > Key: ISPN-39 > URL: https://jira.jboss.org/browse/ISPN-39 > Project: Infinispan > Issue Type: Feature Request > Components: RPC > Reporter: Manik Surtani > Assignee: Trustin Lee > Priority: Critical > Fix For: 5.0.0.BETA1, 5.0.0.Final > > > A new API to allow users to provide a Runnable/Callable and a set of keys to run this on, and the ability to move the code to where the data is and execute it there, returning results (if any) across a network. > Scope and objectives of this task are described in https://community.jboss.org/wiki/InfinispanDistributedExecutionFramework -- 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

14 years, 1 month

1
0
0 / 0

[JBoss JIRA] Commented: (ISPN-186) Smart L1 cache invalidation

by Trustin Lee (JIRA)

[ https://jira.jboss.org/browse/ISPN-186?page=com.atlassian.jira.plugin.sys... ] Trustin Lee commented on ISPN-186: ---------------------------------- Darran, are you working on this issue? Otherwise, I'd like to take this over. > Smart L1 cache invalidation > --------------------------- > > Key: ISPN-186 > URL: https://jira.jboss.org/browse/ISPN-186 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Cache > Reporter: Manik Surtani > Assignee: Darran Lofthouse > Fix For: 5.0.0.BETA1, 5.0.0.Final > > > Need to build a mechanism in which L1 invalidation is NOT multicast, but instead is unicast _if necessary_ to specific nodes that may have cached a given entry. This can be detected by maintaining a list of nodes who have requested a key via a remote get, but this would need to be relayed by all data owners. > Benefits would be performance by removing unnecessary invalidation where this is not needed, and by reducing noise in network stacks of most nodes. -- 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

14 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2010