On 29/04/13 12:38, Lebling, David (US SSA) wrote:
Andy,

The ClassNotFound is just some internal reorganisation to improve
the modularity of the code base.  That's why I'd prefer not to let
SDB get too out of sync with the main releases.

I can understand that. The exact problem has to do with other
third-party code we are using and cannot update to a newer version.
In the end there is a tangle of four different versions of xercesImpl
that ends up with the wrong one being loaded for SDB (or possibly
Jena itself, since the dependency is IIRC in your parent POM).

Always a problem.

Despite having to name an explicit version, Jena is not actually
particularly sensitive to the Xerces version anymore at least to within a few minor versions. Jena does call into Xerces "internals" but they are so widely used they are a de facto API nowadays.

Or you can download the source and rebuild with a different Xerces version and see if it works.

Similarly, using a newer version of Xerces other packages is often worth ago if you can.


Was there a JIRA raised for the "duplicate node" error?

You posted on 4/17 some ruminations on the cause, etc. I did not
raise a JIRA, so if you didn't my guess is there isn't one.

Could you raise a JIRA please?

        Andy


Seeing that error message makes it a bit clearer to me. It's
something to do with the bulk loader (NNodeQuads1740763164) and
some othe raction has already inserted a node.  As the possible
values for a row in the node table are fixed for a given primary
key, I wonder if it's possible to insert but ignore duplicates
(which won't an a different duplicate). And maybe the  LOCK TABLE
needs to be further out. (/me hopes Damian has better insight
here)

WARN [tomcat-http--10] (SDBConnection.java:338) - execUpdate:
SQLException ERROR: duplicate key value violates unique constraint
"nodes_pkey" Detail: Key (hash)=(-8555076428185164481) already
exists. LOCK TABLE Nodes; INSERT INTO Nodes (hash, lex, lang,
datatype, type) SELECT NNodeQuads1740763164.n0 ,
NNodeQuads1740763164.n1 , NNodeQuads1740763164.n2 ,
NNodeQuads1740763164.n3 , NNodeQuads1740763164.n4 FROM
NNodeQuads1740763164 LEFT JOIN Nodes ON
(NNodeQuads1740763164.n0=Nodes.hash) WHERE Nodes.hash IS NULL

Andy

-----Original Message----- From: Andy Seaborne
[mailto:[email protected]]main Sent: Friday, April 26, 2013 6:12 AM To:
[email protected] Subject: Re: Jena 2.10.1 / SDB 1.3.6 -- testing
for next release

On 25/04/13 22:04, Lebling, David (US SSA) wrote:
Andy,

I'd love to be able to test SDB 1.3.6 but we are not able to update
to Jena 2.10.1 for reasons too tedious to go into here, and trying
to use this SDB with an older version of Jena (*cough* 2.7.3
*cough)

Cough and splutter.

doesn't seem to work, probably not to your surprise. The exact
exception is: "Caused by: java.lang.ClassNotFoundException:
org.apache.jena.atlas.lib.Lib". SDB 1.3.5 worked fine in that
environment, aside from the SDB "duplicate node" error I reported
earlier.



Dave Lebling

-----Original Message----- From: Andy Seaborne
[mailto:[email protected]] Sent: Thursday, April 25, 2013 3:51 PM
To: [email protected] Subject: Jena 2.10.1 / SDB 1.3.6 --
testing for next release

We'd like to get testing reports on the current Jena development
build over the next few weeks for a release of Jena 2.10.1.

You can get a copy of the development build (via maven dependency
or a download):

http://jena.staging.apache.org/download/index.html#development-builds





There are two areas of special note: Turtle output and query timeouts.

== Turtle output

The writer for Turtle which has been rewritten. The exact output
layout of the Turtle may change.

Full details of using the writing subsystem:
http://jena.staging.apache.org/documentation/io/rdf-output.html

== Query timeouts (including in Fuseki)

Timeouts were not firing in the right places so that often the
time-to-first-row was remaining and behaving as the
time-to-last-row. This is fixed - if you use query timeouts in
Fuseki you'll see a difference in behaviour if you had timeouts
going off.

Also The status code from a timeouts query was incorrectly 408 -
it's now 503.

== SDB

At the same time, we'd like to do a separate, coordinated release
of SDB to align the libraries.

But we need help from SDB users in order to get proper testing of
SDB. Please test 1.3.6-SNAPSHOT

(if there aren't enough test reports, we'll have to then see
whether a release of SDB is a good idea or not)

Andy



Reply via email to