May 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-7418) Add per-cache key/value type information

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-7418?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes commented on ISPN-7418: ----------------------------------------- After some brainstorming, the idea is to decouple the user MimeType setting from the internal wrappings and transformations and allow multiple storage types for a given MimeType. E.g., an UTF-8 cache may store it as a java.lang.String or as an encoded byte[ ]. A Cache API should allow to retrieve the value in both forms > Add per-cache key/value type information > ---------------------------------------- > > Key: ISPN-7418 > URL: https://issues.jboss.org/browse/ISPN-7418 > Project: Infinispan > Issue Type: Sub-task > Reporter: Galder Zamarreño > > This part of the transcoding enhancement is related to the changes required to the core cache code to force the cache to store keys and values of a certain type. > The type information should be defined via a MIME type, and should be configured by the user. > A cache can only have a single key+value type combination. A single cache will not support storing data of different key and/or value types. Amongst other reasons, this is done for space efficiency. > Once a cache can be configured with a specific key and value type, the user should be able to retrieve the value with an alternative MIME type. Behind the scenes, the cache should be able to transform the value from the give type to target type on the fly. > As suggested in the wiki, there should be the possibility for the key/value type to be implicitly determined by the key+value type passed in during the first cache write. The aim of this is to enable remote clients to decide what the key+value type are upon writing to the cache for the first time, and hence avoid cache pre-configuration. > Some transcoders might require additional configuration. The cache needs to be able to be configured with the necessary options to do on the fly transcoding for clients. E.g. schema for protobuf...etc. > An important aspect here is that consistent hashing should not be affected by transcoding. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7816) Remove default APP/MGMT user/pwd in docker image

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-7816?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-7816: ---------------------------------------- Instead, when the user provides no username or password, a warning message should be printed that the user might not be able to connect to the server. > Remove default APP/MGMT user/pwd in docker image > ------------------------------------------------ > > Key: ISPN-7816 > URL: https://issues.jboss.org/browse/ISPN-7816 > Project: Infinispan > Issue Type: Sub-task > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > > Docker image allows passing in APP_USER and APP_PASS as env variables easily, but it provides default usernames and passwords for both APP and MGMT. These defaults should be removed since they're a security risk. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7584) Rolling upgrade fails with "java.lang.ClassCastException: SimpleClusteredVersion cannot be cast to NumericVersion"

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-7584?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-7584: ----------------------------------------------- Jakub Senko <jsenko(a)redhat.com> changed the Status of [bug 1435617|https://bugzilla.redhat.com/show_bug.cgi?id=1435617] from POST to MODIFIED > Rolling upgrade fails with "java.lang.ClassCastException: SimpleClusteredVersion cannot be cast to NumericVersion" > ------------------------------------------------------------------------------------------------------------------ > > Key: ISPN-7584 > URL: https://issues.jboss.org/browse/ISPN-7584 > Project: Infinispan > Issue Type: Bug > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Labels: rolling_upgrade > Fix For: 9.0.0.CR4 > > > Cache configuration, both for source and target clusters: > {code:xml} > <replicated-cache name="test-cache" mode="SYNC" start="EAGER"> > <expiration interval="300000" lifespan="525600000000" /> > <locking isolation="REPEATABLE_READ" acquire-timeout="20000" concurrency-level="500" striping="false" /> > <transaction mode="NONE" /> > <string-keyed-jdbc-store datasource="java:jboss/datasources/OracleDS" passivation="false" preload="false" purge="false" shared="true"> > <property name="databaseType">ORACLE</property> > <string-keyed-table prefix="ISPN"> > <id-column name="id" type="VARCHAR(256)" /> > <data-column name="datum" type="BLOB" /> > <timestamp-column name="version" type="NUMBER" /> > </string-keyed-table> > </string-keyed-jdbc-store> > <remote-store cache="test-cache" hotrod-wrapping="true" socket-timeout="60000" tcp-no-delay="true" shared="true" passivation="false" purge="false" read-only="true"> > <remote-server outbound-socket-binding="source-cluster" /> > </remote-store> > </replicated-cache> > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6539) ClassCastException with Remote Cache Loader and GetWithMetadata

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-6539?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-6539: ----------------------------------------------- Jakub Senko <jsenko(a)redhat.com> changed the Status of [bug 1435617|https://bugzilla.redhat.com/show_bug.cgi?id=1435617] from POST to MODIFIED > ClassCastException with Remote Cache Loader and GetWithMetadata > --------------------------------------------------------------- > > Key: ISPN-6539 > URL: https://issues.jboss.org/browse/ISPN-6539 > Project: Infinispan > Issue Type: Bug > Components: Core, Loaders and Stores, Server > Affects Versions: 8.2.1.Final, 9.0.0.Alpha1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 9.0.0.Alpha2, 9.0.0.Final > > > A combination of remote cache loader and {{IsolationLevel.REPEATABLE_READ}} will cause a ClassCastException when doing a {{GetWithMetadata}}: > {noformat} > org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for messageId=11 > returned server error (status=0x85): java.lang.ClassCastException: > org.infinispan.container.entries.RepeatableReadEntry cannot be cast to > org.infinispan.container.entries.InternalCacheEntry > {noformat} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7818) Provide an unauthenticated server configuration

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-7818: -------------------------------------- Summary: Provide an unauthenticated server configuration Key: ISPN-7818 URL: https://issues.jboss.org/browse/ISPN-7818 Project: Infinispan Issue Type: Sub-task Reporter: Galder Zamarreño Assignee: Tristan Tarrant While authenticated should be on by default in server, users should have a quick way to use server in unauthenticated way for performance reasons...etc. So, provide a unauthenticated configuration in the server. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (IPROTO-30) Tool to generate protobuf schema from a sample JSON objects

by Adrian Nistor (JIRA)

Adrian Nistor created IPROTO-30: ----------------------------------- Summary: Tool to generate protobuf schema from a sample JSON objects Key: IPROTO-30 URL: https://issues.jboss.org/browse/IPROTO-30 Project: Infinispan ProtoStream Issue Type: Enhancement Reporter: Adrian Nistor -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5290) Better automatic merge for caches with enabled partition handling

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5290?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-5290: ------------------------------- Status: Open (was: New) > Better automatic merge for caches with enabled partition handling > ----------------------------------------------------------------- > > Key: ISPN-5290 > URL: https://issues.jboss.org/browse/ISPN-5290 > Project: Infinispan > Issue Type: Feature Request > Environment: JDG cluster with partitionHandling enabled > Reporter: Wolf-Dieter Fink > Assignee: Dan Berindei > Labels: cluster, clustering, infinispan, partition_handling > > At the moment there is no detection whether a node which join a cluster is one of the nodes which are known from the "last stable view" or not. > This will have the drawback that the cluster will be still in DEGRADED_MODE if there are some nodes restarted during the split-brain. > Assuming the cluster split is a power failure of some nodes the available nodes are DEGRADED as >=numOwners are lost. > If the failed nodes are restarted, let's say we have an application which use library mode in EAP, these instances are now identified as new nodes as the node-ID's are different. > If these nodes join the 'cluster' all the nodes are still degraded as the restarted are now known as different nodes and not as the lost nodes, so the cluster will not heal and come back to AVAILABLE. > There is a way to prevent some of the possibilities by using server hinting to ensure that at least one owner will survive. > But there are other cases where it would be good to have a different strategy to get the cluster back to AVAILABLE mode. > During the split-brain there is no way to continue as there is no possiblity to know whether "the other" part is gone or still acessable but not seen. > For a shared persistence it might be possible but there is a huge drawback for normal working state to synchronize that with locking and version columns. > If the node ID can be kept I see the following enhancements: > - with a shared persistence there should no data lost, if all nodes are back in the cluster it can go AVAILABLE and reload the missing entries > - for a 'side' cache the values are calculated or retrieved from other (slow) systems, so the cluster can be AVAILABLE and reload the entries > - In other cases there might be a WARNING/ERROR that all members are back from split, there is maybe some data lost and automaticaly or manually set back to AVAILABLE > It might be complicated to calculate this modes, but a configuration for partition-handling might give the possibility to the administrator to decide which behaviour is apropriate for a cache > i.e. > <partition-handling enabled="true" healing="HEALING.MODE"/> > where modes are > AVAILABLE_NO_WARNING back to available after all nodes from "last stable" are back > AVAILABLE_WARNING_DATALOST dto. but log a warning that some DATA can be lost > WARNING_DATALOST only a warning and a hint how to enable manually > NONE same as current behaviour (if necessary, maybe WARNING_DATALOST is similar or better) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5290) Better automatic merge for caches with enabled partition handling

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-5290?page=com.atlassian.jira.plugin.... ] Dan Berindei reassigned ISPN-5290: ---------------------------------- Assignee: Dan Berindei > Better automatic merge for caches with enabled partition handling > ----------------------------------------------------------------- > > Key: ISPN-5290 > URL: https://issues.jboss.org/browse/ISPN-5290 > Project: Infinispan > Issue Type: Feature Request > Environment: JDG cluster with partitionHandling enabled > Reporter: Wolf-Dieter Fink > Assignee: Dan Berindei > Labels: cluster, clustering, infinispan, partition_handling > > At the moment there is no detection whether a node which join a cluster is one of the nodes which are known from the "last stable view" or not. > This will have the drawback that the cluster will be still in DEGRADED_MODE if there are some nodes restarted during the split-brain. > Assuming the cluster split is a power failure of some nodes the available nodes are DEGRADED as >=numOwners are lost. > If the failed nodes are restarted, let's say we have an application which use library mode in EAP, these instances are now identified as new nodes as the node-ID's are different. > If these nodes join the 'cluster' all the nodes are still degraded as the restarted are now known as different nodes and not as the lost nodes, so the cluster will not heal and come back to AVAILABLE. > There is a way to prevent some of the possibilities by using server hinting to ensure that at least one owner will survive. > But there are other cases where it would be good to have a different strategy to get the cluster back to AVAILABLE mode. > During the split-brain there is no way to continue as there is no possiblity to know whether "the other" part is gone or still acessable but not seen. > For a shared persistence it might be possible but there is a huge drawback for normal working state to synchronize that with locking and version columns. > If the node ID can be kept I see the following enhancements: > - with a shared persistence there should no data lost, if all nodes are back in the cluster it can go AVAILABLE and reload the missing entries > - for a 'side' cache the values are calculated or retrieved from other (slow) systems, so the cluster can be AVAILABLE and reload the entries > - In other cases there might be a WARNING/ERROR that all members are back from split, there is maybe some data lost and automaticaly or manually set back to AVAILABLE > It might be complicated to calculate this modes, but a configuration for partition-handling might give the possibility to the administrator to decide which behaviour is apropriate for a cache > i.e. > <partition-handling enabled="true" healing="HEALING.MODE"/> > where modes are > AVAILABLE_NO_WARNING back to available after all nodes from "last stable" are back > AVAILABLE_WARNING_DATALOST dto. but log a warning that some DATA can be lost > WARNING_DATALOST only a warning and a hint how to enable manually > NONE same as current behaviour (if necessary, maybe WARNING_DATALOST is similar or better) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7814) Remove auth check in CacheDecodeContext

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-7814?page=com.atlassian.jira.plugin.... ] Galder Zamarreño reassigned ISPN-7814: -------------------------------------- Assignee: Tristan Tarrant (was: Galder Zamarreño) > Remove auth check in CacheDecodeContext > --------------------------------------- > > Key: ISPN-7814 > URL: https://issues.jboss.org/browse/ISPN-7814 > Project: Infinispan > Issue Type: Sub-task > Reporter: Galder Zamarreño > Assignee: Tristan Tarrant > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7810) Error executing the MassIndexer with security enabled

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-7810?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-7810: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.1.0.Alpha1 Resolution: Done > Error executing the MassIndexer with security enabled > ----------------------------------------------------- > > Key: ISPN-7810 > URL: https://issues.jboss.org/browse/ISPN-7810 > Project: Infinispan > Issue Type: Bug > Components: Embedded Querying, Security > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 9.1.0.Alpha1 > > > Exception thrown: > Caused by: java.lang.SecurityException: ISPN000287: Unauthorized access: subject 'null' lacks 'BULK_READ' permission > The mass indexer uses custom commands sent to one or more members, and the subject is not propagated, thus resulting in the error above -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 11 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 May 2017