infinispan-issues March 2011

infinispan-issues@lists.jboss.org

2 participants
214 discussions

[JBoss JIRA] Created: (ISPN-947) Java Hot Rod client exceptions should be more user friendly

by Galder Zamarreño (JIRA)

Java Hot Rod client exceptions should be more user friendly ----------------------------------------------------------- Key: ISPN-947 URL: https://issues.jboss.org/browse/ISPN-947 Project: Infinispan Issue Type: Bug Components: Cache Server Affects Versions: 4.2.1.CR3, 4.2.0.Final Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 4.2.1.FINAL Java Hot Rod client exceptions are not friendly: {code}WARNING: Error status received from the server: for message id 2 Exception in thread "main" org.infinispan.client.hotrod.exceptions.HotRodClientException: id [2] code [133]{code} What is that suppose to mean to clients? The following is much more friendly: {code}WARNING: Error status received from the server: for message put response (opcode=0x02) Exception in thread "main" org.infinispan.client.hotrod.exceptions.HotRodClientException: Put response (opcode=0x02) returned server error (status=0x85): ...{code} This is related to ISPN-944 which should solve the fact that server error messages are not being read by the client properly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

2
6
0 / 0

[JBoss JIRA] Created: (ISPN-362) allow pluggable data container in infinispan

by Mircea Markus (JIRA)

allow pluggable data container in infinispan -------------------------------------------- Key: ISPN-362 URL: https://jira.jboss.org/jira/browse/ISPN-362 Project: Infinispan Issue Type: Feature Request Reporter: Mircea Markus Assignee: Manik Surtani In relation to http://community.jboss.org/message/529586#529586 Users might want to write their own data container and be able to plug that in infinispan. Implementing this would require: - change configuration to support an dataContainer element perhaps under "eviction" elements. This will be passed to DataContainerFacvtory, which will build an instance of the class and pass it back. Actually, in order to allow parameters to this container, it can look like: <eviction wakeUpInterval="500" maxEntries="5000"> <dataContainer class="custom.data.Conatiner"> <properties> <propery name="configParam" value="configValue"/> </properties> </dataContainer> </eviction> -- 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, 9 months

5
8
0 / 0

[JBoss JIRA] Created: (ISPN-936) putAll suboptimal and possibly wrong

by Mircea Markus (JIRA)

putAll suboptimal and possibly wrong ------------------------------------ Key: ISPN-936 URL: https://issues.jboss.org/browse/ISPN-936 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache Affects Versions: 4.2.0.Final Reporter: Mircea Markus Assignee: Manik Surtani Fix For: 4.2.1.Final, 5.0.0.Final DistributionManager.visitPutMapCommand broadcasts ALL the map entries to ALL the nodes to which keys are mapped. E.g. if Map={k1=v1, k2=v2} and k1 maps to node A, k2 maps to node B then both A and B would receive {k1=v1, k2=v2}. The way it should be is A receives {k1=v1} and B receives {k2=v2}. This is suboptimal and error prone as, by the look of code, both node would store ALL the data in the data container. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

2
4
0 / 0

[JBoss JIRA] Created: (ISPN-962) Entries not committed w/ DistLockingInterceptor and L1 caching disabled.

by Shane Johnson (JIRA)

Entries not committed w/ DistLockingInterceptor and L1 caching disabled. ------------------------------------------------------------------------ Key: ISPN-962 URL: https://issues.jboss.org/browse/ISPN-962 Project: Infinispan Issue Type: Bug Components: Distributed Cache, Locking and Concurrency Affects Versions: 4.2.0.Final Reporter: Shane Johnson Assignee: Manik Surtani If you choose to disable the L1 cache (enabled=false AND onRehash=false) in distributed mode, the DistLockingInterceptor will NOT commit any invalidations due to a rehash back to the data container. The problem is in the commitEntry method. boolean doCommit = true; if (!dm.isLocal(entry.getKey())) { if (configuration.isL1CacheEnabled()) { dm.transformForL1(entry); } else { doCommit = false; } } if (doCommit) entry.commit(dataContainer); else entry.rollback(); For most commands, dm.isLocal returns TRUE and so the execution proceeds to commit. However, invalidation commands are unique in that they are executed on a remote node even though that node is NOT the owner of the entry. For that reason, the dm.isLocal returns FALSE and the execution proceeds to the L1 cache enabled check. If the L1 cache is disabled, the execution proceeds to set doCommit to false and rollback the invalidation. We have temporarily fixed this by updating the else block to check and see if the entry has been removed. If it has not, we set doCommit to false like it does now. Otherwise, we set it to true. To be honest, that was a safeguard in case we are missing something. I'm still not sure why we would ever want to set doCommit to false just because the L1 cache has been disabled. However, this change has fixed our problem with entries not being deleted from the original owners on a rehash. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
0
0 / 0

← Newer
1
...
19
20
21
22
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2011