Andy, Sorry, I was in meetings all afternoon. I created a bug to track it. The issue is here: https://issues.apache.org/jira/browse/JENA-400
with source of the test cases and the stack trace. Let me know if you need anything else. On Thu, Feb 21, 2013 at 1:31 PM, Andy Seaborne <[email protected]> wrote: > 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 > > -- Regards, * * *Stephen Owens* CTO, ThoughtWire t 647.351.9473 ext.104 I m 416.697.3466
