[jira] [Commented] (JENA-1121) Performance regression in Jena 3.0.1 / Fuseki 2.3.1

[Andy Seaborne (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15105900#comment-15105900
 ] 

Andy Seaborne commented on JENA-1121:
-

Benjamin - that's quite a large query. Do you have a shorter version that 
illustrates the difference?

e.g. does ORDER/no ORDER make a difference? The GROUP BY?

and does the OPTIONAL make a difference?


> Performance regression in Jena 3.0.1 / Fuseki 2.3.1
> ---
>
> Key: JENA-1121
> URL: https://issues.apache.org/jira/browse/JENA-1121
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Jena
>Affects Versions: Jena 3.0.1, Fuseki 2.3.1, Jena 3.1.0, Fuseki 2.4.0
> Environment: Mac OS X 10.10.5, iMac, 3.4 GHz Intel Core i7, 32 GB RAM
>Reporter: Benjamin Geer
>Priority: Critical
>  Labels: performance
>
> We seem to have encountered a severe performance regression in Jena 3.0.1 / 
> Fuseki 2.3.1 as compared with Jena 3.0.0 / Fuseki 2.3.0. A number of our 
> queries are running between 2 and 20 times slower. Here's one small example 
> with configuration for Fuseki. With Fuseki 2.3.0, the query below takes about 
> 200 milliseconds. With Fuseki 2.3.1, it takes 9 seconds. I've also tried it 
> with the latest Fuseki snapshot 
> (apache-jena-fuseki-2.4.0-20160117.183513-33.zip), and got the same result as 
> with the 2.3.1 release.
> Here's the test data and configuration:
> https://www.dropbox.com/s/b9aepexij5e7noj/jena-performance-test.zip?dl=0
> Here's the query:
> {noformat}
> prefix rdf: 
> prefix rdfs: 
> prefix knora-base: 
> SELECT DISTINCT
> ?resourceIri
> ?resourceLabel
> (SAMPLE(?anyMatch) AS ?match)
> WHERE {
> BIND(STR("de") AS ?preferredLanguage)
> BIND(STR("en") AS ?fallbackLanguage)
> ?s  'Zeitglöcklein' .
> MINUS {
> ?s knora-base:isDeleted true .
> }
> OPTIONAL {
> ?s a ?valueObjectType .
> ?valueObjectType rdfs:subClassOf+ knora-base:Value .
> ?resIri ?resourceProperty ?s .
> ?s knora-base:valueHasString ?literal .
> OPTIONAL {
> ?resourceProperty rdfs:label 
> ?preferredLanguageResourcePropertyLabel .
> FILTER (LANG(?preferredLanguageResourcePropertyLabel) = 
> ?preferredLanguage) .
> }
> OPTIONAL {
> ?resourceProperty rdfs:label 
> ?fallbackLanguageResourcePropertyLabel .
> FILTER (LANG(?fallbackLanguageResourcePropertyLabel) = 
> ?fallbackLanguage) .
> }
> OPTIONAL {
> ?resourceProperty rdfs:label ?anyLanguageResourcePropertyLabel .
> }
> BIND(COALESCE(str(?preferredLanguageResourcePropertyLabel), 
> str(?fallbackLanguageResourcePropertyLabel), 
> str(?anyLanguageResourcePropertyLabel)) AS ?propertyLabel)
> BIND(CONCAT(STR(?valueObjectType), "|", STR(?propertyLabel), "|", 
> STR(?literal)) AS ?anyMatch)
> MINUS {
> ?resIri knora-base:isDeleted true .
> }
> }
> BIND(COALESCE(?resIri, ?s) AS ?resourceIri)
> ?resourceIri a ?resourceClass .
> ?resourceClass rdfs:subClassOf+ knora-base:Resource .
> ?resourceIri rdfs:label ?resourceLabel .
> }
> GROUP BY
> ?resourceIri
> ?resourceLabel
> ORDER BY ?resourceIri
> {noformat}
> Best regards,
> Benjamin Geer



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-1121) Performance regression in Jena 3.0.1 / Fuseki 2.3.1

[Benjamin Geer (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15105876#comment-15105876
 ] 

Benjamin Geer commented on JENA-1121:
-

I should add that the query returns 3 results.

> Performance regression in Jena 3.0.1 / Fuseki 2.3.1
> ---
>
> Key: JENA-1121
> URL: https://issues.apache.org/jira/browse/JENA-1121
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Jena
>Affects Versions: Jena 3.0.1, Fuseki 2.3.1, Jena 3.1.0, Fuseki 2.4.0
> Environment: Mac OS X 10.10.5, iMac, 3.4 GHz Intel Core i7, 32 GB RAM
>Reporter: Benjamin Geer
>Priority: Critical
>  Labels: performance
>
> We seem to have encountered a severe performance regression in Jena 3.0.1 / 
> Fuseki 2.3.1 as compared with Jena 3.0.0 / Fuseki 2.3.0. A number of our 
> queries are running between 2 and 20 times slower. Here's one small example 
> with configuration for Fuseki. With Fuseki 2.3.0, the query below takes about 
> 200 milliseconds. With Fuseki 2.3.1, it takes 9 seconds. I've also tried it 
> with the latest Fuseki snapshot 
> (apache-jena-fuseki-2.4.0-20160117.183513-33.zip), and got the same result as 
> with the 2.3.1 release.
> Here's the test data and configuration:
> https://www.dropbox.com/s/b9aepexij5e7noj/jena-performance-test.zip?dl=0
> Here's the query:
> {noformat}
> prefix rdf: 
> prefix rdfs: 
> prefix knora-base: 
> SELECT DISTINCT
> ?resourceIri
> ?resourceLabel
> (SAMPLE(?anyMatch) AS ?match)
> WHERE {
> BIND(STR("de") AS ?preferredLanguage)
> BIND(STR("en") AS ?fallbackLanguage)
> ?s  'Zeitglöcklein' .
> MINUS {
> ?s knora-base:isDeleted true .
> }
> OPTIONAL {
> ?s a ?valueObjectType .
> ?valueObjectType rdfs:subClassOf+ knora-base:Value .
> ?resIri ?resourceProperty ?s .
> ?s knora-base:valueHasString ?literal .
> OPTIONAL {
> ?resourceProperty rdfs:label 
> ?preferredLanguageResourcePropertyLabel .
> FILTER (LANG(?preferredLanguageResourcePropertyLabel) = 
> ?preferredLanguage) .
> }
> OPTIONAL {
> ?resourceProperty rdfs:label 
> ?fallbackLanguageResourcePropertyLabel .
> FILTER (LANG(?fallbackLanguageResourcePropertyLabel) = 
> ?fallbackLanguage) .
> }
> OPTIONAL {
> ?resourceProperty rdfs:label ?anyLanguageResourcePropertyLabel .
> }
> BIND(COALESCE(str(?preferredLanguageResourcePropertyLabel), 
> str(?fallbackLanguageResourcePropertyLabel), 
> str(?anyLanguageResourcePropertyLabel)) AS ?propertyLabel)
> BIND(CONCAT(STR(?valueObjectType), "|", STR(?propertyLabel), "|", 
> STR(?literal)) AS ?anyMatch)
> MINUS {
> ?resIri knora-base:isDeleted true .
> }
> }
> BIND(COALESCE(?resIri, ?s) AS ?resourceIri)
> ?resourceIri a ?resourceClass .
> ?resourceClass rdfs:subClassOf+ knora-base:Resource .
> ?resourceIri rdfs:label ?resourceLabel .
> }
> GROUP BY
> ?resourceIri
> ?resourceLabel
> ORDER BY ?resourceIri
> {noformat}
> Best regards,
> Benjamin Geer



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JENA-1121) Performance regression in Jena 3.0.1 / Fuseki 2.3.1

[Andy Seaborne (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andy Seaborne updated JENA-1121:

Description: 
We seem to have encountered a severe performance regression in Jena 3.0.1 / 
Fuseki 2.3.1 as compared with Jena 3.0.0 / Fuseki 2.3.0. A number of our 
queries are running between 2 and 20 times slower. Here's one small example 
with configuration for Fuseki. With Fuseki 2.3.0, the query below takes about 
200 milliseconds. With Fuseki 2.3.1, it takes 9 seconds. I've also tried it 
with the latest Fuseki snapshot 
(apache-jena-fuseki-2.4.0-20160117.183513-33.zip), and got the same result as 
with the 2.3.1 release.

Here's the test data and configuration:

https://www.dropbox.com/s/b9aepexij5e7noj/jena-performance-test.zip?dl=0

Here's the query:
{noformat}
prefix rdf: 
prefix rdfs: 
prefix knora-base: 

SELECT DISTINCT
?resourceIri
?resourceLabel
(SAMPLE(?anyMatch) AS ?match)

WHERE {
BIND(STR("de") AS ?preferredLanguage)
BIND(STR("en") AS ?fallbackLanguage)

?s  'Zeitglöcklein' .

MINUS {
?s knora-base:isDeleted true .
}

OPTIONAL {
?s a ?valueObjectType .
?valueObjectType rdfs:subClassOf+ knora-base:Value .
?resIri ?resourceProperty ?s .
?s knora-base:valueHasString ?literal .

OPTIONAL {
?resourceProperty rdfs:label 
?preferredLanguageResourcePropertyLabel .
FILTER (LANG(?preferredLanguageResourcePropertyLabel) = 
?preferredLanguage) .
}

OPTIONAL {
?resourceProperty rdfs:label ?fallbackLanguageResourcePropertyLabel 
.
FILTER (LANG(?fallbackLanguageResourcePropertyLabel) = 
?fallbackLanguage) .
}

OPTIONAL {
?resourceProperty rdfs:label ?anyLanguageResourcePropertyLabel .
}

BIND(COALESCE(str(?preferredLanguageResourcePropertyLabel), 
str(?fallbackLanguageResourcePropertyLabel), 
str(?anyLanguageResourcePropertyLabel)) AS ?propertyLabel)

BIND(CONCAT(STR(?valueObjectType), "|", STR(?propertyLabel), "|", 
STR(?literal)) AS ?anyMatch)

MINUS {
?resIri knora-base:isDeleted true .
}
}

BIND(COALESCE(?resIri, ?s) AS ?resourceIri)

?resourceIri a ?resourceClass .
?resourceClass rdfs:subClassOf+ knora-base:Resource .
?resourceIri rdfs:label ?resourceLabel .
}

GROUP BY
?resourceIri
?resourceLabel

ORDER BY ?resourceIri
{noformat}

Best regards,
Benjamin Geer

  was:
We seem to have encountered a severe performance regression in Jena 3.0.1 / 
Fuseki 2.3.1 as compared with Jena 3.0.0 / Fuseki 2.3.0. A number of our 
queries are running between 2 and 20 times slower. Here's one small example 
with configuration for Fuseki. With Fuseki 2.3.0, the query below takes about 
200 milliseconds. With Fuseki 2.3.1, it takes 9 seconds. I've also tried it 
with the latest Fuseki snapshot 
(apache-jena-fuseki-2.4.0-20160117.183513-33.zip), and got the same result as 
with the 2.3.1 release.

Here's the test data and configuration:

https://www.dropbox.com/s/b9aepexij5e7noj/jena-performance-test.zip?dl=0

Here's the query:

prefix rdf: 
prefix rdfs: 
prefix knora-base: 

SELECT DISTINCT
?resourceIri
?resourceLabel
(SAMPLE(?anyMatch) AS ?match)

WHERE {
BIND(STR("de") AS ?preferredLanguage)
BIND(STR("en") AS ?fallbackLanguage)

?s  'Zeitglöcklein' .

MINUS {
?s knora-base:isDeleted true .
}

OPTIONAL {
?s a ?valueObjectType .
?valueObjectType rdfs:subClassOf+ knora-base:Value .
?resIri ?resourceProperty ?s .
?s knora-base:valueHasString ?literal .

OPTIONAL {
?resourceProperty rdfs:label 
?preferredLanguageResourcePropertyLabel .
FILTER (LANG(?preferredLanguageResourcePropertyLabel) = 
?preferredLanguage) .
}

OPTIONAL {
?resourceProperty rdfs:label ?fallbackLanguageResourcePropertyLabel 
.
FILTER (LANG(?fallbackLanguageResourcePropertyLabel) = 
?fallbackLanguage) .
}

OPTIONAL {
?resourceProperty rdfs:label ?anyLanguageResourcePropertyLabel .
}

BIND(COALESCE(str(?preferredLanguageResourcePropertyLabel), 
str(?fallbackLanguageResourcePropertyLabel), 
str(?anyLanguageResourcePropertyLabel)) AS ?propertyLabel)

BIND(CONCAT(STR(?valueObjectType), "|", STR(?propertyLabel), "|", 
STR(?literal)) AS ?anyMatch)

MINUS {
?resIri knora-base:isDeleted true .
}
}

BIND(COALESCE(?resIri, ?s) AS ?resourceIri)

?resourceIri a ?re

[jira] [Commented] (JENA-1121) Performance regression in Jena 3.0.1 / Fuseki 2.3.1

[Benjamin Geer (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15105614#comment-15105614
 ] 

Benjamin Geer commented on JENA-1121:
-

I've just noticed something important:

If I load the test data with Fuseki 2.3.0, and then run the query with Fuseki 
2.3.1, it runs fast. But if I load the test data *and* run the query with 
Fuseki 2.3.1, the query runs slowly.

> Performance regression in Jena 3.0.1 / Fuseki 2.3.1
> ---
>
> Key: JENA-1121
> URL: https://issues.apache.org/jira/browse/JENA-1121
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Jena
>Affects Versions: Jena 3.0.1, Fuseki 2.3.1, Jena 3.1.0, Fuseki 2.4.0
> Environment: Mac OS X 10.10.5, iMac, 3.4 GHz Intel Core i7, 32 GB RAM
>Reporter: Benjamin Geer
>Priority: Critical
>  Labels: performance
>
> We seem to have encountered a severe performance regression in Jena 3.0.1 / 
> Fuseki 2.3.1 as compared with Jena 3.0.0 / Fuseki 2.3.0. A number of our 
> queries are running between 2 and 20 times slower. Here's one small example 
> with configuration for Fuseki. With Fuseki 2.3.0, the query below takes about 
> 200 milliseconds. With Fuseki 2.3.1, it takes 9 seconds. I've also tried it 
> with the latest Fuseki snapshot 
> (apache-jena-fuseki-2.4.0-20160117.183513-33.zip), and got the same result as 
> with the 2.3.1 release.
> Here's the test data and configuration:
> https://www.dropbox.com/s/b9aepexij5e7noj/jena-performance-test.zip?dl=0
> Here's the query:
> prefix rdf: 
> prefix rdfs: 
> prefix knora-base: 
> SELECT DISTINCT
> ?resourceIri
> ?resourceLabel
> (SAMPLE(?anyMatch) AS ?match)
> WHERE {
> BIND(STR("de") AS ?preferredLanguage)
> BIND(STR("en") AS ?fallbackLanguage)
> ?s  'Zeitglöcklein' .
> MINUS {
> ?s knora-base:isDeleted true .
> }
> OPTIONAL {
> ?s a ?valueObjectType .
> ?valueObjectType rdfs:subClassOf+ knora-base:Value .
> ?resIri ?resourceProperty ?s .
> ?s knora-base:valueHasString ?literal .
> OPTIONAL {
> ?resourceProperty rdfs:label 
> ?preferredLanguageResourcePropertyLabel .
> FILTER (LANG(?preferredLanguageResourcePropertyLabel) = 
> ?preferredLanguage) .
> }
> OPTIONAL {
> ?resourceProperty rdfs:label 
> ?fallbackLanguageResourcePropertyLabel .
> FILTER (LANG(?fallbackLanguageResourcePropertyLabel) = 
> ?fallbackLanguage) .
> }
> OPTIONAL {
> ?resourceProperty rdfs:label ?anyLanguageResourcePropertyLabel .
> }
> BIND(COALESCE(str(?preferredLanguageResourcePropertyLabel), 
> str(?fallbackLanguageResourcePropertyLabel), 
> str(?anyLanguageResourcePropertyLabel)) AS ?propertyLabel)
> BIND(CONCAT(STR(?valueObjectType), "|", STR(?propertyLabel), "|", 
> STR(?literal)) AS ?anyMatch)
> MINUS {
> ?resIri knora-base:isDeleted true .
> }
> }
> BIND(COALESCE(?resIri, ?s) AS ?resourceIri)
> ?resourceIri a ?resourceClass .
> ?resourceClass rdfs:subClassOf+ knora-base:Resource .
> ?resourceIri rdfs:label ?resourceLabel .
> }
> GROUP BY
> ?resourceIri
> ?resourceLabel
> ORDER BY ?resourceIri
> Best regards,
> Benjamin Geer



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (JENA-1121) Performance regression in Jena 3.0.1 / Fuseki 2.3.1

[Benjamin Geer (JIRA)]

Benjamin Geer created JENA-1121:
---

 Summary: Performance regression in Jena 3.0.1 / Fuseki 2.3.1
 Key: JENA-1121
 URL: https://issues.apache.org/jira/browse/JENA-1121
 Project: Apache Jena
  Issue Type: Bug
  Components: Jena
Affects Versions: Fuseki 2.3.1, Jena 3.0.1, Jena 3.1.0, Fuseki 2.4.0
 Environment: Mac OS X 10.10.5, iMac, 3.4 GHz Intel Core i7, 32 GB RAM
Reporter: Benjamin Geer
Priority: Critical


We seem to have encountered a severe performance regression in Jena 3.0.1 / 
Fuseki 2.3.1 as compared with Jena 3.0.0 / Fuseki 2.3.0. A number of our 
queries are running between 2 and 20 times slower. Here's one small example 
with configuration for Fuseki. With Fuseki 2.3.0, the query below takes about 
200 milliseconds. With Fuseki 2.3.1, it takes 9 seconds. I've also tried it 
with the latest Fuseki snapshot 
(apache-jena-fuseki-2.4.0-20160117.183513-33.zip), and got the same result as 
with the 2.3.1 release.

Here's the test data and configuration:

https://www.dropbox.com/s/b9aepexij5e7noj/jena-performance-test.zip?dl=0

Here's the query:

prefix rdf: 
prefix rdfs: 
prefix knora-base: 

SELECT DISTINCT
?resourceIri
?resourceLabel
(SAMPLE(?anyMatch) AS ?match)

WHERE {
BIND(STR("de") AS ?preferredLanguage)
BIND(STR("en") AS ?fallbackLanguage)

?s  'Zeitglöcklein' .

MINUS {
?s knora-base:isDeleted true .
}

OPTIONAL {
?s a ?valueObjectType .
?valueObjectType rdfs:subClassOf+ knora-base:Value .
?resIri ?resourceProperty ?s .
?s knora-base:valueHasString ?literal .

OPTIONAL {
?resourceProperty rdfs:label 
?preferredLanguageResourcePropertyLabel .
FILTER (LANG(?preferredLanguageResourcePropertyLabel) = 
?preferredLanguage) .
}

OPTIONAL {
?resourceProperty rdfs:label ?fallbackLanguageResourcePropertyLabel 
.
FILTER (LANG(?fallbackLanguageResourcePropertyLabel) = 
?fallbackLanguage) .
}

OPTIONAL {
?resourceProperty rdfs:label ?anyLanguageResourcePropertyLabel .
}

BIND(COALESCE(str(?preferredLanguageResourcePropertyLabel), 
str(?fallbackLanguageResourcePropertyLabel), 
str(?anyLanguageResourcePropertyLabel)) AS ?propertyLabel)

BIND(CONCAT(STR(?valueObjectType), "|", STR(?propertyLabel), "|", 
STR(?literal)) AS ?anyMatch)

MINUS {
?resIri knora-base:isDeleted true .
}
}

BIND(COALESCE(?resIri, ?s) AS ?resourceIri)

?resourceIri a ?resourceClass .
?resourceClass rdfs:subClassOf+ knora-base:Resource .
?resourceIri rdfs:label ?resourceLabel .
}

GROUP BY
?resourceIri
?resourceLabel

ORDER BY ?resourceIri

Best regards,
Benjamin Geer



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-1104) LockObtainFailedException for text index

[Andy Seaborne (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15105540#comment-15105540
 ] 

Andy Seaborne commented on JENA-1104:
-

Sharing text indexes between text datasets will not work (it'll break on update 
if not before).

Sharing text datasets would work.

> LockObtainFailedException for text index
> 
>
> Key: JENA-1104
> URL: https://issues.apache.org/jira/browse/JENA-1104
> Project: Apache Jena
>  Issue Type: Bug
>  Components: Fuseki
>Affects Versions: Fuseki 2.3.1
> Environment: CentOS 5.11
> Java 1.8.0_45-b14
> Tomcat 7.0.62
>Reporter: Joachim Neubert
>
> When starting Fuseki2 under Tomcat, on Centos 5 I get an exception which I 
> have not seen on Centos 7:
> {quote}
> SEVERE: Exception sending context initialized event to listener instance of 
> class org.apache.jena.fuseki.server.FusekiServerListener
> org.apache.jena.assembler.exceptions.AssemblerException: caught: 
> org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: 
> NativeFSLock@/opt/thes/var/gn
> d/2015-10-13/tdb_lucene/write.lock: 
> java.nio.channels.OverlappingFileLockException
>   doing:
> root: file:///opt/fuseki2/run/configuration/gnd.ttl#gndIndex with type: 
> http://jena.apache.org/text#TextIndexLucene assembler class: class 
> org.apache.jena.query.tex
> t.assembler.TextIndexLuceneAssembler
> root: file:///opt/fuseki2/run/configuration/gnd.ttl#gnd with type: 
> http://jena.apache.org/text#TextDataset assembler class: class 
> org.apache.jena.query.text.assembl
> er.TextDatasetAssembler
> at 
> org.apache.jena.assembler.assemblers.AssemblerGroup$PlainAssemblerGroup.openBySpecificType(AssemblerGroup.java:138)
> ...
> {quote}
> The very strange thing is that tomcat actually *has* created the write.lock 
> file in that directory (which I had removed before).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: VERSION and BUILD_DATE for jena-sdb commands

[Andy Seaborne]

On 18/01/16 12:37, Osma Suominen wrote:

Hi,

I've recently reenabled building of the jena-sdb distribution (see
JENA-1118). After building the packages, I noticed that the --version
flag gives the versions of Jena, ARQ and RIOT, but the version and build
date information for SDB itself is missing:

$ sdbinfo --version
Jena:   VERSION: 3.1.0-SNAPSHOT
Jena:   BUILD_DATE: 2016-01-14T09:48:43+
ARQ:VERSION: 3.1.0-SNAPSHOT
ARQ:BUILD_DATE: 2016-01-17T18:26:28+
RIOT:   VERSION: 3.1.0-SNAPSHOT
RIOT:   BUILD_DATE: 2016-01-17T18:26:28+
SDB:VERSION: unknown
SDB:BUILD_DATE: unset


Forgive my ignorance, but how is this determined/stored and where can I
fix it? To my eyes, the jena-sdb pom.xml looks similar to the other
modules and has version information among other things, but somewhere
along the way it gets lost apparently.

Older versions of SDB distributions did show this correctly.

-Osma



There is a file
src/main/resources/org/apache/jena/sdb/sdb-properties.xml
that gets maven-processed to hard wire the
build details. (So under Eclipse it is wrong - it's a filtered maven 
resource).


But the resource path name to it in the java was wrong.

I was fixing up initialization as the init code wasn't firing 
automatically (useful in Fuseki) and moved the properties file but 
mistyped the resource name in SDB.java.


Should be fixed now. I must have left some maven-generated files around.

Andy

PS What I don't understand is why the SDB command line tools are so slow 
to start up.

VERSION and BUILD_DATE for jena-sdb commands

[Osma Suominen]

Hi,

I've recently reenabled building of the jena-sdb distribution (see 
JENA-1118). After building the packages, I noticed that the --version 
flag gives the versions of Jena, ARQ and RIOT, but the version and build 
date information for SDB itself is missing:


$ sdbinfo --version
Jena:   VERSION: 3.1.0-SNAPSHOT
Jena:   BUILD_DATE: 2016-01-14T09:48:43+
ARQ:VERSION: 3.1.0-SNAPSHOT
ARQ:BUILD_DATE: 2016-01-17T18:26:28+
RIOT:   VERSION: 3.1.0-SNAPSHOT
RIOT:   BUILD_DATE: 2016-01-17T18:26:28+
SDB:VERSION: unknown
SDB:BUILD_DATE: unset


Forgive my ignorance, but how is this determined/stored and where can I 
fix it? To my eyes, the jena-sdb pom.xml looks similar to the other 
modules and has version information among other things, but somewhere 
along the way it gets lost apparently.


Older versions of SDB distributions did show this correctly.

-Osma


--
Osma Suominen
D.Sc. (Tech), Information Systems Specialist
National Library of Finland
P.O. Box 26 (Kaikukatu 4)
00014 HELSINGIN YLIOPISTO
Tel. +358 50 3199529
osma.suomi...@helsinki.fi
http://www.nationallibrary.fi

[jira] [Resolved] (JENA-1120) bashisms in jena-sdb/bin/make_classpath

[Osma Suominen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Osma Suominen resolved JENA-1120.
-
   Resolution: Fixed
Fix Version/s: Jena 3.1.0

> bashisms in jena-sdb/bin/make_classpath
> ---
>
> Key: JENA-1120
> URL: https://issues.apache.org/jira/browse/JENA-1120
> Project: Apache Jena
>  Issue Type: Bug
>  Components: SDB
>Affects Versions: Jena 3.0.1
> Environment: Ubuntu 12.04
>Reporter: Osma Suominen
>Assignee: Osma Suominen
> Fix For: Jena 3.1.0
>
>
> The script make_classpath is called indirectly by the SDB command line 
> utilities. The shebang line sets it to be interpreted using /bin/sh but parts 
> of the script seem to rely on bash-specific features. On Ubuntu and Debian 
> systems at least, /bin/sh is nowadays often symlinked to dash which only 
> implements the POSIX standard parts (see https://wiki.ubuntu.com/DashAsBinSh 
> for background). 
> This leads to errors such as this one:
> {noformat}
> $ sdbinfo
> /home/oisuomin/sw/jena-sdb-3.1.0-SNAPSHOT/bin/make_classpath: 63: 
> /home/oisuomin/sw/jena-sdb-3.1.0-SNAPSHOT/bin/make_classpath: Bad substitution
> Error: Could not find or load main class sdb.sdbinfo
> {noformat}
> The simple fix is to change the interpreter to /bin/bash and I will do that 
> very soon.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-1120) bashisms in jena-sdb/bin/make_classpath

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15105071#comment-15105071
 ] 

ASF subversion and git services commented on JENA-1120:
---

Commit 35e964a5eb99e15c479c67f81f5e414105b3a64a in jena's branch 
refs/heads/master from [~osma]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=35e964a ]

JENA-1120: set interpreter to /bin/bash because script contains bashisms


> bashisms in jena-sdb/bin/make_classpath
> ---
>
> Key: JENA-1120
> URL: https://issues.apache.org/jira/browse/JENA-1120
> Project: Apache Jena
>  Issue Type: Bug
>  Components: SDB
>Affects Versions: Jena 3.0.1
> Environment: Ubuntu 12.04
>Reporter: Osma Suominen
>Assignee: Osma Suominen
> Fix For: Jena 3.1.0
>
>
> The script make_classpath is called indirectly by the SDB command line 
> utilities. The shebang line sets it to be interpreted using /bin/sh but parts 
> of the script seem to rely on bash-specific features. On Ubuntu and Debian 
> systems at least, /bin/sh is nowadays often symlinked to dash which only 
> implements the POSIX standard parts (see https://wiki.ubuntu.com/DashAsBinSh 
> for background). 
> This leads to errors such as this one:
> {noformat}
> $ sdbinfo
> /home/oisuomin/sw/jena-sdb-3.1.0-SNAPSHOT/bin/make_classpath: 63: 
> /home/oisuomin/sw/jena-sdb-3.1.0-SNAPSHOT/bin/make_classpath: Bad substitution
> Error: Could not find or load main class sdb.sdbinfo
> {noformat}
> The simple fix is to change the interpreter to /bin/bash and I will do that 
> very soon.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (JENA-1120) bashisms in jena-sdb/bin/make_classpath

[Osma Suominen (JIRA)]

Osma Suominen created JENA-1120:
---

 Summary: bashisms in jena-sdb/bin/make_classpath
 Key: JENA-1120
 URL: https://issues.apache.org/jira/browse/JENA-1120
 Project: Apache Jena
  Issue Type: Bug
  Components: SDB
Affects Versions: Jena 3.0.1
 Environment: Ubuntu 12.04
Reporter: Osma Suominen
Assignee: Osma Suominen


The script make_classpath is called indirectly by the SDB command line 
utilities. The shebang line sets it to be interpreted using /bin/sh but parts 
of the script seem to rely on bash-specific features. On Ubuntu and Debian 
systems at least, /bin/sh is nowadays often symlinked to dash which only 
implements the POSIX standard parts (see https://wiki.ubuntu.com/DashAsBinSh 
for background). 

This leads to errors such as this one:

{noformat}
$ sdbinfo
/home/oisuomin/sw/jena-sdb-3.1.0-SNAPSHOT/bin/make_classpath: 63: 
/home/oisuomin/sw/jena-sdb-3.1.0-SNAPSHOT/bin/make_classpath: Bad substitution
Error: Could not find or load main class sdb.sdbinfo
{noformat}

The simple fix is to change the interpreter to /bin/bash and I will do that 
very soon.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (JENA-1118) Bringing back the SDB assembly (zip/tarball distribution)

[Osma Suominen (JIRA)]

 [ 
https://issues.apache.org/jira/browse/JENA-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Osma Suominen updated JENA-1118:

Fix Version/s: Jena 3.1.0

> Bringing back the SDB assembly (zip/tarball distribution)
> -
>
> Key: JENA-1118
> URL: https://issues.apache.org/jira/browse/JENA-1118
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: SDB
>Affects Versions: Jena 3.0.1
>Reporter: Osma Suominen
>Assignee: Osma Suominen
>Priority: Minor
> Fix For: Jena 3.1.0
>
>
> I've been using the ancient jena-sdb-1.3.6 distribution but it's getting old. 
> I wanted to have something newer to deploy to my server but compiling SDB 
> using "mvn package" only builds the jar, not a full distribution with the 
> command line scripts etc.
> I noticed that the Maven assembly plugin configuration to do this was 
> commented out from jena-sdb/pom.xml in commit 807f8bf on 16 Feb 2014 and 
> later removed entirely. Maybe there was a good reason to do so, I don't know. 
> The assembly.xml file has since bitrotted slightly since it references files 
> that no longer exist.
> In any case I'd like to have it back in working condition and I will open a 
> PR shortly to do that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-1118) Bringing back the SDB assembly (zip/tarball distribution)

[Osma Suominen (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15105057#comment-15105057
 ] 

Osma Suominen commented on JENA-1118:
-

PR merged. Now I'll wait for the snapshot build and then e-mail the dev@ list, 
as Andy advised above.

> Bringing back the SDB assembly (zip/tarball distribution)
> -
>
> Key: JENA-1118
> URL: https://issues.apache.org/jira/browse/JENA-1118
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: SDB
>Affects Versions: Jena 3.0.1
>Reporter: Osma Suominen
>Assignee: Osma Suominen
>Priority: Minor
>
> I've been using the ancient jena-sdb-1.3.6 distribution but it's getting old. 
> I wanted to have something newer to deploy to my server but compiling SDB 
> using "mvn package" only builds the jar, not a full distribution with the 
> command line scripts etc.
> I noticed that the Maven assembly plugin configuration to do this was 
> commented out from jena-sdb/pom.xml in commit 807f8bf on 16 Feb 2014 and 
> later removed entirely. Maybe there was a good reason to do so, I don't know. 
> The assembly.xml file has since bitrotted slightly since it references files 
> that no longer exist.
> In any case I'd like to have it back in working condition and I will open a 
> PR shortly to do that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-1118) Bringing back the SDB assembly (zip/tarball distribution)

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15105054#comment-15105054
 ] 

ASF GitHub Bot commented on JENA-1118:
--

Github user asfgit closed the pull request at:

https://github.com/apache/jena/pull/122


> Bringing back the SDB assembly (zip/tarball distribution)
> -
>
> Key: JENA-1118
> URL: https://issues.apache.org/jira/browse/JENA-1118
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: SDB
>Affects Versions: Jena 3.0.1
>Reporter: Osma Suominen
>Assignee: Osma Suominen
>Priority: Minor
>
> I've been using the ancient jena-sdb-1.3.6 distribution but it's getting old. 
> I wanted to have something newer to deploy to my server but compiling SDB 
> using "mvn package" only builds the jar, not a full distribution with the 
> command line scripts etc.
> I noticed that the Maven assembly plugin configuration to do this was 
> commented out from jena-sdb/pom.xml in commit 807f8bf on 16 Feb 2014 and 
> later removed entirely. Maybe there was a good reason to do so, I don't know. 
> The assembly.xml file has since bitrotted slightly since it references files 
> that no longer exist.
> In any case I'd like to have it back in working condition and I will open a 
> PR shortly to do that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (JENA-1118) Bringing back the SDB assembly (zip/tarball distribution)

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/JENA-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15105053#comment-15105053
 ] 

ASF subversion and git services commented on JENA-1118:
---

Commit f0217efdbd440529cb5259017a8168a345866020 in jena's branch 
refs/heads/master from [~osma]
[ https://git-wip-us.apache.org/repos/asf?p=jena.git;h=f0217ef ]

JENA-1118: bringing back the SDB distribution


> Bringing back the SDB assembly (zip/tarball distribution)
> -
>
> Key: JENA-1118
> URL: https://issues.apache.org/jira/browse/JENA-1118
> Project: Apache Jena
>  Issue Type: Improvement
>  Components: SDB
>Affects Versions: Jena 3.0.1
>Reporter: Osma Suominen
>Assignee: Osma Suominen
>Priority: Minor
>
> I've been using the ancient jena-sdb-1.3.6 distribution but it's getting old. 
> I wanted to have something newer to deploy to my server but compiling SDB 
> using "mvn package" only builds the jar, not a full distribution with the 
> command line scripts etc.
> I noticed that the Maven assembly plugin configuration to do this was 
> commented out from jena-sdb/pom.xml in commit 807f8bf on 16 Feb 2014 and 
> later removed entirely. Maybe there was a good reason to do so, I don't know. 
> The assembly.xml file has since bitrotted slightly since it references files 
> that no longer exist.
> In any case I'd like to have it back in working condition and I will open a 
> PR shortly to do that.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] jena pull request: JENA-1118: bringing back the SDB distribution

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/jena/pull/122


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---