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
9 years, 9 months
Lambda's & Batching
by Sanne Grinovero
A local cache with batching enabled produces this:
java.lang.IllegalArgumentException: Cannot create a transactional
context without a valid Transaction instance.
at org.infinispan.context.TransactionalInvocationContextFactory.createInvocationContext(TransactionalInvocationContextFactory.java:69)
at org.infinispan.context.TransactionalInvocationContextFactory.createInvocationContext(TransactionalInvocationContextFactory.java:63)
at org.infinispan.functional.impl.ReadWriteMapImpl.eval(ReadWriteMapImpl.java:56)
at org.infinispan.lucene.impl.FileListOperations.addFileName(FileListOperations.java:60)
(<-- experimental uncommitted code here)
I'm guessing the eval implementations is needing the
"auto-transaction-start" semantics which we normally have for other
operations in a batching cache... right?
But I wonder about the usefulness of having a short lived batching
context when all I'm doing is sending a lambda to a specific entry:
wouldn't it be even better to treat this as a no-context operation?
Thanks,
Sanne
10 years
Infinispan 8.1.0.Alpha1
by Tristan Tarrant
Dear all,
release early release often ! The first Alpha release of Infinispan 8.1
is out. As is traditional, it is codenamed after a beer. This time it is
"Mahou" !
The highlights for 8.1.0.Alpha1 are:
ISPN-5781 - Upgrade server to WildFly 10.0.0.CR1
ISPN-5742 - Add global persistent state path configuration
We're working on lots of cool things for 8.1 Final due at the end of
November, so be sure to check our roadmap to see what's coming.
Get it, learn how to use it, help us improve it
Enjoy !
http://infinispan.org
The Infinispan team
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
10 years
Remove cache issues
by Pedro Ruivo
Hi,
I found the following issues with _EmbeddedCacheManager.removeCache()_
while I was helping the LEADS devs. The method removes the cache from
all the nodes in the cluster.
#1 It has different behaviour in the invoker node.
In the invoked node, it removes the configuration from
_configurationOverrides_ field and from _cacheDependencyGraph_. In the
remaining node, it doesn't.
To think: it should remove from _cacheDependencyGraph_ in all the nodes
but keep the configuration.
#2 It tries to remove the cache remotely before locally.
It could be done in parallel and it has a small issue: if a timeout
occurs, it never tries to remove the cache locally.
To think: can we send the request asynchronously?
#3 When passivation is enabled, it first invoke
_PassivationManager.passivateAll()_ and then _PersistenceManager.stop()_.
The former will copy all the data in memory to the cache store and the
later will clear the cache store. We can skip the passivation.
To think: create a _PassivationManager.skipPassivationOnStop()_ (similar
to _PersistenceManager.setClearOnStop()_).
Comments are welcome.
Cheers,
Pedro
10 years
Lucene 5 is coming: pitfalls to consider
by Sanne Grinovero
Hi all,
the Hibernate Search branch upgrading to Apache Lucene 5.2.x is almost
ready, but there are some drawbacks on top of the many nice efficiency
improvements.
# API changes
The API changes are not too bad, and definitely an improvement. I'll
provide a detailed list as usual in the Hibernate Search migration
guide - for now let it suffice to know that it's an easy upgrade for
end users, as long as they were just creating Query instances and not
using the more powerful and complex stuff.
# Sorting
To sort on a field will require an UninvertingReader to wrap the
cached IndexReaders, and the uninverting process is very inefficient.
On top of that, the result of the uninverting process is not
cacheable, so that will need to be repeated on each index, for each
query which is executed.
In short, I expect performance of sorted queries to be quite degraded
in our first milestone using Lucene 5, and we'll have to discuss how
to fix this.
Needless to say, fixing this is a blocking requirement before we can
consider the migration complete.
Sorting will not need an UninvertingReader if the target field has
been indexed as DocValues, but that implies:
- we'll need an explicit, upfront (indexing time) flag to be set
- we'll need to detect if the matching indexing options are
compatible with the runtime query to skip the uninverting process
This is mostly a job for Hibernate Search, but in terms of user
experience it means you have to mark fields for "sortability"
explicitly; will we need to extend the protobuf schema?
Please make sure we'll just have to hook in existing metadata, we
can't fix this after API freeze.
# Filters
We did some clever bitset level optimisations to merge multiple Filter
instances and save memory to cache multiple filter instances, I had to
drop that code as we don't deal with in-heap structures more but the
design is about iterating off heap chunks of data, and resort on the
more traditional Lucene stack for filtering.
I couldn't measure the performance impact yet; it's a significantly
different approach and while it sounds promising on paper, we'll need
some help testing this. The Lucene team can generally be trusted to go
in the better direction, but we'll have to verify if we're using it in
the best way.
# Analyzers
It is no longer possible to override the field->analyzer mapping at
runtime. We did expose this feature as a public API and I found a way
to still do it, but it comes with a performance price tag.
We'll soon deprecate this feature; if you can, start making sure
there's no need for this in Infinispan as at some time in the near
future we'll have to drop this, with no replacement.
# Index encoding
As usual the index encoding evolves and the easy solution is to
rebuild it. Lucene 5 no longer ships with backwards compatible
de-coders, but these are available as separate dependencies. If you
feel the need to be able to read existing indexes, we should include
these.
(I'm including these as private dependencies in the Hibernate Search modules).
Thanks,
Sanne
10 years
Infinispan 8.0.1.Final and 7.2.5.Final
by Tristan Tarrant
Dear all,
we've just cooked two new point releases of Infinispan to address a
number of issues.
The highlights for 8.0.1.Final are:
ISPN-5717 Notify continuous query also when entry expires
ISPN-5591 Simple local cache without interceptor stack. This is an
extremely fast cache with very few features (no transactions, no
indexing, no persistence, etc). Its primary intendend usage is as a
2nd-level cache for Hibernate, but we're sure you can find lot's of
other applications for it, provided you don't require all the bells and
whistles that come with our fully-fledged caches.
Bump Hibernate Search to 5.5.0.CR1 and Lucene to 5.3.0
A number of query fixes, including indexing and searching of null
non-string properties, aggregation expressions in orderBy, filter with
both 'where' and 'having' in the same query
ISPN-5731 Cannot use aggregation expression in orderBy
Read the complete release notes
The highlights for 7.2.5.Final are:
ISPN-5607 Preemptively invalidate near cache after writes
ISPN-5670 Hot Rod server sets -1 for lifespan or maxIdle as default
ISPN-5677 RemoteCache async methods use flags
ISPN-5684 Make getAll work with compatibility mode in DIST
Read the complete release notes
Visit http://infinispan.org to get it, learn how to use and help us
improve it.
Enjoy !
The Infinispan team
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
10 years
