May 2018 - infinispan-issues - Jboss List Archives

[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)

6 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: ---------------------------------- 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)

6 years, 7 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)

6 years, 7 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)

6 years, 7 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)

6 years, 7 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)

6 years, 7 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)

6 years, 7 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)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9208) Use functional commands for timestamp cache

by Radim Vansa (JIRA)

Radim Vansa created ISPN-9208: --------------------------------- Summary: Use functional commands for timestamp cache Key: ISPN-9208 URL: https://issues.jboss.org/browse/ISPN-9208 Project: Infinispan Issue Type: Enhancement Components: Hibernate Cache Affects Versions: 9.3.0.Beta1 Reporter: Radim Vansa Assignee: Radim Vansa Use UnorderedDistributionInterceptor and functional commands (max function) to achieve monotonicity of timestamps. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9059) Use functional commands for 2LC

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-9059?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-9059: ------------------------------ Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/5954 > Use functional commands for 2LC > ------------------------------- > > Key: ISPN-9059 > URL: https://issues.jboss.org/browse/ISPN-9059 > Project: Infinispan > Issue Type: Enhancement > Reporter: Radim Vansa > Assignee: Radim Vansa > > Replace TombstoneInterceptor and VersionedCallInterceptor with functional commands. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 7 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues May 2018