That seems a bit strange. I would think that the single dataset lock and
multiple-reader-or-single-writer policy would guard against this-- only one
thread (request) can mutate the dataset at a time. Or is this a problem with
TDB? Do you see this occurring with in-memory datasets?
ajs6f
> On A
Extend StreamRDFWrapper and call super.triple() otherwise the data will
not flow down the pipeline. There are prefixes as well and quads if the
input is trig etc.
@Override
public void triple(Triple triple) {
... process triple ... create newTriple ...
super.triple(newTriple);
}
A
Easier fix that sleeping was to add system wide semaphore which puts all
concurrent requests to single queue.
So the problem is in the way how Fuseki handles situation where
(concurrent) requests are coming in faster that it can process it.
Usually there are 2 ways to handle that: return er
> Since I want triple processing...is extending the StreamRDFBase and
> overriding the method `public void triple(Triple triple)` an option? Is it
> the best option?
That's a reasonable option, or try StreamRDFWrapper [1] and override where
appropriate. Keep in mind that triple-level processing
On 2018/08/03 10:10:34, Andy Seaborne wrote:
>
>
> On 02/08/18 22:17, didac.montero.men...@gmail.com wrote:
> > I'm converting a JSON-LD input to RDF using Jena:
> >
> > Model m = ModelFactory.createDefaultModel;
> > String str_reader = new StringReader(json.noSpaces)
> > RDFDataMgr.read(m,
On 02/08/18 22:17, didac.montero.men...@gmail.com wrote:
I'm converting a JSON-LD input to RDF using Jena:
Model m = ModelFactory.createDefaultModel;
String str_reader = new StringReader(json.noSpaces)
RDFDataMgr.read(m, str_reader, "", RDFFormat.JSONLD.getLang)
