February 2011 - infinispan-issues

[JBoss JIRA] Created: (ISPN-944) RemoteCacheManager.getCache() should be friendlier when cache does not exist

by Galder Zamarreño (JIRA)

RemoteCacheManager.getCache() should be friendlier when cache does not exist ---------------------------------------------------------------------------- Key: ISPN-944 URL: https://issues.jboss.org/browse/ISPN-944 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 When a Java Hot Rod client requests a non-existing cache, RemoteCacheManager throws a rather cryptic exception: {code}Feb 9, 2011 5:52:48 PM org.infinispan.client.hotrod.impl.operations.HotRodOperation checkForErrorsInResponseStatus 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] at org.infinispan.client.hotrod.impl.operations.HotRodOperation.checkForErrorsInResponseStatus(HotRodOperation.java:129) at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:98) at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:48) at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:27) at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:38) at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:166) at org.infinispan.CacheSupport.put(CacheSupport.java:28) at org.example.Sample.main(Sample.java:14){code} For 4.2.x, try to cleanup the exception so that it's a more friendly one. For 5.x, returning null would make more sense. However, I'd rather see this limitation going away (as indicated in ISPN-833) and that would stop getCache() from returning anything other than a running cache of some sort. Bottom line, the end result is to not return null, so not much point in having an intermdiate API change when we're gonna change it again soon after. To sum up, this jira will be limited to making the exception more user friendly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

3
9
0 / 0

[JBoss JIRA] Created: (ISPN-948) Support XML marshaling of Configuration instances

by Jürgen Kellerer (JIRA)

Support XML marshaling of Configuration instances ------------------------------------------------- Key: ISPN-948 URL: https://issues.jboss.org/browse/ISPN-948 Project: Infinispan Issue Type: Feature Request Components: Configuration Affects Versions: 4.2.1.CR3 Reporter: Jürgen Kellerer Assignee: Manik Surtani Fix For: 4.2.1.FINAL, 5.0.0.Final Infinispan supports a very flexible way of configuring caches using multiple levels of inheritance. While this is really nice, it is sometimes not easy to understand how exactly a particular cache was configured. (E.g. JPA is just one example where a cache configuration can be adjusted in several ways). JMX or debuggers help but may not always be available. What about allowing to convert a configuration instance back to XML to give a quick overview of the really applied settings. _(Optionally it might also be a nice little feature to implement a "toXmlString();" method or override the default and also make this available through JMX)_ JAXB annotations are already present on all configurable options but a couple getters and a @XmlRootElement annotation is missing that would allow to convert an existing instance back to XML. The effort in doing this should be rather low. --- This feature request may also fit with #ISPN-791 as it would allow to transfer cache configs using XML. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

3
16
0 / 0

[JBoss JIRA] Created: (ISPN-946) Fix build of Query module by aligning to latest Hibernate Search API

by Sanne Grinovero (JIRA)

Fix build of Query module by aligning to latest Hibernate Search API -------------------------------------------------------------------- Key: ISPN-946 URL: https://issues.jboss.org/browse/ISPN-946 Project: Infinispan Issue Type: Bug Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Critical Fix For: 5.1.0.BETA1 Fix compile error after HSEARCH-691 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

2
3
0 / 0

[JBoss JIRA] Created: (ISPN-952) Update query module to use new Hibernate Search SPI

by Sanne Grinovero (JIRA)

Update query module to use new Hibernate Search SPI --------------------------------------------------- Key: ISPN-952 URL: https://issues.jboss.org/browse/ISPN-952 Project: Infinispan Issue Type: Task Components: Querying Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 5.0.0.BETA1 Major API breaking in Search, need to keep this in sync. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

2
5
0 / 0

[JBoss JIRA] Created: (ISPN-923) Incorrect rehashing on merge

by Bela Ban (JIRA)

Incorrect rehashing on merge ---------------------------- Key: ISPN-923 URL: https://issues.jboss.org/browse/ISPN-923 Project: Infinispan Issue Type: Bug Components: Distributed Cache Affects Versions: 4.2.1.CR1 Reporter: Bela Ban Assignee: Manik Surtani When I simulate a network partition and subsequent merge, data added to the different nodes during the partition are only partially rehashed correctly. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

3
7
0 / 0

[JBoss JIRA] Created: (ISPN-932) Failed nodes remain in the topology.

by Shane Johnson (JIRA)

Failed nodes remain in the topology. ------------------------------------ Key: ISPN-932 URL: https://issues.jboss.org/browse/ISPN-932 Project: Infinispan Issue Type: Bug Components: Distributed Cache Reporter: Shane Johnson Assignee: Manik Surtani A node will remain in the cluster topology even if it never enters the RUNNING state. 1. CacheDelegate.start 2. ComponentRegistry.start 3. AbstractComponentRegistry.start 4. AbstractComponentRegistry.internalStart 5. AbstractComponentRegistry.handleLifecycleTransitionFailure The last start method will execute the @Start methods of the components. In the event that one of the methods throws an exception, the node will enter the FAILED state. The problem is that in distributed mode the node is added to the cluster topology before the rehashing takes place. If an exception is thrown during the rehash, the join still completes successfully. 1. Broadcast new consistent hash. 2. Get state. 3. Invalidate state. (This is in a finally block. Occurs even if get state fails.) 4. Complete join. (This is in a finally block. Occurs even if get state/invalidation fail.) There needs to be a way to remove a node from the topology if it enters the FAILED state. Or, perhaps wait to add it to the topology until it enters the RUNNING state. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

3
6
0 / 0

[JBoss JIRA] Created: (ISPN-937) hotrod server state transfer problem during startup

by Michal Linhard (JIRA)

hotrod server state transfer problem during startup --------------------------------------------------- Key: ISPN-937 URL: https://issues.jboss.org/browse/ISPN-937 Project: Infinispan Issue Type: Bug Components: Cache Server Affects Versions: 4.2.1.CR2 Reporter: Michal Linhard Assignee: Manik Surtani Attachments: hotrod-server-stdout.txt, hotrodconsole-0.0.1-SNAPSHOT-bin.zip, infinispan.xml This is something that happend to me when playing with hotrod servers. I've built infinispan distribution from source (mvn install -P distribution -DskipTests=true) unzipped infinispan-4.2.1.CR2-all.zip 2x to folders distro1 distro2 created 2 virtual ifaces 192.168.11.101 test1 192.168.11.102 test2 ran distro1/bin/startServer.sh -r hotrod -l test1 -c /home/mlinhard/dev/projects/infinispan/issues/infinispan.xml distro2/bin/startServer.sh -r hotrod -l test2 -c /home/mlinhard/dev/projects/infinispan/issues/infinispan.xml ran demo-hotrod-console hotrodconsole-0.0.1-SNAPSHOT/bin/console.sh test1 entered >put a a (which means put value "a" under key "a") the servers waited a bit and then server 2 wrote some errors to stdout (I guess after some timeout expired) client was still blocked, after some time produced ERROR: Invalid magic number. Expected a1 and received 50 attaching - binary version of demo-hotrod-console (source: https://github.com/mlinhard/demo-hotrod-console) - server 2 stdout - infinispan.xml I tried this with 4.2.1.CR1 and it worked. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

5
22
0 / 0

[JBoss JIRA] Created: (ISPN-272) recover from transaction failures

by Mircea Markus (JIRA)

recover from transaction failures --------------------------------- Key: ISPN-272 URL: https://jira.jboss.org/jira/browse/ISPN-272 Project: Infinispan Issue Type: Feature Request Components: Transactions Affects Versions: 5.0.0.GA Reporter: Mircea Markus Assignee: Manik Surtani We currently don't support any sort of recovery from transaction failures. E.g. tm.start(); database.delete(account); ispnCache.put(account); tm.commit(): At tm commit: -prepare is successful on both enlisted resources. - database.commit - fails What shall we do with the locks/state from ispnCache. Possible solutions: - configure to automatically commit/rollback after a timeout - keep locks on resources and allow manual intervention through JMX - others? -- 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, 1 month

4
19
0 / 0

[JBoss JIRA] Created: (ISPN-748) provide an API to expose core operations omitting return values as safe alternative to Flags

by Sanne Grinovero (JIRA)

provide an API to expose core operations omitting return values as safe alternative to Flags -------------------------------------------------------------------------------------------- Key: ISPN-748 URL: https://jira.jboss.org/browse/ISPN-748 Project: Infinispan Issue Type: Feature Request Components: Core API Reporter: Sanne Grinovero Assignee: Manik Surtani Priority: Minor Fix For: 5.0.0.BETA1, 5.0.0.Final On mailing list we discussed the possibility to provide the same methods as defined by Map but omitting return values. This would be useful for those cases in which return values are not needed, so that Infinispan can enable all possible optimizations to disregard retrieveing an appropriate return value. Several alternatives where proposed, and there's also an interesting proposal to do the same relating to async methods, and the combination of async+noReturn A suggestion: cache.noReturnValue().remote(K); //returns void and enables both flags SKIP_CACHE_LOAD and SKIP_REMOTE_LOOKUP. The advantage is that people refactoring code don't have to remember to adjust flags according to using the return value or not, or would at least get a compiler error in case of abuse of method; also Infinispan might introduce more optimizations in future and apply them without code changes for new flags arising. See all discussion started by: http://lists.jboss.org/pipermail/infinispan-dev/2010-October/006484.html -- 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, 1 month

3
3
0 / 0

[JBoss JIRA] Created: (ISPN-706) Enable Hot Rod server caches to be accessed without extra marshalling

by Galder Zamarreño (JIRA)

Enable Hot Rod server caches to be accessed without extra marshalling --------------------------------------------------------------------- Key: ISPN-706 URL: https://jira.jboss.org/browse/ISPN-706 Project: Infinispan Issue Type: Feature Request Components: Cache Server Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.0.0.BETA1, 5.0.0.Final People are starting to ask for this: Write to Hot Rod remotely and then being able to retrieve objects from the server side cache without any extra steps. At the moment, a marshalling layer is necessary so that those byte[] are converted into objects. -- 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, 1 month

2
5
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2011