August 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-9444) Support native JSON in scripts

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-9444?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-9444: ---------------------------------------- Also: {code} // mode=local,language=javascript,parameters=[k, v],datatype='application/json; charset=utf-8' cache.put(k, v); cache.get(k); {code} Where {{k}} and {{v}} are native JSON objects. > Support native JSON in scripts > ------------------------------ > > Key: ISPN-9444 > URL: https://issues.jboss.org/browse/ISPN-9444 > Project: Infinispan > Issue Type: Enhancement > Reporter: Galder Zamarreño > > E.g. > {code} > // mode=local,language=javascript,datatype='text/plain; charset=utf-8' > var addr = cacheManager.getAddress(); > {address: addr} > {code} > {code} > // mode=local,language=javascript,datatype='application/json;type=java.lang.String' > cache.put({k: "բարեվ"}, {v: "բարեվ"}); > cache.get({k: "բարեվ"}); > {code} > {code} > // mode=local,language=javascript,datatype='application/json; charset=utf-8' > var s = cache.size(); > var st = cache.getStatus(); > {size: s, status: st} > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9444) Support native JSON in scripts

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-9444: -------------------------------------- Summary: Support native JSON in scripts Key: ISPN-9444 URL: https://issues.jboss.org/browse/ISPN-9444 Project: Infinispan Issue Type: Enhancement Reporter: Galder Zamarreño E.g. {code} // mode=local,language=javascript,datatype='text/plain; charset=utf-8' var addr = cacheManager.getAddress(); {address: addr} {code} {code} // mode=local,language=javascript,datatype='application/json;type=java.lang.String' cache.put({k: "բարեվ"}, {v: "բարեվ"}); cache.get({k: "բարեվ"}); {code} {code} // mode=local,language=javascript,datatype='application/json; charset=utf-8' var s = cache.size(); var st = cache.getStatus(); {size: s, status: st} {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9443) Fail when single region is accessed with multiple strategies

by Radim Vansa (JIRA)

Radim Vansa created ISPN-9443: --------------------------------- Summary: Fail when single region is accessed with multiple strategies Key: ISPN-9443 URL: https://issues.jboss.org/browse/ISPN-9443 Project: Infinispan Issue Type: Enhancement Components: Hibernate Cache Affects Versions: 9.3.1.Final Reporter: Radim Vansa Fix For: 9.4.0.Final When we have two entities that share the same region but use different access strategies the Hibernate boot should fail. Right now there's an assertion in {{DomainDataRegionImpl.prepareFor*}} but this does not give much explanation and does not fail when assertions are disabled which leads to cryptic errors later on. Example: ``` @Cache(usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE, region = "item") public static class NonStrictReadWriteVersionedCacheableItem { ...} @Cache(usage = CacheConcurrencyStrategy.READ_WRITE, region = "item") public static class ReadWriteVersionedCacheableItem { ``` -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9443) Fail when single region is accessed with multiple strategies

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-9443?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-9443: ------------------------------ Description: When we have two entities that share the same region but use different access strategies the Hibernate boot should fail. Right now there's an assertion in {{DomainDataRegionImpl.prepareFor*}} but this does not give much explanation and does not fail when assertions are disabled which leads to cryptic errors later on. Example: {code} @Cache(usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE, region = "item") public static class NonStrictReadWriteVersionedCacheableItem { ... } @Cache(usage = CacheConcurrencyStrategy.READ_WRITE, region = "item") public static class ReadWriteVersionedCacheableItem { ... } {code} was: When we have two entities that share the same region but use different access strategies the Hibernate boot should fail. Right now there's an assertion in {{DomainDataRegionImpl.prepareFor*}} but this does not give much explanation and does not fail when assertions are disabled which leads to cryptic errors later on. Example: ``` @Cache(usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE, region = "item") public static class NonStrictReadWriteVersionedCacheableItem { ...} @Cache(usage = CacheConcurrencyStrategy.READ_WRITE, region = "item") public static class ReadWriteVersionedCacheableItem { ``` > Fail when single region is accessed with multiple strategies > ------------------------------------------------------------ > > Key: ISPN-9443 > URL: https://issues.jboss.org/browse/ISPN-9443 > Project: Infinispan > Issue Type: Enhancement > Components: Hibernate Cache > Affects Versions: 9.3.1.Final > Reporter: Radim Vansa > Fix For: 9.4.0.Final > > > When we have two entities that share the same region but use different access strategies the Hibernate boot should fail. Right now there's an assertion in {{DomainDataRegionImpl.prepareFor*}} but this does not give much explanation and does not fail when assertions are disabled which leads to cryptic errors later on. > Example: > {code} > @Cache(usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE, region = "item") > public static class NonStrictReadWriteVersionedCacheableItem { ... } > @Cache(usage = CacheConcurrencyStrategy.READ_WRITE, region = "item") > public static class ReadWriteVersionedCacheableItem { ... } > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9409) NPE and CCE when using filters/convertes with events with older clients

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-9409?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9409: ----------------------------------- Fix Version/s: 9.4.0.Final 9.3.2.Final > NPE and CCE when using filters/convertes with events with older clients > ----------------------------------------------------------------------- > > Key: ISPN-9409 > URL: https://issues.jboss.org/browse/ISPN-9409 > Project: Infinispan > Issue Type: Bug > Components: Hot Rod > Affects Versions: 9.4.0.Beta1, 9.3.1.Final > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 9.4.0.CR1, 9.4.0.Final, 9.3.2.Final > > > Infinispan 9.3.x has been updated so that clients send the data type with the Hot Rod operations. Older clients (Protocol version < 2.8) do not send this information and the server is not handling this correctly. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9411) Shutdown process hangs on same cache each time

by Sergey Chernolyas (JIRA)

[ https://issues.jboss.org/browse/ISPN-9411?page=com.atlassian.jira.plugin.... ] Sergey Chernolyas commented on ISPN-9411: ----------------------------------------- Hi [~gustavonalle] {code:xml} <replicated-cache name="LuceneIndexesLocking_accessories"/> <replicated-cache name="LuceneIndexesMetadata_accessories"/> {code} > Shutdown process hangs on same cache each time > ---------------------------------------------- > > Key: ISPN-9411 > URL: https://issues.jboss.org/browse/ISPN-9411 > Project: Infinispan > Issue Type: Bug > Affects Versions: 9.2.4.Final, 9.3.1.Final > Environment: Linux, cluster with two nodes > Reporter: Sergey Chernolyas > Attachments: server_log.txt, shutdown_10540_931.txt, shutdown_15226_931.txt, shutdown_7181_924.txt, shutdown_7252_924.txt > > > Each time, shutdown process hangs on same cache. > Configuration of the caches are: > {code:title=Cache configurations|linenumbers=true|language=XML} > <distributed-cache name="ACCESSORIES" owners="2" segments="1024" mode="SYNC"> > <state-transfer await-initial-transfer="true" enabled="true" timeout="2400000" chunk-size="2048"/> > <partition-handling when-split="ALLOW_READ_WRITES" merge-policy="PREFERRED_ALWAYS"/> > <memory> > <object size="1000000" strategy="REMOVE"/> > </memory> > <indexing index="LOCAL"> > <property name="default.directory_provider">infinispan</property> > <property name="default.indexmanager">org.infinispan.query.indexmanager.InfinispanIndexManager > </property> > <property name="default.worker.execution">async</property> > <property name="default.index_flush_interval">500</property> > <property name="default.indexwriter.merge_factor">30</property> > <property name="default.indexwriter.merge_max_size">1024</property> > <property name="default.indexwriter.ram_buffer_size">256</property> > <property name="default.locking_cachename">LuceneIndexesLocking_accessories</property> > <property name="default.data_cachename">LuceneIndexesData_accessories</property> > <property name="default.metadata_cachename">LuceneIndexesMetadata_accessories</property> > </indexing> > <rocksdb-store preload="true" path="/data/rocksdb/accessories/data"> > <expiration path="/data/rocksdb/accessories/expired"/> > </rocksdb-store> > </distributed-cache> > <distributed-cache name="LuceneIndexesData_accessories"> > <state-transfer await-initial-transfer="true" enabled="true" timeout="2400000" chunk-size="2048"/> > <partition-handling when-split="ALLOW_READ_WRITES" merge-policy="PREFERRED_ALWAYS"/> > <rocksdb-store preload="true" fetch-state="true" passivation="true" name="accessories_index_data" path="/data/rocksdb/accessories_index_data/data"> > <expiration path="/data/rocksdb/accessories_index_data/expired"/> > </rocksdb-store> > </distributed-cache> > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9442) Scripts with JSON datatype should be able to read data as String by default

by Gustavo Fernandes (JIRA)

Gustavo Fernandes created ISPN-9442: --------------------------------------- Summary: Scripts with JSON datatype should be able to read data as String by default Key: ISPN-9442 URL: https://issues.jboss.org/browse/ISPN-9442 Project: Infinispan Issue Type: Enhancement Components: Tasks Affects Versions: 9.4.0.Beta1 Reporter: Gustavo Fernandes Assignee: Gustavo Fernandes ISPN-9182 introduced support for application/json as a script datatype, but the data is presented as byte[]. When protobuf is the storage, it is possible to read data as JSON from scripts in the String form, by applying the "type" parameters to the MediaType: "application/json; type=java.lang.String", but this is not available for other storages. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7409) Replace external marshaller with user marshaller

by Ryan Emerson (JIRA)

[ https://issues.jboss.org/browse/ISPN-7409?page=com.atlassian.jira.plugin.... ] Ryan Emerson updated ISPN-7409: ------------------------------- Fix Version/s: 10.0.0.Final > Replace external marshaller with user marshaller > ------------------------------------------------ > > Key: ISPN-7409 > URL: https://issues.jboss.org/browse/ISPN-7409 > Project: Infinispan > Issue Type: Enhancement > Components: Core, Marshalling > Reporter: Galder Zamarreño > Assignee: Ryan Emerson > Fix For: 10.0.0.Final > > > ISPN-6906 brings much needed independence from JBoss Marshalling to our marshalling layer. One of the key aspects it brings it’s the separation between marshalling internal types we know about, e.g. String, byte[], CacheTopologyCommand...etc and external or unknown types, e.g. any types that extend Serializable. > Although this separation helps achieve objectives of ISPN-6906, it’s not an ideal solution: > * If user types map directly to primitive types supported by our internal marshaller, or types that depend on types that are marshalled by our internal marshaller, any changes made to the internal marshaller have a direct impact on the representation of the user types. > * In the ISPN-6906 implementation, Internal marshaller exposes its own externalizer table to the external marshaller so that it can lookup how to marshall internal types. This is done to support corner cases in Hibernate Search where some of the classes that Query module marshalls rely on the fact that some Hibernate Search classes are Serializable, but these classes reference Lucene query classes that are not for which there are externalizers defined. For query logic to work, externalizers have to be found while dealing with Serializable types are being traversed. Gustavo and Sane are aware of this issue and we should soon have externalizers for those Hibernate Search classes and avoid this issue altogether (see ISPN-7156). > So, rather than an external marshaller, a more suitable abstraction would be to have a user marshaller. The job of the user marshaller, which would be configurable, would be to marshall user types. The user marshaller should be independent of the internal marshaller, so it would not be able to piggyback on the internal externalizers. > Externalizers for user types could still be supported, by having a user externalizer table, purely used by the user marshaller. In fact, it would make sense that all externalizers that are configured in Infinispan (regardless of whether via xml, programmatic or via annotation) to be user externalizers. > User types are considered to be: > * Keys and values > * Metadata instances provided by the user via *withMetadata() calls > The benefits of the user marshaller are the following: > * Having the user marshaller configurable would make it easy to try out different marshallers when comparing how key/value types are marshalled, e.g. try out different ways to marshall Strings. > * An easier upgrade path for user types. Since user types no longer rely on internal marshaller details, Infinispan upgrades are easier to deal with. > For reference, custom commands that can be plugged via ModuleCommandFactory implementations would use the internal marshaller since these commands often marshall internal types, e.g. Address. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9434) Reading JSON content from untyped caches return escaped quotes

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-9434?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-9434: ----------------------------------- Fix Version/s: 9.3.2.Final > Reading JSON content from untyped caches return escaped quotes > -------------------------------------------------------------- > > Key: ISPN-9434 > URL: https://issues.jboss.org/browse/ISPN-9434 > Project: Infinispan > Issue Type: Bug > Components: Hot Rod > Affects Versions: 9.4.0.Beta1, 9.3.1.Final > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 9.4.0.CR1, 9.4.0.Final, 9.3.2.Final > > > Reading content as "application/json" from caches without media type configured causes Infinispan to interpret the content as String first and then convert it to JSON, resulting in JSON string literal rather than a proper JSON. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (HRJS-66) Fix Jsdoc generation

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/HRJS-66?page=com.atlassian.jira.plugin.sy... ] Galder Zamarreño updated HRJS-66: --------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Fix Jsdoc generation > -------------------- > > Key: HRJS-66 > URL: https://issues.jboss.org/browse/HRJS-66 > Project: Infinispan Javascript client > Issue Type: Bug > Affects Versions: 0.5.0 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 0.6.0 > > > * Add jsdoc to devDependencies > * Fix jsdoc generation (currently fails) > * Add jsdoc generation check to PR CI checks. > * Publish jsdoc for 0.5.0 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 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 August 2018