February 2019 - infinispan-issues

[JBoss JIRA] (ISPN-2575) Key Transformer registration is required on all nodes of the cluster, in case of custom keys

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-2575?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-2575: ---------------------------------- Fix Version/s: 10.0.0.Beta3 (was: 10.0.0.Beta2) > Key Transformer registration is required on all nodes of the cluster, in case of custom keys > -------------------------------------------------------------------------------------------- > > Key: ISPN-2575 > URL: https://issues.jboss.org/browse/ISPN-2575 > Project: Infinispan > Issue Type: Enhancement > Components: Embedded Querying > Affects Versions: 5.2.0.Beta5 > Reporter: Anna Manukyan > Assignee: Adrian Nistor > Priority: Minor > Fix For: 10.0.0.Beta3 > > Attachments: ClusteredCacheTest.java > > > The case is the following: > I have a clustered cache on which I want to perform a search. I'm doing the following: > I'm initializing SearchManager on node1, I'm registering a custom key transformer for my key using the created searchmanager, but then when I'm trying to put data into the cache on node1 (which is in REPL_SYNC mode with cache on node2), I'm getting the exception: > java.lang.IllegalArgumentException: Indexing only works with entries keyed on Strings, primitives and classes that have the @Transformable annotation - you passed in a class org.infinispan.query.test.CustomKey3. Alternatively, see org.infinispan.query.SearchManager#registerKeyTransformer > When I'm initializing the SearchManager using node2 cache and register the keyTransformer on it as well, then everything works perfectly, even though I am not using the second created SearchManager. > The test which reproduces the issue is attached to the jira. Please see the test case: testSearchKeyTransformer() -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-8124) ServerNG: Initial implementation

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-8124?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-8124: ---------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > ServerNG: Initial implementation > -------------------------------- > > Key: ISPN-8124 > URL: https://issues.jboss.org/browse/ISPN-8124 > Project: Infinispan > Issue Type: Sub-task > Components: Server > Affects Versions: 9.1.0.Final > Reporter: Ryan Emerson > Assignee: Tristan Tarrant > Priority: Major > Fix For: 10.0.0.Beta1 > > > First implementation of the server. > This task focuses on organization of the server, directory layout, configuration, boot process and initial testing. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9957) InfinispanSubsystemXMLReader ignores configuration attribute on cache elements

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9957?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9957: ---------------------------------- Fix Version/s: 10.0.0.Beta3 (was: 10.0.0.Beta2) > InfinispanSubsystemXMLReader ignores configuration attribute on cache elements > ------------------------------------------------------------------------------ > > Key: ISPN-9957 > URL: https://issues.jboss.org/browse/ISPN-9957 > Project: Infinispan > Issue Type: Bug > Components: Integration > Affects Versions: 9.4.4.Final, 9.4.5.Final, 9.4.6.Final > Reporter: Oliver Lüttin > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.Beta3, 10.0.0.Final > > Attachments: example.cli > > > InfinispanSubsystemXMLReader ignores configuration attribute on local-cache elements. > The method > {code:java} > initPersistenceConfiguration(cacheConfigurationAddress, additionalConfigurationOperations); > {code} > , which is called from parseLocalCache, > adds an entry to additionalConfigurationOperations. > This causes the method > {code:java} > addCacheConfiguration(String cacheType, PathAddress containerAddress, Map<PathAddress, ModelNode> operations, > boolean configurationOnly, ModelNode cacheConfiguration, > Map<PathAddress, ModelNode> additionalConfigurationOperations, PathAddress cacheConfigurationAddress) > {code} > to call > {code:java} > addCacheConfiguration(String cacheType, PathAddress containerAddress, Map<PathAddress, ModelNode> operations, > boolean configurationOnly, ModelNode cacheConfiguration, > Map<PathAddress, ModelNode> additionalConfigurationOperations, PathAddress cacheConfigurationAddress) > {code} > without a configurationName. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9714) Update CacheNotifier to return CompletionStage

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9714?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9714: ---------------------------------- Fix Version/s: 10.0.0.Beta3 (was: 10.0.0.Beta2) > Update CacheNotifier to return CompletionStage > ---------------------------------------------- > > Key: ISPN-9714 > URL: https://issues.jboss.org/browse/ISPN-9714 > Project: Infinispan > Issue Type: Sub-task > Components: Core, Listeners > Reporter: William Burns > Assignee: William Burns > Priority: Major > Fix For: 10.0.0.Beta3 > > > We need to update CacheNotifier to return CompletionStage for all its appropriate methods. We also need to update all the internals to use these appropriately. > Not all notification usages may provide support non blocking, but our listener internals should support non blocking listeners for all. > The simplest way internally is to treat all current listeners as "alien" and invoke them in the notification thread pool. If it is sync we would wait for this task to complete. We would also now allow a listener to return a CompletionStage. If this is returned we will use this operate in a non blocking way. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9657) Multimap jar is not OSGi compliant

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9657?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9657: ---------------------------------- Fix Version/s: 10.0.0.Beta3 (was: 10.0.0.Beta2) > Multimap jar is not OSGi compliant > ---------------------------------- > > Key: ISPN-9657 > URL: https://issues.jboss.org/browse/ISPN-9657 > Project: Infinispan > Issue Type: Bug > Components: Multimap > Affects Versions: 9.4.0.Final > Reporter: Alain Picard > Assignee: Katia Aresti > Priority: Major > Fix For: 10.0.0.Beta3, 10.0.0.Final > > > Due to issues related to using the embedded jar (see [here|https://developer.jboss.org/message/986042#986042], when switching to individual jars, the multimap jar (infinispan-multimap-9.4.0.Final.jar) doesn't provide a valid OSGi manifest. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9624) Deprecate StreamingMarshaller interface

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9624?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9624: ---------------------------------- Fix Version/s: 10.0.0.Beta3 (was: 10.0.0.Beta2) > Deprecate StreamingMarshaller interface > --------------------------------------- > > Key: ISPN-9624 > URL: https://issues.jboss.org/browse/ISPN-9624 > Project: Infinispan > Issue Type: Sub-task > Components: Core > Affects Versions: 9.4.0.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.Beta3 > > > The StreamingMarshaller interface is no longer fit for purpose once we move away from jboss-marshalling as the ObjectOutput abstraction does not fit with non-serialization based marshallers. We should provide a simpler interface that simply allows reading/writing objects to a provided stream. This interface should then be exposed via the InitializationContext to store implementations. > {code:java} > @ThreadSafe > public interface StreamAwareMarshaller extends Marshaller { > /** > * Marshall an object to the {@link OutputStream} > * > * @param o the object to write to the {@link OutputStream} > * @param out the {@link OutputStream} to write the object to > * @throws IOException if the object cannot be marshalled to the {@link OutputStream} due to some I/O error > */ > void writeObject(Object o, OutputStream out) throws IOException; > /** > * Unmarshall an object from the {@link InputStream} > * > * @param in the {@link InputStream} to unmarshall an object from > * @return the unmarshalled object instance > * @throws IOException if unmarshalling cannot complete due to some I/O error > * @throws ClassNotFoundException if the class of the object trying to unmarshall is not found > */ > Object readObject(InputStream in) throws ClassNotFoundException, IOException; > } > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9621) Split global marshaller into Persistence and Internal marshaller

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9621?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9621: ---------------------------------- Fix Version/s: 10.0.0.Beta3 (was: 10.0.0.Beta2) > Split global marshaller into Persistence and Internal marshaller > ---------------------------------------------------------------- > > Key: ISPN-9621 > URL: https://issues.jboss.org/browse/ISPN-9621 > Project: Infinispan > Issue Type: Sub-task > Components: Core, Loaders and Stores > Affects Versions: 9.4.0.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.Beta3 > > > Currently the internal marshaller is used for marshalling key/value/metadata in store implementations. This means that it is possible for internal classes to be marshalled to a user store, which can cause compatibility issues if an internal classes serialization format changes (due to marshaller changes or addition/removal of fields). > We should separate the internal and persistence marshaller, only exposing the latter to stores via the InitializationContext. The persistence marshaller should only be able to serialize user key/values and the metadata/version data. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9620) Rolling Upgrade Marshaller Changes

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9620?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9620: ---------------------------------- Fix Version/s: 10.0.0.Beta3 (was: 10.0.0.Beta2) > Rolling Upgrade Marshaller Changes > ---------------------------------- > > Key: ISPN-9620 > URL: https://issues.jboss.org/browse/ISPN-9620 > Project: Infinispan > Issue Type: Enhancement > Components: Core, Loaders and Stores > Affects Versions: 9.4.0.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.0.0.Beta3 > > > In order to allow for compatibility between infinispan versions it is necessary for us to utilise a marshalling implementation at both the cluster (internal node-to-node communication) and persistence layer that is strictly defined but allows for future changes. This is necessary in order to facilitate both rolling and start/stop upgrades. Protocol buffers should be utilised as the wire/storage format, with protostream providing the implementation. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9533) ProtobufValueWrapper needs a more efficient key transformer when used as key in an indexed cache

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9533?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9533: ---------------------------------- Fix Version/s: 10.0.0.Beta3 (was: 10.0.0.Beta2) > ProtobufValueWrapper needs a more efficient key transformer when used as key in an indexed cache > ------------------------------------------------------------------------------------------------ > > Key: ISPN-9533 > URL: https://issues.jboss.org/browse/ISPN-9533 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Querying > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Priority: Major > Fix For: 10.0.0.Beta3 > > > DefaultTransformer is very very wasteful. Right now (9.x) we do not put protobuf keys in cache wrapped in a ProtobufValueWrapper but we'll start doing that once we implement query on keys. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ISPN-9463) Provide API to enlist the resource with TransactionManager

by Tristan Tarrant (Jira)

[ https://issues.jboss.org/browse/ISPN-9463?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9463: ---------------------------------- Fix Version/s: 10.0.0.Beta3 (was: 10.0.0.Beta2) > Provide API to enlist the resource with TransactionManager > ---------------------------------------------------------- > > Key: ISPN-9463 > URL: https://issues.jboss.org/browse/ISPN-9463 > Project: Infinispan > Issue Type: Enhancement > Components: Hot Rod, Remote Protocols, Transactions > Reporter: Ramesh Reddy > Assignee: Pedro Ruivo > Priority: Major > Fix For: 10.0.0.Beta3 > > > Currently, Infinispan will automatically enlist the transaction when a transaction is bound to the executing thread. However, in cases like Teiid where remote access to Infinispan access is wrapped with a resource-adapter (RAR) the resource adapter does the explicit enlisting or delisting. For this there needs to be API provided by Infinispan Cache like > {code} > RemoteCacheManager.getXaResource() > {code} > where it can access the XA resource. -- This message was sent by Atlassian Jira (v7.12.1#712002)

7 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues February 2019