I'm going to upgrade our Jenkins on CI next week, the 27th of December.
This could be a relatively safe procedure but because our version is
old and we are using several plugins I'm not sure it will go smoothly.
If you have some jobs that need to be executed that day, let me know.
I have pushed a newly updated version of the design.adoc bringing the
discussions up-to-date with the latest code/design.
This PoC work is getting very far along and I really have not had much
feedback. My concern is that this code is only going to become harder to
review (more to look at) as more time passes.
I know digging in the code (it is a lot) is not really feasible, but please
at least take some time to look over the design.adoc in the poc repo.
Feedback sooner is better :)
We just released Hibernate Search 5.6.0.CR1 and 5.7.0.Beta2, with the
latest bugfixes and previously missing features for our experimental
This is the last step before 5.6 is released, so be sure to check it out so
you can share your thoughts with us before the release!
For more information, please see our blog:
Yoann Rodière <yoann(a)hibernate.org>
Hibernate NoORM Team
Query spaces for EntityGraph nodes/subgraphs are not currently added
when applied to a Query, and so the session is not flushed if it
contains updated data relevant to the EntityGraph that is not in the
query spaces defined for the Query.
I originally though this was a critical issue, but now that I'm
looking into it, I'm not so sure. I am having a hard time coming up
with a test case where it matters.
I've created a pull request with the test case attached to HHH-11213,
with some added checks to detect if the session flushes. 
In this case, the session does not flush, but the query results are
still correct because the updated entity is taken from the Session,
not from the ResultSet returned by the query.
I wonder now if it really is necessary to flush the Session when the
session has updates that apply *only* to the EntityGraph (and not to
the base Query).
mysteries of Maven .. it sometimes reports SUCCESS, yet you have to
scroll into the logs to find the error.
I wonder if there's something off in our pom files: it's the the first
time it happens.
Tests in error:
Tests run: 64, Failures: 0, Errors: 1, Skipped: 0
On 15 December 2016 at 15:00, Gustavo Fernandes <gustavonalle(a)gmail.com> wrote:
> I can see BUILD SUCCESS in the logs, what happened?
> On Thu, Dec 15, 2016 at 2:58 PM, Hibernate CI <ci(a)hibernate.org> wrote:
since hibernate-infinispan testsuite has been set on by default,
recently I've set myself to improve the execution time which is several
minutes due to various sleeps and timeouts.
Many of the tests test concurrency issues, and that often involves
issuing two writes to single table/row in DB. In H2, this results in
waiting 10 seconds (as configured default lock timeout), and since the
tests are executed sequentially, the testsuite takes much longer than it
Obvious workaround is reducing this timeout to, say, 100 ms, but this
could lead to a) false positives and b) those 100 ms add up and with
over thousand of tests (for various configurations), this could be
Q: is there any infrastructure in testsuite to hook into the DB, assert
that it's waiting in lock and let the thread time out if everything is
Radim Vansa <rvansa(a)redhat.com>
JBoss Performance Team