June 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-2183) Add the ability to fetch a set of keys at once (getAll)

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-2183?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-2183: -------------------------------- Labels: 64QueryBlockers (was: ) > Add the ability to fetch a set of keys at once (getAll) > ------------------------------------------------------- > > Key: ISPN-2183 > URL: https://issues.jboss.org/browse/ISPN-2183 > Project: Infinispan > Issue Type: Feature Request > Components: Core > Reporter: Mircea Markus > Assignee: Manik Surtani > Priority: Minor > Labels: 64QueryBlockers > > When a transaction knows in advance about the set of keys it needs to read, this cache.getAll(k1,k2,..kn) method can bring a some performance improvement: > 1. all the keys can be fetched from remote nodes in parallel > 2. keys that map to the same node can be grouped and fetched in the same RPC request > > Note that 1. can be be achieved even at this time by using Cache.getAsync(K) method - that's not as elegant though as it requires the user to write the code the code that waits on the Future objects that are returned. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4358) Add sorting support for the distributed iterator

by Mircea Markus (JIRA)

Mircea Markus created ISPN-4358: ----------------------------------- Summary: Add sorting support for the distributed iterator Key: ISPN-4358 URL: https://issues.jboss.org/browse/ISPN-4358 Project: Infinispan Issue Type: Feature Request Reporter: Mircea Markus Assignee: Mircea Markus Distributed iterator is used by non-indexed querying. In order to efficiently support the sorting functionality querying provides, we need support from the distributed iterator. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4358) Add sorting support for the distributed iterator

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-4358?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-4358: -------------------------------- Assignee: William Burns (was: Mircea Markus) > Add sorting support for the distributed iterator > ------------------------------------------------- > > Key: ISPN-4358 > URL: https://issues.jboss.org/browse/ISPN-4358 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: William Burns > > Distributed iterator is used by non-indexed querying. > In order to efficiently support the sorting functionality querying provides, we need support from the distributed iterator. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4357) Use a specific cache for managing protofiles

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-4357?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-4357: -------------------------------- Summary: Use a specific cache for managing protofiles (was: Use a specific cache for holding protofiles) > Use a specific cache for managing protofiles > -------------------------------------------- > > Key: ISPN-4357 > URL: https://issues.jboss.org/browse/ISPN-4357 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Adrian Nistor > Labels: 64QueryBlockers > > Portofile defining schema should be held in a separate cache. This would allow users to manage schema from a hotrod client. Security should be considered as well. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4357) Use a specific cache for holding protofiles

by Mircea Markus (JIRA)

Mircea Markus created ISPN-4357: ----------------------------------- Summary: Use a specific cache for holding protofiles Key: ISPN-4357 URL: https://issues.jboss.org/browse/ISPN-4357 Project: Infinispan Issue Type: Feature Request Reporter: Mircea Markus Assignee: Mircea Markus Portofile defining schema should be held in a separate cache. This would allow users to manage schema from a hotrod client. Security should be considered as well. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4357) Use a specific cache for holding protofiles

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-4357?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-4357: -------------------------------- Assignee: Adrian Nistor (was: Mircea Markus) > Use a specific cache for holding protofiles > ------------------------------------------- > > Key: ISPN-4357 > URL: https://issues.jboss.org/browse/ISPN-4357 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Adrian Nistor > Labels: 64QueryBlockers > > Portofile defining schema should be held in a separate cache. This would allow users to manage schema from a hotrod client. Security should be considered as well. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4357) Use a specific cache for holding protofiles

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-4357?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-4357: -------------------------------- Labels: 64QueryBlockers (was: ) > Use a specific cache for holding protofiles > ------------------------------------------- > > Key: ISPN-4357 > URL: https://issues.jboss.org/browse/ISPN-4357 > Project: Infinispan > Issue Type: Feature Request > Reporter: Mircea Markus > Assignee: Adrian Nistor > Labels: 64QueryBlockers > > Portofile defining schema should be held in a separate cache. This would allow users to manage schema from a hotrod client. Security should be considered as well. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4354) Unable to use custom keys/values with clustered caches in OSGi

by Ion Savin (JIRA)

[ https://issues.jboss.org/browse/ISPN-4354?page=com.atlassian.jira.plugin.... ] Ion Savin commented on ISPN-4354: --------------------------------- The classloader used to load these classes by default is the classloader of GlobalConfigurationBuilder which should be the classloader of the org.infinispan.core bundle. At the moment just the org.infinispan.commons bundle is using Dynamic-Import: * in the header. It will need to be added to the core bundle also. The stack reports org.jgroups as the bundle trying to load the class because the tests repackage the core jar and make it a fragment of the jgroups bundle. > Unable to use custom keys/values with clustered caches in OSGi > -------------------------------------------------------------- > > Key: ISPN-4354 > URL: https://issues.jboss.org/browse/ISPN-4354 > Project: Infinispan > Issue Type: Bug > Affects Versions: 7.0.0.Alpha4 > Reporter: Martin Gencur > Assignee: Ion Savin > Priority: Critical > Labels: 630 > Attachments: custom-objects-stacktrace.txt, CustomObjectsReplicatedCacheTest.java > > > JGroups cannot find custom classes that are used as keys or values. The stacktrace looks like this: > {code} > Caused by: java.lang.ClassNotFoundException: org.infinispan.it.osgi.tx.CustomObjectsReplicatedCacheTest$Person not found by org.jgroups [61] > at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1460) > at org.apache.felix.framework.BundleWiringImpl.access$400(BundleWiringImpl.java:72) > at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1843) > at java.lang.ClassLoader.loadClass(ClassLoader.java:356) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:266) > at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:131) > at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:112) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:943) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1239) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) > at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41) > at org.infinispan.container.entries.ImmortalCacheEntry$Externalizer.readObject(ImmortalCacheEntry.java:152) > at org.infinispan.container.entries.ImmortalCacheEntry$Externalizer.readObject(ImmortalCacheEntry.java:142) > at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:406) > at org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:213) > at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:148) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:351) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) > at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41) > at org.infinispan.marshall.exts.ListExternalizer.readObject(ListExternalizer.java:62) > at org.infinispan.marshall.exts.ListExternalizer.readObject(ListExternalizer.java:26) > at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:406) > at org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:213) > at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:148) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:351) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) > at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41) > at org.infinispan.statetransfer.StateChunk$Externalizer.readObject(StateChunk.java:88) > at org.infinispan.statetransfer.StateChunk$Externalizer.readObject(StateChunk.java:65) > at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:406) > at org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:213) > at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:148) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:351) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) > at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41) > at org.infinispan.marshall.exts.ListExternalizer.readObject(ListExternalizer.java:62) > at org.infinispan.marshall.exts.ListExternalizer.readObject(ListExternalizer.java:26) > at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:406) > at org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:213) > at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:148) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:351) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) > at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41) > at org.infinispan.marshall.exts.ReplicableCommandExternalizer.readParameters(ReplicableCommandExternalizer.java:100) > at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.readObject(CacheRpcCommandExternalizer.java:153) > at org.infinispan.marshall.exts.CacheRpcCommandExternalizer.readObject(CacheRpcCommandExternalizer.java:64) > at org.infinispan.marshall.core.ExternalizerTable$ExternalizerAdapter.readObject(ExternalizerTable.java:406) > at org.infinispan.marshall.core.ExternalizerTable.readObject(ExternalizerTable.java:213) > at org.infinispan.marshall.core.JBossMarshaller$ExternalizerTableProxy.readObject(JBossMarshaller.java:148) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:351) > at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209) > at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41) > at org.infinispan.commons.marshall.jboss.AbstractJBossMarshaller.objectFromObjectStream(AbstractJBossMarshaller.java:135) > at org.infinispan.marshall.core.VersionAwareMarshaller.objectFromByteBuffer(VersionAwareMarshaller.java:101) > at org.infinispan.commons.marshall.AbstractDelegatingMarshaller.objectFromByteBuffer(AbstractDelegatingMarshaller.java:80) > at org.infinispan.remoting.transport.jgroups.MarshallerAdapter.objectFromBuffer(MarshallerAdapter.java:28) > at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:204) > ... 24 more > {code} -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3718) Select which protobuf fields to index

by Mircea Markus (JIRA)

[ https://issues.jboss.org/browse/ISPN-3718?page=com.atlassian.jira.plugin.... ] Mircea Markus updated ISPN-3718: -------------------------------- Labels: 64QueryBlockers (was: ) > Select which protobuf fields to index > ------------------------------------- > > Key: ISPN-3718 > URL: https://issues.jboss.org/browse/ISPN-3718 > Project: Infinispan > Issue Type: Feature Request > Components: Embedded Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Labels: 64QueryBlockers > > Currently we index all fields. An interesting idea is to use a custom protobuf Option (see 'Custom Options' section here https://developers.google.com/protocol-buffers/docs/proto) to indicate which message types and specifically which fields should be indexed, similar to Hibernate Search annotations. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4347) Remove Geronimo from parent pom as global dependency

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-4347?page=com.atlassian.jira.plugin.... ] Martin Gencur updated ISPN-4347: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/2605 > Remove Geronimo from parent pom as global dependency > ---------------------------------------------------- > > Key: ISPN-4347 > URL: https://issues.jboss.org/browse/ISPN-4347 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Core, Test Suite - Query > Reporter: Sanne Grinovero > Assignee: Martin Gencur > Fix For: 7.0.0.Alpha5 > > > Geronimo is now being added to the classpath of all modules, creating ambiguity both as a JTA implementor and by providing duplicate definitions of the API. > We should actually never add dependency to the parent of all modules, as a module can not exclude it. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 10 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2014