Saxon

On first attempt, I can't reproduce the problem. It's an intermittent problem so that's not entirely surprising. Next step might be to try loading the schema concurrently in several threads into the same Configuration.

I've now set up a test that is compiling the same schema in 100 threads in parallel (into the same Configuration) and I'm getting a variety of failures. I'm not getting a StackOverflow, but it's clearly not working properly and it wouldn't surprise me if a StackOverflow were a possible symptom.

The bad news is that there appears to be no attempt to make schema compilation thread-safe. There doesn't seem to be any synchronization of the relevant methods on the Configuration for loading a schema, and the data structures used within the Configuration (which are updated incrementally as a schema is compiled) are regular HashMaps, rather than thread-safe varieties thereof.

I think the way this was supposed to work is that we process and validate a schema, to the maximum extent possible, in thread-local memory (specifically, in the SchemaCompiler) before copying the schema components over into shared configuration space. But it looks like pulling that design into shape might be significant effort. In the meantime, I guess we just have to do some fairly crude synchronization,

Synchronizing at the level of EnterpriseConfiguration.addSchemaSource() does the job (the test passes) but it would be nice to do better.

Also established that synchronizing at a finer-grained level isn't good enough. The problem is that we process each xs:import as we encounter it.

Raised internal issue #5982 to look at longer-term redesign options in this area.