June 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3840) Test suite should continue when a test hasn't closed its cache managers

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3840?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3840: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Alpha5 (was: 7.0.0.Beta1) Resolution: Done > Test suite should continue when a test hasn't closed its cache managers > ----------------------------------------------------------------------- > > Key: ISPN-3840 > URL: https://issues.jboss.org/browse/ISPN-3840 > Project: Infinispan > Issue Type: Task > Security Level: Public(Everyone can see) > Components: Test Suite - Core > Affects Versions: 6.0.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: testsuite_stability > Fix For: 7.0.0.Alpha5 > > > The test listener has access to the cache managers that are still open, so it could fail the test and still close the cache managers. > Especially now that the server tests are back into the main project, the server tests should run even if a test in another module failed to close its cache managers. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1855) Accessing a non-distributed cache from a RemoteCacheManager can break topology updates

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-1855?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-1855: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Alpha5 (was: 7.0.0.Beta1) Resolution: Done > Accessing a non-distributed cache from a RemoteCacheManager can break topology updates > -------------------------------------------------------------------------------------- > > Key: ISPN-1855 > URL: https://issues.jboss.org/browse/ISPN-1855 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Remote Protocols > Affects Versions: 5.1.1.FINAL > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Fix For: 7.0.0.Alpha5 > > > RemoteCacheManager uses a single consistent hash to map requests to different servers, but caches on the server may have different CHs (or even no CH if the cache is not in distributed mode). > If the first request goes to a on-distributed cache, the client will never request an updated CH and so it will use a round robin strategy for routing request to all the caches. Obviously this is not optimal for distributed caches. > Each distributed cache can also have different members since 5.1, so it would be best if we kept a separate CH per cache on the client. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3530) The HotRod client should support a separate CH for each cache

by Pedro Ruivo (JIRA)

[ https://issues.jboss.org/browse/ISPN-3530?page=com.atlassian.jira.plugin.... ] Pedro Ruivo updated ISPN-3530: ------------------------------ Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Alpha5 (was: 7.0.0.Beta1) Resolution: Done > The HotRod client should support a separate CH for each cache > ------------------------------------------------------------- > > Key: ISPN-3530 > URL: https://issues.jboss.org/browse/ISPN-3530 > Project: Infinispan > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Remote Protocols > Affects Versions: 6.0.0.Alpha4 > Reporter: Dan Berindei > Assignee: Galder Zamarreño > Labels: hotrod, hotrod-java-client > Fix For: 7.0.0.Alpha5 > > > With asymmetric clusters, each cache can have its own consistent hash, so the primary owner of a key in one cache is not necessarily the owner in all the caches. Even with a symmetric cluster, the same client may be used to access both distributed and replicated caches, and those would certainly have a different CH. > In order to send the operations to the correct owner, the HotRod client should use a different CH for each cache. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3717) Add support for index-less queries using the EntryRetriever

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3717?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3717: ----------------------------------------------- Adrian Nistor <anistor(a)redhat.com> changed the Status of [bug 1104667|https://bugzilla.redhat.com/show_bug.cgi?id=1104667] from ON_QA to MODIFIED > Add support for index-less queries using the EntryRetriever > ----------------------------------------------------------- > > Key: ISPN-3717 > URL: https://issues.jboss.org/browse/ISPN-3717 > Project: Infinispan > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Embedded Querying, Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 6.3remotequeries, 630, roadmap > Fix For: 7.0.0.Alpha5, 7.0.0.Final > > > The current Lucene-based search implementation requires indexes for all fields that are referenced in queries. > Need to be able to query also for non-indexed fields. M/R is a potential implementation idea. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4377) Make receiving state for Hot Rod client listeners optional

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4377?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4377: ----------------------------------- Fix Version/s: 7.0.0.Final > Make receiving state for Hot Rod client listeners optional > ---------------------------------------------------------- > > Key: ISPN-4377 > URL: https://issues.jboss.org/browse/ISPN-4377 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Beta1, 7.0.0.Final > > > Receiving state for Hot Rod client listeners has a cost. Some users might not want to incur it, so it should be optional. By default, it should be enabled though for correctness. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4378) Inject marshaller into binary filter/converter instances

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-4378?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-4378: ----------------------------------- Fix Version/s: 7.0.0.Final > Inject marshaller into binary filter/converter instances > -------------------------------------------------------- > > Key: ISPN-4378 > URL: https://issues.jboss.org/browse/ISPN-4378 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Beta1, 7.0.0.Final > > > The Hot Rod server configuration now has a marshaller configured which is used to enable typed filter/converter parameter handling, and in order to enable typed filter/converter callbacks. > Note that this is separate from the cache marshaller, and separate from the compatibility marshaller, both of which, have different objectives. For example, you don't want to force compatibility to be enabled to be able to have typed converter/filters. This type conversion has been implementing using BinaryFilter/BinaryConverter classes which unmarshall the key/values and pass them to the filter/converter instances that the user has configured. > There's a problem with this when running in a cluster. Part of the cluster listener logic involves serializing these filter/converter instances and sending them to other nodes. However, these Binary* classes require the marshaller to do their job, which is not serializable. > However, the marshaller could be plugged to the Binary* classes if there was some kind of callback or something in each node that gets these classes replicated to, and it can initialise it properly. > Will has done some work with Adrian to make filter/converters cache components and be able to inject stuff in them. Check if that would work for this use case. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4276) Make JPA cache store work in Karaf

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4276?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4276: ----------------------------------------------- gsheldon(a)redhat.com changed the Status of [bug 1067725|https://bugzilla.redhat.com/show_bug.cgi?id=1067725] from ON_QA to MODIFIED > Make JPA cache store work in Karaf > ---------------------------------- > > Key: ISPN-4276 > URL: https://issues.jboss.org/browse/ISPN-4276 > Project: Infinispan > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 7.0.0.Alpha3 > Reporter: Martin Gencur > Assignee: Ion Savin > Labels: 63gablocker > Fix For: 7.0.0.Alpha5 > > > The JPA cache store does not currently work in Karaf. There are several thing to make it work in OSGi: > * use hibernate-osgi dependency, and possibly change some other dependencies > * JpaStoreConfigurationParser70 should be exposed as a service in Blueprint > * EntityManagerFactory should be obtained from the service registry, similar to https://github.com/hibernate/hibernate-orm/tree/master/documentation/src/... -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4385) Document installation process for OSGi containers

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4385?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4385: ----------------------------------------------- gsheldon(a)redhat.com changed the Status of [bug 1067725|https://bugzilla.redhat.com/show_bug.cgi?id=1067725] from ON_QA to MODIFIED > Document installation process for OSGi containers > ------------------------------------------------- > > Key: ISPN-4385 > URL: https://issues.jboss.org/browse/ISPN-4385 > Project: Infinispan > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ion Savin > Assignee: Ion Savin > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4385) Document installation process for OSGi containers

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4385?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4385: ----------------------------------------------- gsheldon(a)redhat.com changed the Status of [bug 1067725|https://bugzilla.redhat.com/show_bug.cgi?id=1067725] from MODIFIED to ON_QA > Document installation process for OSGi containers > ------------------------------------------------- > > Key: ISPN-4385 > URL: https://issues.jboss.org/browse/ISPN-4385 > Project: Infinispan > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ion Savin > Assignee: Ion Savin > -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4276) Make JPA cache store work in Karaf

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4276?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4276: ----------------------------------------------- gsheldon(a)redhat.com changed the Status of [bug 1067725|https://bugzilla.redhat.com/show_bug.cgi?id=1067725] from MODIFIED to ON_QA > Make JPA cache store work in Karaf > ---------------------------------- > > Key: ISPN-4276 > URL: https://issues.jboss.org/browse/ISPN-4276 > Project: Infinispan > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Affects Versions: 7.0.0.Alpha3 > Reporter: Martin Gencur > Assignee: Ion Savin > Labels: 63gablocker > Fix For: 7.0.0.Alpha5 > > > The JPA cache store does not currently work in Karaf. There are several thing to make it work in OSGi: > * use hibernate-osgi dependency, and possibly change some other dependencies > * JpaStoreConfigurationParser70 should be exposed as a service in Blueprint > * EntityManagerFactory should be obtained from the service registry, similar to https://github.com/hibernate/hibernate-orm/tree/master/documentation/src/... -- This message was sent by Atlassian JIRA (v6.2.6#6264)

11 years, 5 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2014