August 2018 - infinispan-issues - Jboss List Archives

[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 commented on ISPN-9443: ----------------------------------- Maybe I misunderstand this but to my knowledge the read-only strategy does not apply to Phones but to Person.phones collection. Therefore you are free to change Phone.foo but given person is not allowed to add a new Phone. > 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-9445) HotRod Transaction Cache - Wrong values when a transactional cache stops in the middle of PrepareTransactionOperation/CompleteTransactionOperation

by Diego Lovison (JIRA)

Diego Lovison created ISPN-9445: ----------------------------------- Summary: HotRod Transaction Cache - Wrong values when a transactional cache stops in the middle of PrepareTransactionOperation/CompleteTransactionOperation Key: ISPN-9445 URL: https://issues.jboss.org/browse/ISPN-9445 Project: Infinispan Issue Type: Bug Reporter: Diego Lovison Priority: Critical There are 3 scenarios and I believe that they are correlated. If it is not the case, a JIRA for each item should be open. All scenarios below are multiple clients and one server. The following steps should be executed does not matter what is the scenario. * Add one breakpoint at the first line of the method `acceptResponse` at the class PrepareTransactionOperation * Add one breakpoint at the first line of the method `executeOperation` at the class PrepareTransactionOperation *Scenario 1* * Execute the client code ( Program 1 ) * Execute the client code ( Program 2 ) * Program 1 -> Resume, Resume, Resume. It will stop at `acceptResponse`. * Program 2 -> Resume, Resume. It will stop at `executeOperation`. * Wait 5 minutes or any time greater than 60 seconds ( I was not able to identify the right period of time but greater than 60 seconds should work), Resume and Resume the "Program 2". It will fail. * The issue in scenario 1 is: Why doesn't matter the amount of time since it is greater than 60 seconds the request will fail? I am expecting something like a timeout in the "Program 1" and not expire when a call in that key was called for the first time. * Kill all clients and servers *Scenario 2* * Execute the client code ( Program 1 ) * Execute the client code ( Program 2 ) * Program 1 -> Resume, Resume, Resume. It will stop at `acceptResponse`. * Program 2 -> Resume, Resume, Resume, Resume. It will fail. Here you don't need to wait. Just press the Resume. * Program 1 -> Resume. * The issue in scenario 2 is: Why the test fails due: expected value 'null' different from 'random-value-generated' * Kill all clients and servers *Scenario 3* * Execute the client code ( Program 1 ) * Execute the client code ( Program 2 ) * Program 1 -> Resume, Resume, Resume. It will stop at `acceptResponse`. * Program 2 -> Resume, Resume, Resume, Resume. It will fail. Here you don't need to wait. Just press the Resume. * Wait 60 seconds * Re-run Program 2 -> Resume, Resume, Resume, Resume. It will work. * Program 1 -> Resume, it will fail due to an assertion error * The issue in scenario 3 is: When resuming the "Program 1" I am expecting an error during the commit phase and not an assertion error. * Kill all clients and servers Program 1 means that you should run the client code. It will create a separated JVM. Program 2 means that you should run the client code. It will create a separated JVM. It will be nice if we find out an way to automate this kind of tests. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9408) Support for query results in different formats in Hot Rod

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-9408?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-9408: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.4.0.CR1 Resolution: Done Integrated in master. Thanks [~gustavonalle]! > Support for query results in different formats in Hot Rod > --------------------------------------------------------- > > Key: ISPN-9408 > URL: https://issues.jboss.org/browse/ISPN-9408 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 9.4.0.CR1 > > > ISPN-7420 introduced multiple format support for the Hot Rod client, but this is not covering the query results which are always protobuf. The data format specified in the client should propagate to the server and the response (query results or projections) should be converted to the specified format. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9408) Support for query results in different formats in Hot Rod

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-9408?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-9408: -------------------------------- Fix Version/s: 9.4.0.Final > Support for query results in different formats in Hot Rod > --------------------------------------------------------- > > Key: ISPN-9408 > URL: https://issues.jboss.org/browse/ISPN-9408 > Project: Infinispan > Issue Type: Enhancement > Components: Remote Protocols > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 9.4.0.CR1, 9.4.0.Final > > > ISPN-7420 introduced multiple format support for the Hot Rod client, but this is not covering the query results which are always protobuf. The data format specified in the client should propagate to the server and the response (query results or projections) should be converted to the specified format. -- 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)

[ https://issues.jboss.org/browse/ISPN-9442?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-9442: ------------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/6212 > 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-9443) Fail when single region is accessed with multiple strategies

by Diego Lovison (JIRA)

[ https://issues.jboss.org/browse/ISPN-9443?page=com.atlassian.jira.plugin.... ] Diego Lovison edited comment on ISPN-9443 at 8/21/18 12:46 PM: --------------------------------------------------------------- Please consider the following scenario as well. Most of the fields were hidden. {code:java} @Entity @Table(name = "phone") @Cacheable public class Phone { } @Entity @Table(name = "person") @Cacheable public class Person { @OneToMany(cascade = CascadeType.ALL) @org.hibernate.annotations.Cache(usage = CacheConcurrencyStrategy.READ_ONLY, region = "phone-region") private List<Phone> phones; } {code} Phone has two different access strategies. was (Author: dlovison): Please consider the following scenario as well. Most of the fields were hidden. {code:java} @Entity @Table(name = "phone") @Cacheable public class Phone { } @Entity @Table(name = "person") @Cacheable public class Person { @OneToMany(cascade = CascadeType.ALL) @org.hibernate.annotations.Cache(usage = CacheConcurrencyStrategy.READ_ONLY, region = "phone-region") private List<Phone> phones; } {code} In the case above, Phone have two different access strategies. > 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-9443) Fail when single region is accessed with multiple strategies

by Diego Lovison (JIRA)

[ https://issues.jboss.org/browse/ISPN-9443?page=com.atlassian.jira.plugin.... ] Diego Lovison commented on ISPN-9443: ------------------------------------- Please consider the following scenario as well. Most of the fields were hidden. {code:java} @Entity @Table(name = "phone") @Cacheable public class Phone { } @Entity @Table(name = "person") @Cacheable public class Person { @OneToMany(cascade = CascadeType.ALL) @org.hibernate.annotations.Cache(usage = CacheConcurrencyStrategy.READ_ONLY, region = "phone-region") private List<Phone> phones; } {code} In the case above, Phone have two different access strategies. > 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-9442) Scripts with JSON datatype should be able to read data as String by default

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-9442?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-9442: ------------------------------------ Status: Open (was: New) > 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-9209) Implement RemoteCache statistics

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-9209?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-9209: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/6211 > Implement RemoteCache statistics > -------------------------------- > > Key: ISPN-9209 > URL: https://issues.jboss.org/browse/ISPN-9209 > Project: Infinispan > Issue Type: Enhancement > Components: Hot Rod > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 9.4.0.Final > > > The Hot Rod client does not expose any local statistics (RemoteCacheManager.getStatistics() returns the server-side stats). > We should have the following per-cache stats: > - remote hits and hit avg time > - remote misses and miss avg time > - remote removes and remove avg time > - near cache hits and avg time > - near cache miss and avg time > - near cache size -- 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 William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-9411?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-9411: ------------------------------------- This is caused due to having passivation enabled with an eviction size of 1M elements. During passivation of all entries the writes get blocked by the expiration queue in RocksDB which is default configured at only 1000 elements. Thus it would take at least 1000! minutes to shut down as the reaper has to run each time to allow for 1000 more writes. The RocksDB should shut down irrespective of the expiration queue as everything is getting dumped anyways. > 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues August 2018