Useful report.
This does not look like a serious problem. It may be test-specific -
tests call RIOT.init all over the place so two colliding, one via the
reflection hook, is possible. If so, it will not happen in deployment.
If it does the temporary workaround is call ARQ.init() before going
multithreaded.
I'll armor RIOT.init() anyway.
Andy
-------- Original Message --------
Subject: Re: Jena 2.10.0 : request for pre-release testing
Date: Thu, 21 Feb 2013 18:31:06 +0000
From: Andy Seaborne <a...@apache.org>
To: us...@jena.apache.org
On 21/02/13 13:45, Stephen Owens wrote:
We built and ran 2.10.0 against all internal tests and got good results.
There didn't appear to be any regression errors in functionality and the
new Maven structure is a good thing.
We are tracking one error in multi-threaded access to the results of
construct query execution. I'll try to create a good reproducible case for
that and submit it to Jira. This is behaviour that was present in previous
releases so I don't think it is a regression in 2.10.0.
The only odd behaviour that seems to only be present in 2.10.0 is that when
running JUnit tests with parallel execution via Maven the tests hang in
Jena at:
org.apache.jena.riot.RIOT.<clinit>(RIOT.java:38) and
com.hp.hpl.jena.rdf.model.ModelFactory.createDefaultModel(ModelFactory.java:140).
This is only true when the tests are forked. I'll create a Jira issue for
that as well.
Stephen,
Thank you for the report, especially as it's positive (mostly) :-)
If you have a stacktrace and an indication as to which tests lock up
that would helpful. Do your tests specifically call RIOT?
The first use of ModelFactory.createDefaultModel does call into RIOT
inside a double locked initializer - I'm guessing but there may be a
another direct RIOT.init call in the tests. This would not happen in
application code; the tests are a bit different as some do specific
initializations so they run stand-alone as well.
Assuming the lock up is in the first tests to run, I can see that the
RIOT.init is not using full double locking although it does use the
class initialization device for initialization. However, I have
encountered class initialization problems before where one class
initializes depending on another where full class initialization may not
be complete at the right time where reflection call is involved and it
is here. We can armour the RIOT initialization code.
Thanks,
Andy
