Members present: m1s, westei, tkurz, sschaffert, jfrank, Wikier ---------------- Meeting summary: ----------------
1. Preface 2. ldclient n. http://svn.apache.org/repos/asf/stanbol/trunk/enhancer/generic/test/src/main/java/org/apache/stanbol/enhancer/test/helper/RemoteServiceHelper.java (jfrank, 2) p. http://svn.apache.org/repos/asf/stanbol/trunk/enhancement-engines/celi/src/test/java/org/apache/stanbol/enhancer/engines/celi/CeliHttpTest.java (westei, 2) r. look at RemoteServiceHelper for tests requiring HTTP access (sschaffert, 2) ?. http://code.google.com/p/lmf/source/browse/ldclient/ldclient-provider-rdf/src/main/java/org/apache/marmotta/ldclient/endpoint/rdf/StanbolEndpoint.java (sschaffert, 2) 3. ldcache 4. RepositoryConnection handling ?. https://issues.apache.org/jira/browse/MARMOTTA-34 (sschaffert, 4) 5. any other business ?. https://code.google.com/p/lmf/issues/list (Wikier, 5) -------- Actions: -------- - look at RemoteServiceHelper for tests requiring HTTP access (sschaffert, 09:14:34) IRC log follows: # 1. Preface # 09:06:30 [Wikier]: topics? 09:06:37 [sschaffert]: my topics are the same as yesterday: ldclient and ldcache 09:06:44 [jfrank]: ldpath 09:06:52 [Wikier]: for me just minor bug fixes 09:07:07 [jfrank]: SailService 09:07:17 [sschaffert]: SailService? 09:07:23 [sschaffert]: or SesameService? 09:07:29 [jfrank]: true 09:07:37 [Wikier]: welcome tkurz 09:07:37 [tkurz]: hi 09:07:52 [jfrank]: autoCommit in RepositoryConnections 09:08:09 [sschaffert]: ok any other topics? Thomas? 09:08:30 [tkurz]: not from my side 09:09:09 [sschaffert]: ok, then let's start # 2. ldclient # 09:09:37 [sschaffert]: just a quick report: 09:09:52 [sschaffert]: the modularization of ldclient is for now finished 09:10:01 [sschaffert]: and there are tests for the most important providers 09:10:14 [sschaffert]: a bit of a problem is that these tests depend on availability of remote services 09:10:22 [sschaffert]: but anyways 09:10:37 [sschaffert]: basic usage: 09:10:45 [westei]: you should add a RemoteServiceHelper as we have in Stanbol 09:10:55 [sschaffert]: what does it do? 09:11:14 [westei]: it checks for HTTP error codes, timeouts, HostNotFoundExceptions ⦠and than deactivates tests 09:11:24 [westei]: rather than let them failing 09:11:25 [sschaffert]: sounds good 09:11:44 [sschaffert]: where can I get it? 09:12:29 [westei]: http://svn.apache.org/repos/asf/stanbol/trunk/enhancer/generic/test/src/main/java/org/apache/stanbol/enhancer/test/helper/RemoteServiceHelper.java 09:13:17 [jfrank]: #link http://svn.apache.org/repos/asf/stanbol/trunk/enhancer/generic/test/src/main/java/org/apache/stanbol/enhancer/test/helper/RemoteServiceHelper.java 09:13:42 [westei]: example usage 09:13:43 [westei]: #link http://svn.apache.org/repos/asf/stanbol/trunk/enhancement-engines/celi/src/test/java/org/apache/stanbol/enhancer/engines/celi/CeliHttpTest.java 09:14:12 [sschaffert]: great, will look at it 09:14:34 [sschaffert]: #action look at RemoteServiceHelper for tests requiring HTTP access 09:14:42 [sschaffert]: so basic usage: 09:14:57 [sschaffert]: new LDClient(configuration) or in the simple case only new LDClient() 09:15:04 [sschaffert]: and then 09:15:12 [sschaffert]: ClientResponse r = ldclient.retrieveResource(uri); 09:15:26 [sschaffert]: r contains some meta-data (e.g. expiry information) as well as the triples 09:15:51 [sschaffert]: uri can be any linked data URI or depending on available providers also YouTube, Vimeo, or MediaWiki resources 09:16:09 [sschaffert]: after use 09:16:10 [sschaffert]: ldclient.shutdown() 09:16:17 [sschaffert]: to clean up http connection pool 09:16:54 [sschaffert]: besides normal LD resources, you can also map resources to SPARQL endpoints or to entity caches like Stanbol Sites 09:17:19 [jfrank]: with the correct provider 09:17:24 [sschaffert]: and that's it for the report, documentation still to come when we have a website 09:17:47 [sschaffert]: yes, but I have simplified this a bit through pre-defined endpoints 09:18:24 [sschaffert]: eg 09:18:24 [sschaffert]: #link http://code.google.com/p/lmf/source/browse/ldclient/ldclient-provider-rdf/src/main/java/org/apache/marmotta/ldclient/endpoint/rdf/StanbolEndpoint.java 09:18:54 [sschaffert]: ok, my next topic is # 3. ldcache # 09:19:24 [sschaffert]: only message here: will start working on it today, and depending on my time I hope to finish this evening or on Monday 09:19:47 [sschaffert]: Monday then replacement of old lmf-ldcache with the new modularized approach 09:20:02 [sschaffert]: ok, so for me next topic :) # 4. RepositoryConnection handling # 09:22:09 [jfrank]: SesameService.getConnection produced a connection with autocommit set to false 09:22:48 [jfrank]: this implies a connection.begin thus everyone who is using the connection as it should be used is getting errors 09:23:09 [jfrank]: (some message like: do not call begin() twice!) 09:23:33 [sschaffert]: setAutoCommit is deprecated anyways in 2.7, so we remove it 09:23:40 [jfrank]: exactly. 09:23:57 [jfrank]: but this might break some usages of the connection 09:24:09 [sschaffert]: yes, maybe I can briefly explain the background 09:24:11 [jfrank]: but they need to be fixed anyway 09:24:19 [sschaffert]: if setAutoCommit is set to true 09:24:19 [jfrank]: go ahead 09:24:40 [sschaffert]: then Sesame tries a commit when the connection closes 09:24:54 [sschaffert]: in case you forgot doing it manually 09:25:09 [sschaffert]: but since you ALWAYS should commit explicitly anyways 09:25:26 [sschaffert]: this is not a good thing 09:25:39 [m1s]: hi to everybody - Mihai here - sorry for delay 09:25:54 [sschaffert]: the problem starts if you still have connections where you did not commit and close explicitly 09:26:09 [sschaffert]: because at least in the KiWi backend these connections are directly linked to database connections 09:26:26 [sschaffert]: and you will end up with unreleased resources and resource exhaustion 09:26:54 [sschaffert]: so please please check everywhere of you committed and closed your connections 09:27:19 [sschaffert]: I think this is the main message 09:27:32 [sschaffert]: anything more you wanted to discuss here, Jakob? 09:27:42 [jfrank]: yes 09:27:55 [jfrank]: for ldpath i'm creating a new backend 09:28:09 [jfrank]: working on a single RepositoryConnection 09:28:33 [jfrank]: (all operations in one transaction) 09:29:02 [jfrank]: will use this in lmf-search 09:29:09 [westei]: as ldpath is read only that makes totally sense 09:29:18 [sschaffert]: it also makes sense for performance reasons :) 09:29:32 [sschaffert]: but you might get into trouble with the recursion 09:29:39 [jfrank]: why that? 09:30:17 [sschaffert]: you have to move connection control completely outside ldpath 09:30:24 [jfrank]: exactly. 09:30:47 [sschaffert]: so feel free to do a new backend :) 09:31:09 [jfrank]: what happens in the backend is (1) getValueFactory() and (2) getStatements() 09:31:26 [jfrank]: nothing more 09:31:32 [sschaffert]: ok, so a quick think to getValueFactory() 09:31:47 [sschaffert]: there is a difference in the KiWi implementation compared to standard Sesame 09:32:02 [sschaffert]: you can use it the same way for compatibility 09:32:24 [sschaffert]: but with KiWi it is always better to use connection.getValueFactory() instead of repository.getValueFactory() 09:32:39 [jfrank]: that's what i did 09:32:48 [sschaffert]: the reason is that creating nodes and statements through the value factory will also require database access so opens a JDBC connection 09:33:10 [sschaffert]: if you request the value factory from the RepositoryConnection it will simply use the existing connection 09:33:26 [sschaffert]: otherwise it needs to open a separate JDBC connection, which is much less efficient 09:33:47 [sschaffert]: and also not covered by a rollback 09:34:10 [sschaffert]: (just as a short explanation to let you understand the KiWi store) 09:34:25 [sschaffert]: so +1 for creating a backend with only one connection 09:34:45 [jfrank]: re. rollback: should a read-only connection do commit() or rollback() in the end? 09:35:07 [jfrank]: or is it possible to have a ReadOnlyConnection? 09:37:14 [m1s]: stupid question, the ValueFactory is kind of read only because it only creates resources (e.g. nodes), is this right ? 09:38:16 [sschaffert]: "create" is by its definition a write operation :-P 09:38:29 [sschaffert]: every successful connection should do a commit at the end 09:39:07 [m1s]: right, you need to write the new resources to the persistence layer, right 09:39:08 [sschaffert]: and you should anyways do this because if we introduce the caching sail into the stack, it might fetch remote triples and store them in the triple store 09:39:21 [jfrank]: true 09:39:49 [sschaffert]: m1s: the reason why create is a write operation here is that once you create a resource that does not exist, I enter a new row and row id in the database 09:40:04 [sschaffert]: in case you rollback later, the JDBC connection is also rolled back and everything is gone 09:40:14 [sschaffert]: but still a write 09:40:34 [sschaffert]: so please always do a commit() 09:41:49 [Wikier]: something to document ;-) 09:42:20 [sschaffert]: something to keep in mind like the 10 commandments! :-) 09:42:27 [Wikier]: xDDD 09:42:49 [jfrank]: since we're speaking of ValueFactory: any comment on MARMOTTA-34? 09:42:49 [sschaffert]: in IntelliJ I will create a macro for this pattern 09:42:58 [sschaffert]: no, except that you are right 09:43:19 [sschaffert]: it is a legacy issue that a literal with language is typed in KiWi 09:43:34 [sschaffert]: and does not conform completely with the RDF spec 09:43:34 [jfrank]: ok - since i'm currently working in that module, i'll take care of it. 09:43:42 [sschaffert]: even if the RDF spec is stupid 09:43:57 [sschaffert]: but be careful, I did not change it because I feared there might be too many problems 09:44:34 [jfrank]: i'll just ignore type if there is a language 09:44:45 [sschaffert]: the place to change is the KiWiValueFactory probably 09:44:49 [sschaffert]: the rest should be agnostic 09:44:57 [sschaffert]: the persistence layer is 09:47:20 [m1s]: is MARMOTTA-34 an issue in a Issue manager ? 09:47:29 [sschaffert]: yes 09:47:49 [sschaffert]: #link https://issues.apache.org/jira/browse/MARMOTTA-34 09:47:57 [m1s]: ok,thx, I will consider it (look over it) 09:48:12 [sschaffert]: next topic? 09:49:12 [Wikier]: who? 09:50:04 [sschaffert]: maybe no more topics :) # 5. any other business # 09:50:28 [sschaffert]: quick note on branding and website 09:50:35 [sschaffert]: branding: reply from Daniela still open 09:50:49 [sschaffert]: website: still apparently waiting for INFRA, is there any progress? 09:50:57 [Wikier]: no progress 09:50:58 [Wikier]: :-S 09:51:12 [sschaffert]: can we ask someone for help? it is now two weeks almost 09:51:12 [Wikier]: and I don't want to insist too much, you know 09:51:21 [sschaffert]: yes of coursew 09:51:34 [Wikier]: ok, I'll try at #asfinfra 09:51:42 [sschaffert]: but maybe we can reach someone at IRC 09:51:42 [sschaffert]: yes 09:51:45 [sschaffert]: good 09:52:04 [Wikier]: let's see... 09:52:14 [Wikier]: anything else? 09:52:34 [Wikier]: one thing 09:52:49 [Wikier]: please, take a look to the issue tracker at google code 09:52:57 [Wikier]: we should close all ongoing tasks 09:53:05 [Wikier]: some of those issues will be kept there anyway 09:53:21 [Wikier]: but those not fixed for 2.6 we'd need to manually move to jira 09:54:12 [Wikier]: ok, that's it 09:54:20 [m1s]: if bug fixing support is needed I can give a hand (or a finger :) ) 09:54:36 [Wikier]: xD 09:54:42 [Wikier]: thx m1s 09:54:50 [m1s]: I can browse the issues I try pick up something 09:55:04 [m1s]: one more questions, linux question 09:55:19 [Wikier]: so, all, take a look not only to jira, but the issue tracker at google code too 09:55:27 [Wikier]: #link https://code.google.com/p/lmf/issues/list 09:55:34 [Wikier]: m1s: yes? 09:55:34 [m1s]: thx 09:56:15 [sschaffert]: so infra says website probably after 1st February 09:56:19 [m1s]: what GNOME client do you use I use Empathy and it kind of suck, I use now a command line 09:56:27 [sschaffert]: m1s: this is off topic for the meeting 09:56:34 [m1s]: ok 09:56:35 [sschaffert]: please wait until we have finished the official meeting 09:56:35 [m1s]: sorry 09:57:04 [sschaffert]: close the meeting? 09:57:06 [Wikier]: yes 09:57:11 [jfrank]: +1
