Uber jars testing
by Jiri Holusa
Hi all,
we've been thinking for a while, how to test ISPN uber jars. The current status is that we actually don't have many tests in the testsuite, there are few tests in integrationtests/all-embedded-* modules that are basically copies of the actual tests in corresponding modules. We think that this test coverage is not enough and more importantly, they are duplicates.
The questions are now following:
* which tests should be invoked with uber-jars? Whole ISPN testsuite? Only integrationtests module?
* how would it run? Create Maven different profiles for "classic" jars and uber jars? Or try to use some Maven exclusion magic if even possible?
Some time ago, we had discussion about this with Sebastian, who suggested that running only integrationtests module would be sufficient, because uber-jars are really about packaging, not the functionality itself. But I don't know if the tests coverage is sufficient in that level, I would be much more confident if we could run the whole ISPN testsuite against uber-jars.
I'm opening this for wider discussion as we should agree on the way how to do it, so we could do it right :)
Cheers,
Jiri
10 years
Cache Aliases
by Tristan Tarrant
Hi everybody,
to address the needs of Teiid to implement materialized views on
Infinispan caches, I have written a small design document describing
"alias caches" [1].
To be able to fully support the use-case in remote configurations, we
need to perform the switching operation remotely. Since remote admin
functionality is also required by the JCache integration code, I have
created a separate page [2] describing what the remote admin client
would look like in terms of functionality and packaging.
As usual, comments are welcome
[1] https://github.com/infinispan/infinispan/wiki/Alias-Caches
[2] https://github.com/infinispan/infinispan/wiki/Remote-Admin-Client
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
10 years
Memory consumption of org.infinispan.marshall.core.JBossMarshaller
by Christian Beikov
Hello,
In a recent heap dump analysis I found that
org.infinispan.marshall.core.JBossMarshaller consumes a lot of
memory(about 46 MB) that seems to be unused.
This is due to PerThreadInstanceHolder having ExtendedRiverMarshaller
objects that contain big IdentityIntMap objects. Some of those
IdentityIntMap instances have a size of 2 million entries, but most of
them have sizes of a few 100 thousands.
When I look into these IdentityIntMap instances, it seems that the
entries are all unused.
Is that kind of memory consumption expected or does that indicate a
possibly wrong configuration?
I am using Infinispan 7.2.4.Final on Wildfly 9.0.1.Final.
10 years
Consolidating temporary per-key data
by Radim Vansa
Hi again,
examining some flamegraphs I've found out that recently the
ExpirationInterceptor has been added, which registers ongoing write in a
hashmap. So at this point we have a map for locks, map for writes used
for expiration, another two key-addressed maps in L1ManagerImpl and one
in L1NonTxInterceptor and maybe another maps elsewhere.
This makes me think that we could spare map lookups and expensive writes
by providing *single map for temporary per-key data*. A reference to the
entry could be stored in the context to save the lookups. An extreme
case would be to put this into DataContainer, but I think that this
would prove too tricky in practice.
A downside would be the loss of encapsulation (any component could
theoretically access e.g. locks), but I don't find that too dramatic.
WDYT?
Radim
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
10 years
The "Triangle" pattern for reducing Put latency
by Sanne Grinovero
At our last face to face meeting we were discussing about possible
strategies to reduce the latency of a Put operation.
I wasn't part of that conversation, but see in our notes that the idea
would be to have the Originator to wait for first ACK from a backup,
rather than having the backups confirm with the Owner first, although
this would need for Gets to have to go to the primary owner
exclusively to keep the current consistency semantics.
An alternative is to wait for all ACKs, but I think this could still
be optimised in "triangle shape" too by having the Originator only
wait for the ACKs from the non-primary replicas?
So backup owners have to send a confirmation message to the
Originator, while the Primary owner isn't expecting to do so.
I suspect the tricky part is what happens when the Primary owner rules
+1 to apply the change, but then the backup owners (all or some of
them) somehow fail before letting the Originator know. The Originator
in this case should seek confirmation about its operation state
(success?) with the Primary owner; this implies that the Primary owner
needs to keep track of what it's applied and track failures too, and
this log needs to be pruned.
Sounds pretty nice, or am I missing other difficulties?
Thanks,
Sanne
10 years
Early Access b93 is available for JDK 9 on java.net
by Rory O'Donnell
Hi Galder,
Since my last message about JDK 9 build b88, a number of new JEPs have
been integrated into JDK 9 b93
available here <https://jdk9.java.net/download/>. I'd like to point you
to a few that are now available for testing in this JDK 9 Early Access
build:
JEP 254: Compact Strings (http://openjdk.java.net/jeps/254)
This JEP adopts a more space-efficient internal representation for strings.
We propose to change the internal representation of the String class
from a UTF-16 char array to a byte array plus an encoding-flag field.
The new String class will store characters encoded either as
ISO-8859-1/Latin-1 (one byte per character), or as UTF-16 (two bytes per
character), based upon the contents of the string. The encoding flag
will indicate which encoding is used.
JEP 165: Compiler Control (http://openjdk.java.net/jeps/165)
This JEP proposes an improved way to control the JVM compilers. It
enables runtime manageable, method dependent compiler flags. (Immutable
for the duration of a compilation.)
Method-context dependent control of the compilation process is a
powerful tool for writing small contained JVM compiler tests that can be
run without restarting the entire JVM. It is also very useful for
creating workarounds for bugs in the JVM compilers.
JEP 243: Java-Level JVM Compiler Interface
(http://openjdk.java.net/jeps/243)
This JEP instruments the data flows within the JVM which are used by the
JIT compiler to allow Java code to observe, query, and affect the JVM's
compilation process and its associated metadata.
JEP 268: XML Catalog API (http://openjdk.java.net/jeps/268)
This JEP develops a standard XML Catalog API that supports the OASIS XML
Catalogs standard, v1.1. The API will define catalog and
catalog-resolver abstractions which can be used with the JAXP processors
that accept resolvers.
Existing libraries or applications that use the internal API will need
to migrate to the new API in order to take advantage of the new features.
Rgds, Rory
--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland
10 years
CI build failures
by Tristan Tarrant
Hi,
the hibernate test-jar debacle has caused many builds on CI to fail
half-way through. I've cleared all repos hoping that this will cause
re-download.
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
10 years
Equivalence vs. MurmurHash3
by Radim Vansa
Hi guys,
I have noticed that even in library mode we use MurmurHash3 to find out
the segment for particular key. For strings, this involves encoding into
UTF-8 and computation of hashCode, instead of just reading the cached
value in string. Common objects just remix the bits of hashCode. When
user provides custom Equivalence with non-default hashCode, it is not
used to determine the segment.
I think that in library mode we should rather use Equivalence.hashCode,
maybe XORed with some magic number so that there are less collisions in
DataContainer.
If we simply replaced the function in CH, we would break the case when
user starts HR server on top of library mode, as the clients expect key
location based on MurmurHash3. ATM user only has to set
AnyServerEquivalence for keys in DC; we would need to detect
configuration with server equivalence and set CH function to MH3, and
probably also log some warning if the equivalence is set to unknown
class and CH function is not specified.
WDYT?
Radim
--
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team
10 years
Infinispan 8.1.0.CR1 (and 8.0.2.Final)
by Tristan Tarrant
Dear all,
we have two releases for you today:
Infinispan 8.1.0.CR1 brings more refinement to the server management
console, many improvements to query, statistics, management, security
improvements and more.
Infinispan 8.0.2.Final brings a number of stabilization bug fixes.
Upgrading is highly recommended.
Everything is available, as usual, from http://infinispan.org
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
10 years
GitHub protected branches
by Tristan Tarrant
Hi all,
I have used GitHub's new(ish) feature to protect the following projects'
branches from force pushes and removal:
infinispan
infinispan-management-console
infinispan.github.io
cpp-client
dotnet-client
infinispan-hadoop
infinispan-spark
infinispan-cachestore-redis
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
10 years
