Rerun builds for your PRs
by Sebastian Laskawiec
Hey,
Unfortunately Jenkins had some hiccup after Central CI outage this weekend
and I had to clear the job pending queue.
Please rerun your PR builds by navigating to the PR builds page and using
build now button.
Thanks,
Sebastian
--
SEBASTIAN ŁASKAWIEC
INFINISPAN DEVELOPER
Red Hat EMEA <https://www.redhat.com/>
<https://red.ht/sig>
7 years, 6 months
Proposal for moving Hibernate 2l provider to Infinispan
by Galder Zamarreño
Hi all,
Given all the previous discussions we've had on this list [1] [2], seems like there's a majority of opinions towards moving Infinispan Hibernate 2LC cache provider to the Infinispan repo.
Although we could put it in a completely separate repo, given its importance, I think we should keep it in the main Infinispan repo.
With this in mind, I wanted to propose the following:
1. Move the code Hibernate repository and bring it to Infinispan master and 9.0.x branches. We'd need to introduce the module in the 9.0.x branch so that 9.0.x users are not left out.
2. Create a root directory called `hibernate-orm` within Infinispan main repo. Within it, we'd keep 1 or more cache provider modules based on major Hibernate versions.
3. What should be the artifact name? Should it be 'hibernate-infinispan' like it is today? The difference with the existing cache provider would be the groupId. Or some other artifact id?
4. Should the main artifact contain the hibernate major version it belongs to? E.g. assuming we take 'hibernate-infinispan', should it be like that, or should it instead be 'hibernate5-infinispan'? This is where it'd be interesting to hear about our past Lucene directory or Query integration experience.
5. A thing to consider also is whether to maintain same package naming. We're currently using 'org.hibernate.cache.infinispan.*'. From a compatibility sense, it'd help to keep same package since users reference region factory fully qualified class names. We'd also continue to be sole owners of 'org.hibernate.cache.infinispan.*'. However, I dunno whether having 'org.hibernate...' package name within Infinispan repo would create other issues?
6. Testing wise, the cache provider is currently tested one test at the time, using JUnit. The testsuite already runs fast enough and I'd prefer not to change anything in this area right now. Is that Ok? Or is there any desire to move it to TestNG?
Thoughts? Am I forgetting something?
Cheers,
[1] http://lists.jboss.org/pipermail/infinispan-dev/2017-February/017173.html
[2] http://lists.jboss.org/pipermail/infinispan-dev/2017-May/017546.html
--
Galder Zamarreño
Infinispan, Red Hat
7 years, 6 months
Allocation costs of TypeConverterDelegatingAdvancedCache
by Sanne Grinovero
Hi all,
I've been running some benchmarks and for the fist time playing with
Infinispan 9+, so please bear with me as I might shoot some dumb
questions to the list in the following days.
The need for TypeConverterDelegatingAdvancedCache to wrap most
operations - especially "convertKeys" - is highlighet as one of the
high allocators in my Search-centric use case.
I'm wondering:
A - Could this implementation be improved?
B - Could I bypass / disable it? Not sure why it's there.
Thanks,
Sanne
7 years, 6 months
