October 2011 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-1336) Infinispan core fails to build with JDK 7

by Radoslav Husar (JIRA)

Infinispan core fails to build with JDK 7 ----------------------------------------- Key: ISPN-1336 URL: https://issues.jboss.org/browse/ISPN-1336 Project: Infinispan Issue Type: Bug Components: Build process Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Java version: 1.7.0, vendor: Oracle Corporation Reporter: Radoslav Husar Assignee: Manik Surtani "Or is it just me?" {code} [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.1:compile (default-compile) on project infinispan-core: Compilation failure [ERROR] error: Cannot read org.infinispan.util.logging package files, cause : java.io.FileNotFoundException: org.infinispan.util.logging/Log [ERROR] -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.3.1:compile (default-compile) on project infinispan-core: Compilation failure error: Cannot read org.infinispan.util.logging package files, cause : java.io.FileNotFoundException: org.infinispan.util.logging/Log at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:213) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59) at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183) at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156) at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196) at org.apache.maven.cli.MavenCli.main(MavenCli.java:141) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352) Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation failure error: Cannot read org.infinispan.util.logging package files, cause : java.io.FileNotFoundException: org.infinispan.util.logging/Log at org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:656) at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:128) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 19 more {code} Trying on master, last commit was commit e81e8a63fd68b85bc20b3304d62cc5fdcd75f327 Author: Galder Zamarreño Date: Fri Aug 12 13:35:50 2011 +0200 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

2
5
0 / 0

[JBoss JIRA] Created: (ISPN-1235) Per class(es) logging settings in testsuite

by Galder Zamarreño (JIRA)

Per class(es) logging settings in testsuite ------------------------------------------- Key: ISPN-1235 URL: https://issues.jboss.org/browse/ISPN-1235 Project: Infinispan Issue Type: Enhancement Components: Test Suite Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.2.0.Final Just brainstorming: It'd be very useful to have a way to run the testsuite with normal logging settings but have the ability to define one or more test classes as having TRACE on x.y.z. This could be useful for those elusive failures that only happen when the testsuite runs! Clearly, it'd need some programmatic magic to enable/disable the logging at runtime, but there's some benefit to all this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

1
2
0 / 0

[JBoss JIRA] Created: (ISPN-1015) Optimize HotRod client to match Memcached performance

by Dan Berindei (JIRA)

Optimize HotRod client to match Memcached performance ----------------------------------------------------- Key: ISPN-1015 URL: https://issues.jboss.org/browse/ISPN-1015 Project: Infinispan Issue Type: Task Reporter: Dan Berindei Assignee: Dan Berindei Load tests show the HotRod protocol performing worse than the Memcached client. Since the HotRod protocol should be easier to parse and we also have the extra topology information, this is quite surprising. We have analyzed the servers and seem to perform about the same, so we need to optimize the client. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

6
20
0 / 0

[JBoss JIRA] Created: (ISPN-303) Follow up Jopr demo ideas

by Galder Zamarreno (JIRA)

Follow up Jopr demo ideas ------------------------- Key: ISPN-303 URL: https://jira.jboss.org/jira/browse/ISPN-303 Project: Infinispan Issue Type: Task Components: JMX, reporting and management Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 4.1.0.BETA1 Ideas for a follow up Jopr demo: - Show ISPN-302 in action. - Heiko: About the monitoring schedules : in Administration->System Configuration->Templates you can also "predefine" this, so it gets applied to every new instance (and if wanted also to all existing instances). - Heiko: mention that 30 seconds is too too short for production -- 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

12 years, 5 months

3
5
0 / 0

[JBoss JIRA] (ISPN-1453) Infinispan CLI

by Tristan Tarrant (Created) (JIRA)

Infinispan CLI -------------- Key: ISPN-1453 URL: https://issues.jboss.org/browse/ISPN-1453 Project: Infinispan Issue Type: Feature Request Reporter: Tristan Tarrant Assignee: Tristan Tarrant Priority: Minor Infinispan needs an official CLI tool with the following features: - simple CRUD operations (get, put, delete) - queries (if the cache is indexed) - administrative tasks (eg. invoking JMX commands) Optional cool things: - run map/reduce scripts ??? - import/export to/from XML/CSV ??? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 6 months

6
7
0 / 0

[JBoss JIRA] Created: (ISPN-586) ManagedConnectionPool doesn't work in a transactional context

by Manik Surtani (JIRA)

ManagedConnectionPool doesn't work in a transactional context ------------------------------------------------------------- Key: ISPN-586 URL: https://jira.jboss.org/browse/ISPN-586 Project: Infinispan Issue Type: Bug Components: Loaders and Stores, Transactions Affects Versions: 4.1.0.CR2 Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.CR3 >From the reporter: "Anyways, what seems to be the real problem is that all the things that need to be persisted are saved in memory and then when the transaction is completing (either in prepare or commit phase) the loader attempts to get a connection from the datasource. Apparently this is illegal and throws an exception which is what causes the HeuristicMixedException further up the chain. This only fails when using a ManagedConnectionFactory. If I swap out a PooledConnectionFactory it works fine. I presume the managed version fails because it returns the same connection that is part of the active transaction for that thread and you can't perform new operations on that connection once the transaction is already in prepare or commit. This feels like a bit of a design flaw to me... I didn't see an obvious fix." This possibly has to do with the AbstractCacheStore doing the following in prepare(): " public void prepare(List<? extends Modification> mods, GlobalTransaction tx, boolean isOnePhase) throws CacheLoaderException { if (isOnePhase) { applyModifications(mods); } else { transactions.put(tx, mods); } } " and later during commit actually writing the changes to the store. This generic, "abstract" behaviour is intended for non-transactional data stores (such as a filesystem). Behaviour should be different when it comes to transactional data stores. -- 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

12 years, 7 months

8
25
0 / 0

[JBoss JIRA] Created: (ISPN-949) Have something like Hibernate's ResultTransformer for Query results

by Sanne Grinovero (JIRA)

Have something like Hibernate's ResultTransformer for Query results ------------------------------------------------------------------- Key: ISPN-949 URL: https://issues.jboss.org/browse/ISPN-949 Project: Infinispan Issue Type: Enhancement Components: Querying Reporter: Sanne Grinovero Assignee: Manik Surtani Priority: Minor Fix For: 6.0.0.Final Be able to transform an array of projected fields into a nice object. So return a List<CustomBean>, instead of a List<Object[]> -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 7 months

2
6
0 / 0

[JBoss JIRA] Created: (ISPN-893) Addtional attribute on @CacheEntryCreated to get on pre notifications only

by Sudheer Krishna (JIRA)

Addtional attribute on @CacheEntryCreated to get on pre notifications only ----------------------------------------------------------------------------- Key: ISPN-893 URL: https://issues.jboss.org/browse/ISPN-893 Project: Infinispan Issue Type: Enhancement Components: Listeners Affects Versions: 4.2.0.Final Environment: ALL Reporter: Sudheer Krishna Assignee: Manik Surtani Priority: Minor I may have usescases where i need notifications only when isPre = true. I was expecting a parameter to be taken by @CacheEntryCreated. But this doesnt seem to take any parametres. Aslo i would like similar values on @CacheEntryremoved also. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

4
17
0 / 0

[JBoss JIRA] Created: (ISPN-999) Support eventual consistency

by Manik Surtani (JIRA)

Support eventual consistency ---------------------------- Key: ISPN-999 URL: https://issues.jboss.org/browse/ISPN-999 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache, Locking and Concurrency Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 5.1.0.BETA1, 5.1.0.Final Essentially, it is about supporting eventual consistency in Infinispan. Currently Infinispan is strongly consistent when using synchronous distribution mode. Each data owner receives updates synchronously so anyone anywhere on the cluster doing a GET will see the correct value. The only exception is during a rehash (when a new node joins or leaves), that consistency is eventual since the GET may reach a new joiner who may not have applied state it receives from its neighbours yet. However this is hidden from users since the GET is sent to> 1 data owner and if an UnsureResponse is received (determined by the fact that a new joiner responds and the new joiner wouldn't have finished applying state), the caller thread waits for more definite responses. However, there is a use case for being eventually consistent as well: the main benefits being speed and partition tolerance. E.g., if we use distribution in asynchronous mode, the writes become *much* faster. However, anyone anywhere doing a GET will have to perform the GET on all data owners, and compare the versions of the data received to determine which is the latest. And if there is a conflict, to pass back all values to the user. So in terms of design, what I have in mind is: * All cache entries are versioned using vector clocks. One vector clock per node. * When a node performs a GET, the GET is sent to all data owners (concurrently), and the value + version is retrieved from each. * If the versions are all the same (or they can be "fast forwarded"), the value is returned * Otherwise, all potential values and their versions are returned * A resolve() API should be provided where application code may provide a "hint" as to which version should be "correct" - which will cause an update. * In terms of implementation, this will touch the DistributionInterceptor, InternalCacheEntry and relevant factories, some config code (since this should be consistency model should be configurable), and a new public interface. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

4
8
0 / 0

[JBoss JIRA] Created: (ISPN-1394) Investigate possibility of doing manual rehashing

by Galder Zamarreño (JIRA)

Investigate possibility of doing manual rehashing ------------------------------------------------- Key: ISPN-1394 URL: https://issues.jboss.org/browse/ISPN-1394 Project: Infinispan Issue Type: Feature Request Components: Distributed Cache Reporter: Galder Zamarreño Assignee: Manik Surtani Fix For: 5.2.0.FINAL Investigate the possibility of being able to do manual rehashing: - Approach used Dynamo (and Cassandra) - If you're adding 100 nodes, using manual rehashing could reduce traffic and make it more predictable - Could be called via JMX - But removing 10 nodes could be problematic. Unless number of owners is 11 or higher, which will guarantee that at least a copy of data is around -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

5
4
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2011