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