[JBoss JIRA] (ISPN-2529) Simplify Query API
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2529?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2529:
--------------------------------
Fix Version/s: 6.0.0.Beta1
6.0.0.Final
(was: 6.0.0.Alpha1)
> Simplify Query API
> ------------------
>
> Key: ISPN-2529
> URL: https://issues.jboss.org/browse/ISPN-2529
> Project: Infinispan
> Issue Type: Enhancement
> Components: Querying
> Reporter: Sanne Grinovero
> Assignee: Sanne Grinovero
> Labels: stable_embedded_query
> Fix For: 6.0.0.Beta1, 6.0.0.Final
>
>
> I'm not sure exactly how we might be able to expose this but the amount of steps and builders currently needed to run a single query is a bit long.
> Let's have a look at it and make the steps needed to run a query simpler.
> Would also be nice to be able to abstract the Query definition in such a way that indexes are used only if they exist, but otherwise fall back to map/reduce or generate the indexes at runtime.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (ISPN-1116) Version-aware InternalCacheEntries
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-1116?page=com.atlassian.jira.plugin.... ]
Mircea Markus resolved ISPN-1116.
---------------------------------
Fix Version/s: (was: 6.0.0.Final)
Resolution: Out of Date
Metadata.*CacheEntry aggregates an Metadata which can contain a version
> Version-aware InternalCacheEntries
> ----------------------------------
>
> Key: ISPN-1116
> URL: https://issues.jboss.org/browse/ISPN-1116
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core API
> Reporter: Manik Surtani
> Assignee: Manik Surtani
> Priority: Critical
>
> This is to support a number of things including eventual consistency as well as tombstones for deleted entries. Further, this version would need to be used when doing MVCC concurrent write comparisons for write skews (and not just a reference check which is done at the moment).
> This also would need to be able to use versions provided in a value's metadata (see ISPN-1103)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (ISPN-2851) add log.info when using backported concurrent hash map
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2851?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2851:
--------------------------------
Fix Version/s: (was: 6.0.0.Final)
> add log.info when using backported concurrent hash map
> ------------------------------------------------------
>
> Key: ISPN-2851
> URL: https://issues.jboss.org/browse/ISPN-2851
> Project: Infinispan
> Issue Type: Enhancement
> Components: Core API
> Affects Versions: 5.2.2.Final
> Reporter: Mathieu Lachance
> Assignee: Galder Zamarreño
> Priority: Minor
>
> it would be nice if there was a bit more logging information when using backported concurrent hash map since it is activation is not only based on the :
> Boolean.getBoolean("infinispan.unsafe.allow_jdk8_chm");
> property as we could think.
> static {
> boolean sunIncompatibleJvm;
> boolean jdk8;
> boolean allowExperimentalMap = Boolean.getBoolean("infinispan.unsafe.allow_jdk8_chm");
> try {
> Class.forName("com.sun.unsafe.Unsafe");
> sunIncompatibleJvm = false;
> } catch (ClassNotFoundException e) {
> sunIncompatibleJvm = true;
> }
>
> try {
> Class.forName("java.util.concurrent.atomic.LongAdder");
> jdk8 = true;
> } catch (ClassNotFoundException e) {
> jdk8 = false;
> }
> if (jdk8 || sunIncompatibleJvm || !allowExperimentalMap){
> MAP_CREATOR = new JdkConcurrentMapCreator();
> }
> else{
> MAP_CREATOR = new BackportedV8ConcurrentMapCreator();
> logger.info("using backported jdk8 concurrent hash map implementation");
> }
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (ISPN-2761) Write tests for the RHQ plugin
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-2761?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-2761:
--------------------------------
Fix Version/s: (was: 6.0.0.Final)
> Write tests for the RHQ plugin
> ------------------------------
>
> Key: ISPN-2761
> URL: https://issues.jboss.org/browse/ISPN-2761
> Project: Infinispan
> Issue Type: Task
> Components: JMX, reporting and management
> Affects Versions: 5.2.0.CR3
> Reporter: Dan Berindei
> Assignee: Tristan Tarrant
>
> The RHQ plugin doesn't have any functional tests at the moment. The InfinispanRhqTest class just starts a cache manager and waits for someone to start RHQ manually and connect to it.
> Instead we should have a test that creates a {{CacheComponent}} instance and invokes several operations on it, reads attributes etc.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[JBoss JIRA] (ISPN-19) different cache manager impl : LocalCacheManager and ClusteredCacheManager
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-19?page=com.atlassian.jira.plugin.sy... ]
Mircea Markus updated ISPN-19:
------------------------------
Fix Version/s: (was: 6.0.0.Final)
> different cache manager impl : LocalCacheManager and ClusteredCacheManager
> --------------------------------------------------------------------------
>
> Key: ISPN-19
> URL: https://issues.jboss.org/browse/ISPN-19
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core API
> Reporter: Mircea Markus
> Assignee: Manik Surtani
>
> consider having two CacheManagers impl: LocalCacheaManager and ClusteredCacheManager.
> This is in order to offer a more clear API to the user, who might want to use a specific cache manager.
> Currently, this is achieved through usage of GlobalConfiguration.getClusterDefault()/getNonClusterDefault(), but this is not very clear to the user.
> Also, after trying to create an replicated cache on a cache manager build on an "getNonClusterDefault" config, there will be an unclear error message:
> ""Caused by: java.lang.reflect.InvocationTargetException
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.horizon.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:129)
> ... 35 more
> Caused by: java.lang.NullPointerException
> at org.horizon.statetransfer.StateTransferManagerImpl.start(StateTransferManagerImpl.java:116)
> ... 40 more
> Error should be more specific, something like: "You're not allowed to deploy an clustered cache on an local cache manager".
> public void testCreateReplicatedCacheOnLocalCM() {
> GlobalConfiguration globalConfiguration = GlobalConfiguration.getNonClusteredDefault();
> globalConfiguration.setAllowDuplicateDomains(true);
> CacheManager dcm1 = new DefaultCacheManager(globalConfiguration);
> CacheManager dcm2 = new DefaultCacheManager(globalConfiguration);
> Configuration conf = new Configuration();
> conf.setCacheMode(Configuration.CacheMode.REPL_SYNC);
> dcm1.defineCache("replicated", conf);
> dcm2.defineCache("replicated", conf);
> dcm1.getCache("replicated");
> dcm2.getCache("replicated");
> }
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months