Thanks Andy, I appreciate your insight. > It's -Xmx, not --Xmx
A typo from reconstituting the command line from wrapper code. It's definitely allocating heap judging by LSF reports on the job. > I'd have thought 24G is plenty for 23 million triples unless there are many > very large literals. I was averaging about 1GB per million triples during testing, but it runs on less up to a point. >> I have tried the following so far: >> 1. Add heap >> 2. Change JVM to another Java 8 release >> 3. Turn up Fuseki logging - No debug messages obviously indicate an error >> prior to the crash >> Can anybody recommend a course of action to diagnose and fix my issue? > > I hate to say it but it smells a bit like a hardware fault (or JVM fault?), > especially the unpredictability. Anything software is usually reasonably > predictable. Thanks for this. The main thing is that it's not a common occurence for Jena users. I had hoped it was related to some kind of memory allocation error around sort/search buffers or similar, but that is more in the territory of Virtuoso. I am leaning toward the process being ungracefully terminated by the wrapping code, rather than it killing itself from within Fuseki. This is a good thing! Fuseki barked loudest which made me believe it was the issue, but I have good indications that Fuseki is working properly. Thanks again, Kieron
