May 2018 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-9192) Upgrade to Hibernate Search 5.10, Hibernate ORM 5.3, JPA 2.2

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-9192?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-9192: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Integrated. Thanks [~sannegrinovero]! > Upgrade to Hibernate Search 5.10, Hibernate ORM 5.3, JPA 2.2 > ------------------------------------------------------------ > > Key: ISPN-9192 > URL: https://issues.jboss.org/browse/ISPN-9192 > Project: Infinispan > Issue Type: Component Upgrade > Components: Build, Embedded Querying, Integration , Lucene Directory, WildFly modules > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 9.3.0.CR1 > > > We can upgrade to Hibernate Search {{5.10.0.Final}} to benefit the Infinispan Query component. > However, this is much easier if combined with the upgrade to Hibernate ORM {{5.3.0.Final}} as integration tests would not need to diverge (*JPA 2.2*). > Both these versions are included in WildFly 13. WildFly {{13.0.0.Beta1}} is available now so switching to this version to run integration test of the _Lucene Directory Modules_ already makes sense - as Infinispan no longer ships a dependency to a specific WildFly version: this is used only for integration tests. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9178) EntityCollectionInvalidationTest.testAll randomly failing

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-9178?page=com.atlassian.jira.plugin.... ] Galder Zamarreño commented on ISPN-9178: ---------------------------------------- The problem with read-write is similar, the put from load call results in an async call which is not waited for. Detailed analysis can be found [here|https://gist.github.com/galderz/98216b498ed125f327d993426fe94972]. > EntityCollectionInvalidationTest.testAll randomly failing > --------------------------------------------------------- > > Key: ISPN-9178 > URL: https://issues.jboss.org/browse/ISPN-9178 > Project: Infinispan > Issue Type: Bug > Components: Hibernate Cache > Affects Versions: 9.3.0.Beta1 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Labels: testsuite_stability > Fix For: 9.3.0.CR1, 9.3.0.Final > > Attachments: ispn9178-log-v2.tgz > > > Failure: > {code} > [INFO] Running > org.infinispan.test.hibernate.cache.commons.functional.cluster.EntityCollectionInvalidationTest > [ERROR] Tests run: 12, Failures: 1, Errors: 1, Skipped: 0, Time elapsed: 7.655 s <<< FAILURE! - in org.infinispan.test.hibernate.cache.commons.functional.cluster.EntityCollectionInvalidationTest > [ERROR] testAll[nonstrict, REPL_SYNC](org.infinispan.test.hibernate.cache.commons.functional.cluster.EntityCollectionInvalidationTest) Time elapsed: 0.563 s <<< FAILURE! > java.lang.AssertionError: Contact#1 was in cache > at org.junit.Assert.fail(Assert.java:88) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.infinispan.test.hibernate.cache.commons.functional.cluster.EntityCollectionInvalidationTest.assertLoadedFromCache(EntityCollectionInvalidationTest.java:426) > at org.infinispan.test.hibernate.cache.commons.functional.cluster.EntityCollectionInvalidationTest.testAll(EntityCollectionInvalidationTest.java:171) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.hibernate.testing.junit4.ExtendedFrameworkMethod.invokeExplosively(ExtendedFrameworkMethod.java:45) > at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) > at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:298) > at org.junit.internal.runners.statements.FailOnTimeout$CallableStatement.call(FailOnTimeout.java:292) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.lang.Thread.run(Thread.java:748) > {code} > TRACE logs attached. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9209) Implement RemoteCachestatistics

by Tristan Tarrant (JIRA)

Tristan Tarrant created ISPN-9209: ------------------------------------- Summary: Implement RemoteCachestatistics Key: ISPN-9209 URL: https://issues.jboss.org/browse/ISPN-9209 Project: Infinispan Issue Type: Enhancement Components: Hot Rod Reporter: Tristan Tarrant 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, 10 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: ---------------------------------- Summary: Implement RemoteCache statistics (was: Implement RemoteCachestatistics) > 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 > > 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, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9021) Remote query: add option to disable default/legacy indexing per schema file

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-9021?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-9021: -------------------------------- Description: All types that are not annotated are currently fully indexed for backward compat with first version of remote query (which did not have protobuf annotations to control indexing). This behaviour is very inefficient and confusing for users that do not intend to use indexing (non-indexed query works anyway). Given the history of this behaviour we cannot remove it until next major version. Until then we can offer the choice of disabling it per each schema file via a boolean protobuf file-level option named{color:#cccccc} -'enable_legacy_indexing'-{color} 'indexed_by_default', which when absent is considered to default to true. Setting it to false will disable indexing of types that do not have indexing annotations. Whenever an entry is indexed using default indexing a warning will be logged in order to motivate people to switch to using proper annotations. was: All types that are not annotated are currently fully indexed for backward compat with first version of remote query (which did not have protobuf annotations to control indexing). This behaviour is very inefficient and confusing for users that do not intend to use indexing (non-indexed query works anyway). Given the history of this behaviour we cannot remove it until next major version. Until then we can offer the choice of disabling it per each schema file via a boolean protobuf file-level option named 'enable_legacy_indexing', which when absent is considered to default to true. Setting it to false will disable indexing of types that do not have indexing annotations. Whenever an entry is indexed using default indexing a warning will be logged in order to motivate people to switch to using proper annotations. > Remote query: add option to disable default/legacy indexing per schema file > --------------------------------------------------------------------------- > > Key: ISPN-9021 > URL: https://issues.jboss.org/browse/ISPN-9021 > Project: Infinispan > Issue Type: Enhancement > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 9.3.0.CR1, 9.3.0.Final > > > All types that are not annotated are currently fully indexed for backward compat with first version of remote query (which did not have protobuf annotations to control indexing). > This behaviour is very inefficient and confusing for users that do not intend to use indexing (non-indexed query works anyway). > Given the history of this behaviour we cannot remove it until next major version. Until then we can offer the choice of disabling it per each schema file via a boolean protobuf file-level option named{color:#cccccc} -'enable_legacy_indexing'-{color} 'indexed_by_default', which when absent is considered to default to true. Setting it to false will disable indexing of types that do not have indexing annotations. > Whenever an entry is indexed using default indexing a warning will be logged in order to motivate people to switch to using proper annotations. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9206) Handle long qualified region names more efficiently

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-9206?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on ISPN-9206: ------------------------------------ [~rvansa] {quote} Are you sure that the list will be equal on all nodes? I can imagine 1) app having two different versions clustered together - at least temporarily during roll out {quote} This is not something WF would/should encourage users to do. There is nothing to be gained by multiple deployment versions sharing the same logical 2LC cluster. This is not a use case that we need to consider. {quote} 2) with prefixes one server may have more deployments than the other {quote} This is very true (at least for bare-metal deployments). {quote} We'd need to handle different configuration options a bit differently - right now for specific overrides we use o.h.cache.infinispan.deployment#com.acme.Entity.cfg - is the deployment really needed there? Isn't the persistence.xml (or spring properties or whatever file you provide) always scoped to the deployment anyway? {quote} It's entirely feasible that "com.acme.Entity" can be use by multiple deployments, or even by multiple persistent units within a deployment, each with different caching strategies. > Handle long qualified region names more efficiently > --------------------------------------------------- > > Key: ISPN-9206 > URL: https://issues.jboss.org/browse/ISPN-9206 > Project: Infinispan > Issue Type: Enhancement > Components: Hibernate Cache > Affects Versions: 9.2.2.Final, 9.3.0.Beta1 > Reporter: Radim Vansa > Assignee: Radim Vansa > > Hibernate region names are FQCNs, and when the prefix is added this can exceed the 255 byte ByteString limit. Also, it's inefficient to ship such long cache names with each command. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9206) Handle long qualified region names more efficiently

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-9206?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on ISPN-9206: --------------------------------------- With A+B and B+C you're talking about deployments and possibly how to distinguish (prefix?) deployment names. I guess that's maybe why we weren't understanding each other, I was talking about short names for the various entity names within a single Persistent Unit. Those locally detected conflicts are the same thing I referred to in my first comment (I called them collisions though): I agree those are easy to fix for, with whatever strategy as long as it's deterministic so that other nodes would produce exactly the same alternative keys. Yet if other nodes are expected by design to produce the same shortened keys, so when you connect to them... you are expecting them to have the same names. You can't distinguish this expected case from a conflict of keys - unless we premise it all with the assumption that applications need to be identical. So it's easily proven that they need to be identical for any such optimizations to work - the alternative being that the cluster group runs a strong consensus protocol to establish short name mapping upfront, but that seems excessive IMO. We could just expect applications in the same cluster to be identical, and maybe have a simple consensus protocol which just verifies this. > Handle long qualified region names more efficiently > --------------------------------------------------- > > Key: ISPN-9206 > URL: https://issues.jboss.org/browse/ISPN-9206 > Project: Infinispan > Issue Type: Enhancement > Components: Hibernate Cache > Affects Versions: 9.2.2.Final, 9.3.0.Beta1 > Reporter: Radim Vansa > Assignee: Radim Vansa > > Hibernate region names are FQCNs, and when the prefix is added this can exceed the 255 byte ByteString limit. Also, it's inefficient to ship such long cache names with each command. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7191) CacheManager.removeCache leaks

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-7191?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-7191: ----------------------------------- [~NadirX] Is this still valid? > CacheManager.removeCache leaks > ------------------------------ > > Key: ISPN-7191 > URL: https://issues.jboss.org/browse/ISPN-7191 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.2.4.Final > Reporter: Ryan Gustafson > Assignee: Tristan Tarrant > Attachments: TransientInfinispanCacheTest.java > > > Tests to try to use Infinispan caches for a large number of anonymous transient caches eventually runs out of memory. 3 different kinds of leaks were identified. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9206) Handle long qualified region names more efficiently

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-9206?page=com.atlassian.jira.plugin.... ] Radim Vansa commented on ISPN-9206: ----------------------------------- Conflict can be detected locally - you have all the entities that are locally available listed. If there's another node with a list that includes conflicts, it will see the conflict and won't boot. The only situation when you don't detect it (if I am not mistaken) is when you have node1 with deployments A+B, node2 with B+C and there's a conflict between A and C. I consider hashcodes on by default a safe choice: turning that off is a workaround because the situation might theoretically arise. > Handle long qualified region names more efficiently > --------------------------------------------------- > > Key: ISPN-9206 > URL: https://issues.jboss.org/browse/ISPN-9206 > Project: Infinispan > Issue Type: Enhancement > Components: Hibernate Cache > Affects Versions: 9.2.2.Final, 9.3.0.Beta1 > Reporter: Radim Vansa > Assignee: Radim Vansa > > Hibernate region names are FQCNs, and when the prefix is added this can exceed the 255 byte ByteString limit. Also, it's inefficient to ship such long cache names with each command. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-7396) Improve default bundle size and fragment size

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-7396?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-7396: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.0.0.Final (was: 9.3.0.Final) Resolution: Done > Improve default bundle size and fragment size > --------------------------------------------- > > Key: ISPN-7396 > URL: https://issues.jboss.org/browse/ISPN-7396 > Project: Infinispan > Issue Type: Task > Components: Core > Affects Versions: 9.0.0.Beta2 > Reporter: Dan Berindei > Assignee: Dan Berindei > Labels: performance > Fix For: 9.0.0.Final > > > If a UDP packet is split into multiple ethernet frames, the entire packet is lost. TCP avoids sending packets larger than an ethernet frame for us, but with a UDP transport, we need to consider the ethernet frame size when configuring {{UDP.max_bundle_size}} and {{FRAG2.frag_size}}. > Most modern networks should support jumbo frames with 9000 bytes, so we should set {{UDP.max_bundle_size=8000}} and {{FRAG2.frag_size=8500}} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

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