October 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-8427) Support for non-String keys in the rest server

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-8427?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-8427: ------------------------------------ Description: The rest server assumes keys are always String, causing limited interoperability between remote endpoints. When a cache is written via Hot Rod, by default keys will be stored as marshalled {{byte[]}} via {{JBossMarshaller}} (the default marshaller), or via UTF-8 in case the {{UT8Marshaller}} is chosen. The Rest server should accept keys in different formats than String, using an encoding for byte[] values like Base64, and pass in an special header with the key media type so that the server can use it. With this capability, compat mode could be avoided when writing from Hot Rod and reading from Rest and vice versa was: The rest server assumes keys are always String, causing limited interoperability between remote endpoints. When a cache is written via Hot Rod, by default keys will be stored as marshalled {{java.lang.String}} via {{JBossMarshaller}} (the default marshaller), or via UTF-8 in case the {{UT8Marshaller}} is chosen. The Rest server should accept keys in different formats than String, using an encoding for byte[] values like Base64, and pass in an special header with the key media type so that the server can use it. With this capability, compat mode could be avoided when writing from Hot Rod and reading from Rest and vice versa > Support for non-String keys in the rest server > ---------------------------------------------- > > Key: ISPN-8427 > URL: https://issues.jboss.org/browse/ISPN-8427 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 9.2.0.Alpha1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > > The rest server assumes keys are always String, causing limited interoperability between remote endpoints. > When a cache is written via Hot Rod, by default keys will be stored as marshalled {{byte[]}} via {{JBossMarshaller}} (the default marshaller), or via UTF-8 in case the {{UT8Marshaller}} is chosen. > The Rest server should accept keys in different formats than String, using an encoding for byte[] values like Base64, and pass in an special header with the key media type so that the server can use it. > With this capability, compat mode could be avoided when writing from Hot Rod and reading from Rest and vice versa -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8427) Support for non-String keys in the rest server

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-8427?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-8427: ------------------------------------ Description: The rest server assumes keys are always String, causing limited interoperability between remote endpoints. When a cache is written via Hot Rod, by default keys will be stored as {{byte[]}} produced via {{JBossMarshaller}} (the default marshaller), or via UTF-8 in case the {{UT8Marshaller}} is chosen. The Rest server should accept keys in different formats than String, using an encoding for byte[] values like Base64, and pass in an special header with the key media type so that the server can use it. With this capability, compat mode could be avoided when writing from Hot Rod and reading from Rest and vice versa was: The rest server assumes keys are always String, causing limited interoperability between remote endpoints. When a cache is written via Hot Rod, by default keys will be stored as marshalled {{byte[]}} via {{JBossMarshaller}} (the default marshaller), or via UTF-8 in case the {{UT8Marshaller}} is chosen. The Rest server should accept keys in different formats than String, using an encoding for byte[] values like Base64, and pass in an special header with the key media type so that the server can use it. With this capability, compat mode could be avoided when writing from Hot Rod and reading from Rest and vice versa > Support for non-String keys in the rest server > ---------------------------------------------- > > Key: ISPN-8427 > URL: https://issues.jboss.org/browse/ISPN-8427 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 9.2.0.Alpha1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > > The rest server assumes keys are always String, causing limited interoperability between remote endpoints. > When a cache is written via Hot Rod, by default keys will be stored as {{byte[]}} produced via {{JBossMarshaller}} (the default marshaller), or via UTF-8 in case the {{UT8Marshaller}} is chosen. > The Rest server should accept keys in different formats than String, using an encoding for byte[] values like Base64, and pass in an special header with the key media type so that the server can use it. > With this capability, compat mode could be avoided when writing from Hot Rod and reading from Rest and vice versa -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8427) Support for non-String keys in the rest server

by Gustavo Fernandes (JIRA)

Gustavo Fernandes created ISPN-8427: --------------------------------------- Summary: Support for non-String keys in the rest server Key: ISPN-8427 URL: https://issues.jboss.org/browse/ISPN-8427 Project: Infinispan Issue Type: Enhancement Components: Server Affects Versions: 9.2.0.Alpha1 Reporter: Gustavo Fernandes The rest server assumes keys are always String, causing interoperability between remote endpoints limited. When a cache is written via Hot Rod, by default keys will be stored as marshalled {{java.lang.String}} via {{JBossMarshaller}} (the default marshaller), or via UTF-8 in case the {{UT8Marshaller}} is chosen. The Rest server should accept keys in different formats than String, using an encoding for byte[] values like Base64, and pass in an special header with the key media type so that the server can use it. With this capability, compat mode could be avoided when writing from Hot Rod and reading from Rest and vice versa -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8427) Support for non-String keys in the rest server

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-8427?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes reassigned ISPN-8427: --------------------------------------- Assignee: Gustavo Fernandes > Support for non-String keys in the rest server > ---------------------------------------------- > > Key: ISPN-8427 > URL: https://issues.jboss.org/browse/ISPN-8427 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Affects Versions: 9.2.0.Alpha1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > > The rest server assumes keys are always String, causing interoperability between remote endpoints limited. > When a cache is written via Hot Rod, by default keys will be stored as marshalled {{java.lang.String}} via {{JBossMarshaller}} (the default marshaller), or via UTF-8 in case the {{UT8Marshaller}} is chosen. > The Rest server should accept keys in different formats than String, using an encoding for byte[] values like Base64, and pass in an special header with the key media type so that the server can use it. > With this capability, compat mode could be avoided when writing from Hot Rod and reading from Rest and vice versa -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8426) Some tests try to use non-existing IBM Keystore

by Sebastian Łaskawiec (JIRA)

Sebastian Łaskawiec created ISPN-8426: ----------------------------------------- Summary: Some tests try to use non-existing IBM Keystore Key: ISPN-8426 URL: https://issues.jboss.org/browse/ISPN-8426 Project: Infinispan Issue Type: Bug Affects Versions: 9.2.0.Alpha1 Reporter: Sebastian Łaskawiec Assignee: Sebastian Łaskawiec -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8425) PartitionHandlingConfiguration inconsistent with documentaiton

by Ryan Emerson (JIRA)

Ryan Emerson created ISPN-8425: ---------------------------------- Summary: PartitionHandlingConfiguration inconsistent with documentaiton Key: ISPN-8425 URL: https://issues.jboss.org/browse/ISPN-8425 Project: Infinispan Issue Type: Bug Components: Documentation-Core Reporter: Ryan Emerson Assignee: Ryan Emerson Fix For: 9.1.2.Final, 9.2.0.Alpha2 Currently the docs state that the default merge policy is PREFERRED_NON_NULL, but it's currently null. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8424) Cluster does not recover after killing a pod on OpenShift

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-8424?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-8424: ----------------------------------- Attachment: datagrid-3-kg593.log datagrid-3-tzh6h.log > Cluster does not recover after killing a pod on OpenShift > --------------------------------------------------------- > > Key: ISPN-8424 > URL: https://issues.jboss.org/browse/ISPN-8424 > Project: Infinispan > Issue Type: Bug > Components: Core, JMX, reporting and management > Affects Versions: 9.1.0.Final > Reporter: Galder Zamarreño > Attachments: datagrid-3-kg593.log, datagrid-3-tzh6h.log > > > To replicate issue, follow instructions in [here|https://github.com/infinispan-demos/streaming-data-kubernetes/blob/m...] without changing the code. > Once you have injector working and you connect from the dashboard, do the following: > {code} > $ docker ps > ... > // find id for one of the infinispan server nodes > ... > $ docker rm -f <container_id> > {code} > The container will be killed but the other nodes do not manage to recover the cluster and install the new formation. It seems to enter an endless loop... See attached logs. > I suspect the cluster stats requests that appear in the logs come from the management console. > I don't yet have TRACE logs but I'll try to replicate with TRACE later. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8424) Cluster does not recover after killing a pod on OpenShift

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-8424: -------------------------------------- Summary: Cluster does not recover after killing a pod on OpenShift Key: ISPN-8424 URL: https://issues.jboss.org/browse/ISPN-8424 Project: Infinispan Issue Type: Bug Components: Core, JMX, reporting and management Affects Versions: 9.1.0.Final Reporter: Galder Zamarreño To replicate issue, follow instructions in [here|https://github.com/infinispan-demos/streaming-data-kubernetes/blob/m...] without changing the code. Once you have injector working and you connect from the dashboard, do the following: {code} $ docker ps ... // find id for one of the infinispan server nodes ... $ docker rm -f <container_id> {code} The container will be killed but the other nodes do not manage to recover the cluster and install the new formation. It seems to enter an endless loop... See attached logs. I suspect the cluster stats requests that appear in the logs come from the management console. I don't yet have TRACE logs but I'll try to replicate with TRACE later. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8423) Remove metadata size integer in cases where we know the size

by William Burns (JIRA)

William Burns created ISPN-8423: ----------------------------------- Summary: Remove metadata size integer in cases where we know the size Key: ISPN-8423 URL: https://issues.jboss.org/browse/ISPN-8423 Project: Infinispan Issue Type: Sub-task Reporter: William Burns Assignee: William Burns We store a type with the other metadata. This tells us whether the entry is IMMORTAL, MORTAL, TRANSIENT etc. In the case of known types we already know how large the metadata is. There is no reason to write an int stating this. This can remove 4 bytes in a lot of cases, especially now that rest uses a standard metadata. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (ISPN-8418) Off Heap improvements

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-8418?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-8418: -------------------------------- Affects Version/s: 9.2.0.Final (was: 9.2.0.Alpha1) > Off Heap improvements > --------------------- > > Key: ISPN-8418 > URL: https://issues.jboss.org/browse/ISPN-8418 > Project: Infinispan > Issue Type: Enhancement > Components: Off Heap > Affects Versions: 9.2.0.Final > Reporter: William Burns > Assignee: William Burns > > This improvement covers lumping various off heap improvements in one visible place. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 5 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 October 2017