Prepending internal cache names with org.infinispan instead of triple underscore
by Galder Zamarreño
Hi all,
I'm currently going through the JCache 1.1 proposed changes, and one that made me think is [1]. In particular:
> Caches do not use forward slashes (/) or colons (:) as part of their names. Additionally it is
> recommended that cache names starting with java. or javax.should not be used.
I'm wondering whether in the future we should move away from the triple underscore trick we use for internal cache names, and instead just prepend them with `org.infinispan`, which is our group id. I think it'd be cleaner.
Thoughts?
[1] https://github.com/jsr107/jsr107spec/issues/350
--
Galder Zamarreño
Infinispan, Red Hat
6 years, 5 months
PR labels
by Tristan Tarrant
Hello people,
I'd like to rationalize the PR labels because I believe some of them are
useless:
[Ready for review] - Any PR without the [Preview] label must fall under
this category
[Backport] - The burden should be on the PR owner to create relevant
backport PRs, not on the reviewer
[Wait CI Results] - PRs should only be integrated after a successful CI
run (or when failures can be proven to be pre-existing)
[Check CI Failures!] - The CI runs already add failure/success to the PR
status. Checking CI failures should apply to ALL PRs.
[On Ice] PR should be closed and reopened when relevant again.
Comments/suggestions ?
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
6 years, 5 months
Exposure location of Minimum Node Required
by William Burns
Recently I have been working on [1]. Calculating this value is not a hard
task. However as usual the hardest thing is where does this live and what
is its name.
In regards to its location I have a few places I was thinking:
1. CacheImpl/CacheManagerImpl - it would just be an exposed ManagedAttribute
This is my least favorite.
2. CacheMgmtInterceptor/Stats/ClusterStats
This is available at both cache and cluster levels, but this isn't really a
stat. However this one is the only option I found that actually aggregates
all nodes data to be presented, which would give a better estimate (since
each node can have a varying amount of data they could each have a
different idea of required node count).
3. CacheHealth/ClusterHealth
This is available at both cache and cluster levels. However these were
designed for health checks, but it seems like a legitimate place to me. The
only problem is the values aren't aggregated and just called from 1 node.
I am personally leaning towards #2 or #3. Also I am open if we have other
alternatives I am not aware of :) Let me know what you all think?
[1] https://issues.jboss.org/browse/ISPN-6879
6 years, 5 months
