May 2010 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-406) Avoid remote requests to the topology cache.

by Galder Zamarreno (JIRA)

Avoid remote requests to the topology cache. -------------------------------------------- Key: ISPN-406 URL: https://jira.jboss.org/jira/browse/ISPN-406 Project: Infinispan Issue Type: Bug Components: Cache Server Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.BETA1 Stop remote requests to the topology cache. This is to avoid remote clients messing up such an important cache. -- 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, 10 months

2
5
0 / 0

[JBoss JIRA] Created: (ISPN-426) Deal with concurrent Hot Rod topology view changes

by Galder Zamarreno (JIRA)

Deal with concurrent Hot Rod topology view changes -------------------------------------------------- Key: ISPN-426 URL: https://jira.jboss.org/jira/browse/ISPN-426 Project: Infinispan Issue Type: Task Components: Cache Server Affects Versions: 4.1.0.BETA1 Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.CR1 Deal with situations where multiple nodes modify the view at the same time and the atomic putIfAbsent or replace calls do not succeed. If this happens on startup and the node has issues adding itself, a backoff and retry would most probably make sense. If unable after backoff, stop startup process and report issue. If this happens when a node is stopping and the node is trying to remove itself from the view, this is not such a big problem because logic to deal with crashed or stalled members will clear it up. If this happens when the crashed member detector is trying to remove a crashed node, backoff/retry would make sense and if still unable to remove, note it and wait for next view change that would attempt to clear it again. -- 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, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (ISPN-441) HotRodClient:check connection status for idle connection

by Mircea Markus (JIRA)

HotRodClient:check connection status for idle connection -------------------------------------------------------- Key: ISPN-441 URL: https://jira.jboss.org/jira/browse/ISPN-441 Project: Infinispan Issue Type: Bug Components: Cache Server Reporter: Mircea Markus Assignee: Mircea Markus Priority: Critical Fix For: 4.1.0.CR1, 4.1.0.Final For long-lasting sessions, the client must ping the server from time to time, in order to check the status of the tcp connections, so that when a connection dies it should create a new one in the pool. -- 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, 10 months

1
3
0 / 0

[JBoss JIRA] Updated: (ISPN-27) RemoteCacheStore, based on delegating to a CacheServer

by Mircea Markus (JIRA)

[ https://jira.jboss.org/browse/ISPN-27?page=com.atlassian.jira.plugin.syst... ] Mircea Markus updated ISPN-27: ------------------------------ Fix Version/s: (was: 4.1.0.Final) (was: 4.1.0.CR1) > RemoteCacheStore, based on delegating to a CacheServer > ------------------------------------------------------ > > Key: ISPN-27 > URL: https://jira.jboss.org/browse/ISPN-27 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores > Reporter: Manik Surtani > Assignee: Mircea Markus > Priority: Blocker > Fix For: 4.1.0.BETA2 > > > RemoteCacheStore should use the custom binary protocol that is capable of failing over and load balancing. If the backend is configured to use distribution, the same consisitent hashing algorithm should be used by the loader to select the cache server instance in a cluster. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Updated: (ISPN-27) RemoteCacheStore, based on delegating to a CacheServer

by Mircea Markus (JIRA)

[ https://jira.jboss.org/browse/ISPN-27?page=com.atlassian.jira.plugin.syst... ] Mircea Markus updated ISPN-27: ------------------------------ Fix Version/s: 4.1.0.BETA2 > RemoteCacheStore, based on delegating to a CacheServer > ------------------------------------------------------ > > Key: ISPN-27 > URL: https://jira.jboss.org/browse/ISPN-27 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores > Reporter: Manik Surtani > Assignee: Mircea Markus > Priority: Blocker > Fix For: 4.1.0.BETA2, 4.1.0.CR1, 4.1.0.Final > > > RemoteCacheStore should use the custom binary protocol that is capable of failing over and load balancing. If the backend is configured to use distribution, the same consisitent hashing algorithm should be used by the loader to select the cache server instance in a cluster. -- 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, 10 months

1
0
0 / 0

[JBoss JIRA] Created: (ISPN-467) Hot Rod should not call into readKeys

by Galder Zamarreno (JIRA)

Hot Rod should not call into readKeys ------------------------------------- Key: ISPN-467 URL: https://jira.jboss.org/browse/ISPN-467 Project: Infinispan Issue Type: Bug Components: Cache Server Affects Versions: 4.1.0.BETA1 Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.CR1 Hot Rod does not support an operation that gets multiple keys in one go, so avoid creating unnecessary arrays when reading a single key in Hot Rod. -- 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, 10 months

1
2
0 / 0

[JBoss JIRA] Updated: (ISPN-60) make cache XA compliant

by Manik Surtani (JIRA)

[ https://jira.jboss.org/browse/ISPN-60?page=com.atlassian.jira.plugin.syst... ] Manik Surtani updated ISPN-60: ------------------------------ Fix Version/s: 5.0.0.BETA1 > make cache XA compliant > ----------------------- > > Key: ISPN-60 > URL: https://jira.jboss.org/browse/ISPN-60 > Project: Infinispan > Issue Type: Feature Request > Components: Transactions > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 5.0.0.BETA1, 5.0.0.Final > > > This should be implemented in order to bring failure-recovery capabilities to cache. Failure example: > Let's say that we have 3 nodes, A B and C. A starts tx, does a put ("k","v") then commits tx. During commit following happen: > 1) prepare is broadcasted > B prepares and holds locks > C prepares and holds locks > 2) A sees B and C voted okay,so triggers a commit: > - B receives the commit msg and applies changes (for good!) > - A does not manage to send the message to C *in the given timeout*. At this point, the RPC call returns and A rollbacks, also C will rollback after a while (tx timeout). But B will have the changes applied, and this will result in an atomicity being violated. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (ISPN-60) make cache XA compliant

by Manik Surtani (JIRA)

[ https://jira.jboss.org/browse/ISPN-60?page=com.atlassian.jira.plugin.syst... ] Manik Surtani updated ISPN-60: ------------------------------ Assignee: Mircea Markus (was: Manik Surtani) Labels: transaction xa (was: ) Component/s: Transactions > make cache XA compliant > ----------------------- > > Key: ISPN-60 > URL: https://jira.jboss.org/browse/ISPN-60 > Project: Infinispan > Issue Type: Feature Request > Components: Transactions > Reporter: Mircea Markus > Assignee: Mircea Markus > Fix For: 5.0.0.Final > > > This should be implemented in order to bring failure-recovery capabilities to cache. Failure example: > Let's say that we have 3 nodes, A B and C. A starts tx, does a put ("k","v") then commits tx. During commit following happen: > 1) prepare is broadcasted > B prepares and holds locks > C prepares and holds locks > 2) A sees B and C voted okay,so triggers a commit: > - B receives the commit msg and applies changes (for good!) > - A does not manage to send the message to C *in the given timeout*. At this point, the RPC call returns and A rollbacks, also C will rollback after a while (tx timeout). But B will have the changes applied, and this will result in an atomicity being violated. -- 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, 11 months

1
0
0 / 0

[JBoss JIRA] Assigned: (ISPN-180) Colocated nodes should be handled in DIST

by Vladimir Blagojevic (JIRA)

[ https://jira.jboss.org/browse/ISPN-180?page=com.atlassian.jira.plugin.sys... ] Vladimir Blagojevic reassigned ISPN-180: ---------------------------------------- Assignee: Vladimir Blagojevic (was: Manik Surtani) > Colocated nodes should be handled in DIST > ----------------------------------------- > > Key: ISPN-180 > URL: https://jira.jboss.org/browse/ISPN-180 > Project: Infinispan > Issue Type: Feature Request > Components: Distributed Cache > Reporter: Manik Surtani > Assignee: Vladimir Blagojevic > Fix For: 5.0.0.BETA1, 5.0.0.Final > > > DefaultConsistentHash should place addresses on the hash wheel such that colocated nodes are never less than repl_count nodes apart to prevent data loss when a server fails. -- 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, 11 months

1
0
0 / 0

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

by Vladimir Blagojevic (JIRA)

[ https://jira.jboss.org/browse/ISPN-186?page=com.atlassian.jira.plugin.sys... ] Vladimir Blagojevic reassigned ISPN-186: ---------------------------------------- Assignee: Vladimir Blagojevic (was: Manik Surtani) > 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: Vladimir Blagojevic > 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

13 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2010