Weekly IRC meeting
by William Burns
I will be unable to make it to the meeting today.
Last week:
ISPN-7479 Add Failover and Execution Policy to ClusterExecutor
This has been completed and integrated.
I also was looking at CI to find some stuff that could be fixed, I submitted
ISPN-7743 DistributedStreamIteratorTest.testNode* fails randomly
The fix may not work, but it should ease the test at a minimum. Will have
to watch it later to see if it resurfaces.
I also completed various backport work required and tried to relieve some
of the PR queue stress and added comments to others.
This week:
I will most likely have to go on leave very soon, to be honest I am
surprised I am not yet :D
But I need to add documentation for both wiki and forums regarding
ISPN-7479 and deprecate distributed execution service. The new cluster
executor is completely detached from keys though so we will have to see if
that is an issue (distributed streams should handle the bulk of that now).
If time permits I also have some design stuff I need to add regarding
stream for each with lock.
Have a good week!
- Will
7 years
SLF4J shaded into infinispan-query-embedded ?
by Sanne Grinovero
When inspecting the stuff included in the "shaded" jar
infinispan-query-embedded, I even found a copy of SLF4J in there.
It's being relocated to the package "/infinispan/org/slf4j/"
Is that intentional? Does it even work in this way? I doubt it would
be able to bind to the right appenders, or be configured as intended.
Thanks,
Sanne
7 years
Infinispan Query API simplification
by Tristan Tarrant
Querying an Infinispan cache is currently a bit cumbersome. There are
two paths:
Ickle:
Search.getQueryFactory(cache).create("...").list();
DSL (one possible example):
Search.getQueryFactory(cache).from(class).[filters].build().list();
Ideally we should have something like:
Ickle:
cache.query("...").list();
DSL:
cache.query(class).[filters].list();
Additionally, the query module is separate from infinispan-core. While
this made sense when we didn't have non-indexed query capabilities (and
is somewhat mitigated by the uberjars), I feel that query should be a
1st class citizen API-wise.
For this reason I propose that we extract the query API to
infinispan-commons, put the query SPI in infinispan-core together with
the non-indexed implementation and have the hibernate-search backend as
a pluggable implementation.
Thoughts ?
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
7 years
Native Infinispan Multimap support
by Katia Aresti
Hi all,
As you probably know, Will and I are working on the vert-x infinispan
integration [1], where the primary goal is to make infinispan the default
cluster management of vert-x. (yeah!)
Vert-x needs support for an Async Multimap. Today's implementation is a
wrapper on a normal Cache where only Cache Key's are used to implement the
multi map [2].
This is not very efficient, so after trying some other alternative
implementations [3] that don't fully work (injection not working), Will and
I have come to the conclusion that it might be a good idea to start having
our own native CacheMultimap. This first multimap won't support duplicate
values on key's.
As a quick start, the smallest multimap we need should implement the
following interface :
public interface CacheMultimap<K, V> {
V put(K key, V value);
Collection<V> get(K key);
boolean remove(K key, V value);
}
CacheMultimapImpl will be a wrapper on a normal Cache, similar to [3].
We could add a new method in EmbeddedCacheManager.java
<K, V> CacheMultimap<K, V> getCacheMultimap(String cacheName, boolean
createIfAbsent);
Implementation will create a cache as always and return a new
CacheMultimapImpl(cache).
What do you think ? Please fell free to suggest any other alternative or
idea.
Cheers
Katia
[1] https://github.com/vert-x3/vertx-infinispan
[2]
https://github.com/vert-x3/vertx-infinispan/blob/master/src/main/java/io/...
[3] https://gist.github.com/karesti/194bb998856d4a2828d83754130ed79c
7 years
Branching 9.0.x
by Tristan Tarrant
Hi all,
I am going to branch 9.0.x tomorrow at 12:00 CEST. Let me know if I
should delay this.
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
7 years
Streams & missing segments
by Radim Vansa
Hi Will,
rebasing scattered cache PR I've found a test failure when handling
streams, and I'd like to ask you guidance, how to address it.
My problem is that temporarily primary owners can be unknown (when a
node crashes), but streams assume that there's always a primary owner.
Therefore, a remote streams operation must be delayed until a topology
arrives where the new owner is decided.
Could you suggest how should I adapt the code?
ClusteredStreamManagerImpl currently does not hold DistributionManager
reference, ConsistenHash is passed down from DistributedCacheStream, and
it seems that segments are suspected after any unsuccessful response.
Which components should react to topology changes?
Thanks!
Radim
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
7 years
