That was premature, I just reran the experiment and now it crashed again :(

Will try to see where that core dump went.

Regards,
Jerven

On 13/02/14 09:25, Jerven Bolleman wrote:
> Hi All,
>
> I have managed to build a debug build.
> The funny thing is it now succeeds!
> I do get this message once the next time I call a checkpoint.
>
> 18:02:22 suspect to miss a flush of L=100 in cpt, line 1008
> 18:02:23 Buffer 0x7fc9f79516f8 occupied in cpt
>
> Regards,
> Jerven
> On 11/02/14 16:06, Jerven Bolleman wrote:
>> Hi Hugh,
>>
>> I don't understand how to build the debug release.
>> I can't find the lines to patch e.g.
>>
>> cd /scratch/virtuoso-opensource
>> git pull;git status;
>> grep CONFIGURE_ARGS Makefile
>>
>>
>> remote: Counting objects: 298, done.
>> remote: Compressing objects: 100% (298/298), done.
>> remote: Total 298 (delta 174), reused 0 (delta 0)
>> Receiving objects: 100% (298/298), 1.44 MiB | 974 KiB/s, done.
>> Resolving deltas: 100% (174/174), done.
>>  From git://github.com/openlink/virtuoso-opensource
>>     74ed20c..0b71fb6  develop/7  -> origin/develop/7
>> Already up-to-date.
>> # On branch stable/7
>> nothing to commit (working directory clean)
>>
>> As you can notice I am now trying out the stable branch.
>> Because when I tried building the develop/7 branch yesterday I had a
>> failure.
>>
>> I do have a better idea of what is going on to trigger the bug.
>> First of all I have rewritten the update statement to look like this.
>>
>> PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#>
>> INSERT { GRAPH <http://beta.sparql.uniprot.org/taxonomy> {
>>    ?sub rdfs:subClassOf ?super}}
>> WHERE   {
>>      SELECT DISTINCT ?super ?sub
>>      WHERE {GRAPH <http://beta.sparql.uniprot.org/taxonomy> {
>>                        ?sub rdfs:subClassOf [] .
>>                        ?sub rdfs:subClassOf/rdfs:subClassOf+ ?super .
>>                        []   rdfs:subClassOf ?super . }
>>      }
>> }
>>
>> Which runs in about 25 minutes for the taxonomy data I have been using.
>> Once the TransactionAfterImageLimit is raised (in my case to about 1GB
>> or 1000000000 bytes)
>>
>> Then I try loading the go.rdf.gz data into a named which works fine and
>> run the nearly identical query.
>>
>> PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#>
>> INSERT { GRAPH <http://beta.sparql.uniprot.org/go> {
>>    ?sub rdfs:subClassOf ?super}}
>> WHERE   {
>>      SELECT DISTINCT ?super ?sub
>>      WHERE {GRAPH <http://beta.sparql.uniprot.org/go> {
>>                        ?sub rdfs:subClassOf [] .
>>                        ?sub rdfs:subClassOf/rdfs:subClassOf+ ?super .
>>                        []   rdfs:subClassOf ?super . }
>>      }
>> }
>>
>> At this time the database starts to die again :(
>>
>> ?sub rdfs:subClassOf [] .
>> and
>> []   rdfs:subClassOf ?super
>> are there to ground ?sub and ?super or I get an error from the query
>> engine but without those the query is valid SPARQL as well.
>> I think this is fixed in the develop branch.
>>
>> As you might have noticed from yesterday's message about the clob/blob
>> api for Virtuoso JDBC I was investigating better ways of loading the
>> data again.
>>
>> Currently I build a Turtle string that is passed to the virtuoso side
>> where it is loaded via TTLP or TTLP_MT. However, it is sad that I go
>> from structured data to a string to be parsed again on the other side.
>> I was hoping that there would be a better way to generate a data
>> structure that does not require as much parsing by virtuoso.
>> On large datasets this might not be a noticable overhead but on the
>> small datasets that I am now testing I notice that we are running out of
>> CPU power before IO/MEM.
>>
>> I was wondering if an API where we can pass 4 (or 5) array's to a
>> prepared statement instead of a string to parse can really improve the
>> loading speed.
>>
>> e.g.
>> one array of subjects
>> one array of predicates
>> one array of objects
>> optional one of datatypes
>> one array of graphs
>>
>> If this does not match your needs then another feature requests is
>> better blob/clob support in virtuoso.
>> Currently I can figure out how to create them but not how to actually
>> put data into them without being in a virtuoso package.
>>
>> Regards,
>> Jerven
>>
>>
>> On 28/01/14 06:03, Hugh Williams wrote:
>>> Hi Jerven,
>>>
>>> I have run the query many times, but as said I keep getting the "SR325:
>>> Transaction aborted because it's log after image size went above the
>>> limit" first time the query is run and have to increase
>>> the "TransactionAfterImageLimit" param in the INI file. Thus have you
>>> encountered this error yourself or do you even have
>>> the "TransactionAfterImageLimit" param set for your instance as I am
>>> wondering if this might be the cause of the crash you are seeing on your
>>> instance and perhaps the param needs to be increased for your instance ?
>>>
>>> Best Regards
>>> Hugh Williams
>>> Professional Services
>>> OpenLink Software, Inc.      // http://www.openlinksw.com/
>>> Weblog   -- http://www.openlinksw.com/blogs/
>>> LinkedIn -- http://www.linkedin.com/company/openlink-software/
>>> Twitter  -- http://twitter.com/OpenLink
>>> Google+  -- http://plus.google.com/100570109519069333827/
>>> Facebook -- http://www.facebook.com/OpenLinkSoftware
>>> Universal Data Access, Integration, and Management Technology Providers
>>>
>>> On 27 Jan 2014, at 13:52, Jerven Bolleman <jerven.bolle...@isb-sib.ch
>>> <mailto:jerven.bolle...@isb-sib.ch>> wrote:
>>>
>>>> Hi Hugh,
>>>>
>>>> Sorry I won’t have time to get a memory dump for at least two weeks.
>>>> However, I must have explained something badly you need to run the
>>>> insert query 4 or 5 times in a row to get the crash.
>>>>
>>>> Regards,
>>>> Jerven
>>>> On 26 Jan 2014, at 15:51, Hugh Williams <hwilli...@openlinksw.com
>>>> <mailto:hwilli...@openlinksw.com>> wrote:
>>>>
>>>>> Hi Jerven,
>>>>>
>>>>> I  have tried recreating this against the VOS develop/7 branch on Mac
>>>>> OS X but have been unable to do so ...
>>>>>
>>>>> Hughs-MacBook-Pro-478:database hwilliams$ /Applications/Virtuoso\
>>>>> 7.1.app/Contents/virtuoso/bin/isql 1111
>>>>> Connected to OpenLink Virtuoso
>>>>> Driver: 07.10.3207 OpenLink Virtuoso ODBC Driver
>>>>> OpenLink Interactive SQL (Virtuoso), version 0.9849b.
>>>>> Type HELP; for help and EXIT; to exit.
>>>>> SQL> status('');
>>>>> REPORT
>>>>> VARCHAR
>>>>> _______________________________________________________________________________
>>>>>
>>>>>
>>>>>
>>>>> OpenLink Virtuoso  Server
>>>>> Version 07.00.3207-pthreads for Darwin as of Dec 10 2013
>>>>> Started on: 2014-01-26 14:16 GMT+0
>>>>>
>>>>> Database Status:
>>>>> File size 614465536, 75008 pages, 51817 free.
>>>>> 170000 buffers, 21735 used, 0 dirty 0 wired down, repl age 0 0 w. io
>>>>> 0 w/crsr.
>>>>> Disk Usage: 524 reads avg 1 msec, 0% r 0% w last  0 s, 21387 writes,
>>>>>   13 read ahead, batch = 14.  Autocompact 40700 in 18150 out, 55%
>>>>> saved col ac: 4997 in 47% saved.
>>>>> Gate:  44 2nd in reads, 0 gate write waits, 0 in while read 0 busy
>>>>> scrap.
>>>>> Log = /usr/local/vos7/database/virtuoso.trx, 185 bytes
>>>>> 23061 pages have been changed since last backup (in checkpoint state)
>>>>> Current backup timestamp: 0x0000-0x00-0x00
>>>>> Last backup date: unknown
>>>>> Clients: 1 connects, max 1 concurrent
>>>>> RPC: 4 calls, 1 pending, 1 max until now, 0 queued, 0 burst reads
>>>>> (0%), 0 second 0M large, 83M max
>>>>> Checkpoint Remap 95 pages, 0 mapped back. 0 s atomic time.
>>>>>   DB master 75008 total 51817 free 95 remap 0 mapped back
>>>>>  temp  1024 total 1019 free
>>>>>
>>>>> Lock Status: 0 deadlocks of which 0 2r1w, 0 waits,
>>>>>  Currently 1 threads running 0 threads waiting 0 threads in vdb.
>>>>> Pending:
>>>>>
>>>>> 23 Rows. -- 8 msec.
>>>>> SQL> DB.DBA.RDF_LOAD_RDFXML_MT (file_to_string_output
>>>>> ('./taxonomy.rdf'), '', 'http://beta.sparql.uniprot.org/taxonomy/');
>>>>>
>>>>> Done. -- 118988 msec.
>>>>>
>>>>> SQL> SPARQL PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#>
>>>>> INSERT { GRAPH <http://beta.sparql.uniprot.org/taxonomy/> { ?sub
>>>>> rdfs:subClassOf ?super}} WHERE  { GRAPH
>>>>> <http://beta.sparql.uniprot.org/taxonomy/> { ?sub
>>>>> rdfs:subClassOf/rdfs:subClassOf ?super . MINUS { ?sub rdfs:subClassOf
>>>>> ?super .}}};
>>>>>
>>>>> *** Error 40005: VD [Virtuoso Server]SR325: Transaction aborted
>>>>> because it's log after image size went above the limit
>>>>> at line 4 of Top-Level:
>>>>> SPARQL PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#> INSERT {
>>>>> GRAPH <http://beta.sparql.uniprot.org/taxonomy/> { ?sub
>>>>> rdfs:subClassOf ?super}} WHERE  { GRAPH
>>>>> <http://beta.sparql.uniprot.org/taxonomy/> { ?sub
>>>>> rdfs:subClassOf/rdfs:subClassOf ?super . MINUS { ?sub rdfs:subClassOf
>>>>> ?super .}}}
>>>>> SQL>
>>>>>
>>>>> I got around the SR325 erro by doubling the
>>>>> "TransactionAfterImageLimit" param in the INI file from the default
>>>>> of 50000000 to 100000000 and restarted Virtuoso as indicated in the
>>>>> documentation at:
>>>>>
>>>>> http://docs.openlinksw.com/virtuoso/databaseadmsrv.html#dbadm
>>>>>
>>>>> Then the insertion was successful:
>>>>>
>>>>> Hughs-MacBook-Pro-478:database hwilliams$ /Applications/Virtuoso\
>>>>> 7.1.app/Contents/virtuoso/bin/isql 1111
>>>>> Connected to OpenLink Virtuoso
>>>>> Driver: 07.10.3207 OpenLink Virtuoso ODBC Driver
>>>>> OpenLink Interactive SQL (Virtuoso), version 0.9849b.
>>>>> Type HELP; for help and EXIT; to exit.
>>>>> SQL> SPARQL PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#>
>>>>> INSERT { GRAPH <http://beta.sparql.uniprot.org/taxonomy/> { ?sub
>>>>> rdfs:subClassOf ?super}} WHERE  { GRAPH
>>>>> <http://beta.sparql.uniprot.org/taxonomy/> { ?sub
>>>>> rdfs:subClassOf/rdfs:subClassOf ?super . MINUS { ?sub rdfs:subClassOf
>>>>> ?super .}}};
>>>>>
>>>>> Done. -- 41081 msec.
>>>>> SQL> sparql select count(*) from
>>>>> <http://beta.sparql.uniprot.org/taxonomy/> where {?s ?p ?o};
>>>>> callret-0
>>>>> INTEGER
>>>>> _______________________________________________________________________________
>>>>>
>>>>>
>>>>>
>>>>> 9549986
>>>>>
>>>>> 1 Rows. -- 150 msec.
>>>>> SQL>
>>>>>
>>>>> In your case Is a core file being created when the server crashes (
>>>>> note core size for user account should be set to be unlimited with
>>>>> command “ulimit -c unlimited” first), as if so you can create a debug
>>>>> unstripped Virtuoso binary, recreate the core with it and use gdb to
>>>>> debug it as follows:
>>>>>
>>>>> 1. Edit ~//Makefile
>>>>>
>>>>> 2. To CONFIGURE_ARGS add --with-debug
>>>>>
>>>>> 3. To CONFIGURE_ENV prepend CC='cc -g’
>>>>>
>>>>> 4. Then do "make clean all deinstall reinstall” to build a new debug
>>>>>  unstripped binary (virtuoso-t)
>>>>>
>>>>> 5. Start database with this new binary and force the crash condition
>>>>> again to generate a new core file
>>>>>
>>>>> 6. Use gdb to load core file
>>>>>
>>>>> gdb virtuoso-t  core
>>>>>
>>>>> 7. At  the prompt, type "bt" or “backtrace” to backtrace through
>>>>> stack and provide the output when top of stack is reached.
>>>>>
>>>>> Best Regards
>>>>> Hugh Williams
>>>>> Professional Services
>>>>> OpenLink Software, Inc.      //
>>>>> http://www.openlinksw.com/
>>>>> Weblog   -- http://www.openlinksw.com/blogs/
>>>>> LinkedIn -- http://www.linkedin.com/company/openlink-software/
>>>>> Twitter  -- http://twitter.com/OpenLink
>>>>> Google+  -- http://plus.google.com/100570109519069333827/
>>>>> Facebook -- http://www.facebook.com/OpenLinkSoftware
>>>>> Universal Data Access, Integration, and Management Technology
>>>>> Providers
>>>>>
>>>>> On 22 Jan 2014, at 11:08, Jerven Bolleman
>>>>> <jerven.bolle...@isb-sib.ch> wrote:
>>>>>
>>>>>> Dear Virtuoso devs,
>>>>>>
>>>>>> On commit 2701d3f242a630562302471d168d20fec5ed2805 of the develop/7
>>>>>> branch.
>>>>>>
>>>>>> I load the file
>>>>>> ftp://ftp.uniprot.org/pub/databases/uniprot/current_release/rdf/taxonomy.rdf.gz
>>>>>>
>>>>>>
>>>>>> into the graph named
>>>>>> http://beta.sparql.uniprot.org/taxonomy/.
>>>>>>
>>>>>> Then checkpoint. Then I the run the SPARUL query
>>>>>>
>>>>>> PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#>
>>>>>> INSERT { GRAPH <http://beta.sparql.uniprot.org/taxonomy/> {
>>>>>>                                  ?sub rdfs:subClassOf ?super}}
>>>>>> WHERE  { GRAPH <http://beta.sparql.uniprot.org/taxonomy/> {
>>>>>>                                  ?sub
>>>>>> rdfs:subClassOf/rdfs:subClassOf ?super .
>>>>>>                          MINUS { ?sub rdfs:subClassOf ?super .}}}
>>>>>>
>>>>>> I get a message
>>>>>> 17:27:41 * Monitor: Low query memory limit, try to increase
>>>>>> MaxQueryMem
>>>>>> Then I again run the same query
>>>>>> PREFIX rdfs:<http://www.w3.org/2000/01/rdf-schema#>
>>>>>> INSERT { GRAPH <http://beta.sparql.uniprot.org/taxonomy/> {
>>>>>>                                  ?sub rdfs:subClassOf ?super}}
>>>>>> WHERE  { GRAPH <http://beta.sparql.uniprot.org/taxonomy/> {
>>>>>>                                  ?sub
>>>>>> rdfs:subClassOf/rdfs:subClassOf ?super .
>>>>>>                          MINUS { ?sub rdfs:subClassOf ?super .}}}
>>>>>>
>>>>>> And virtuoso crashes without leaving a trace in the logs.
>>>>>>
>>>>>> The query log shows the first execution but not the second.
>>>>>> And that looks like this
>>>>>>
>>>>>> Precode:
>>>>>>    0: { FOR UPDATE
>>>>>> time      -nan% fanout         1 input         1 rows
>>>>>> time      -nan% fanout         1 input         1 rows
>>>>>>
>>>>>> Precode:
>>>>>>    0: vector := Call vector ( 1 ,  0 ,  3 ,  ##subClassOf ,  1 ,  1 )
>>>>>>    5: vector := Call vector (vector)
>>>>>>    10: vector := Call vector ()
>>>>>>    15: __bft := Call __bft (<c
>>>>>> http://beta.sparql.uniprot.org/taxonomy/>,  1 )
>>>>>>    20: BReturn 0
>>>>>> { fork
>>>>>> time      -nan% fanout 1.09875e+06 input         1 rows
>>>>>> RDF_QUAD_POGS   2.4e+03 rows(s_6_4_t1.O, s_6_4_t1.S)
>>>>>> inlined  P =  ##subClassOf  G =  #/
>>>>>> time      -nan% fanout  0.999965 input 1.09875e+06 rows
>>>>>> RDF_QUAD         1 rows(s_6_7_t2.O)
>>>>>> inlined  P =  ##subClassOf  ,  S = k_s_6_4_t1.O G =  #/
>>>>>> time      -nan% fanout         0 input 1.09871e+06 rows
>>>>>> END Node
>>>>>> After test:
>>>>>>    0: if ({
>>>>>> time      -nan% fanout         1 input 1.09871e+06 rows
>>>>>> time      -nan% fanout         0 input 1.09871e+06 rows
>>>>>> RDF_QUAD_POGS unq    0.0011 rows ()
>>>>>> P =  ##subClassOf  ,  O = k_s_6_7_t2.O ,  S = k_s_6_4_t1.S ,  G =  #/
>>>>>> time      -nan% fanout         0 input         0 rows
>>>>>> Subquery Select( <none> )
>>>>>> }
>>>>>> ) then 5 else 4 unkn 5
>>>>>>    4: BReturn 1
>>>>>>    5: BReturn 0
>>>>>>
>>>>>> After code:
>>>>>>    0: __ro2lo := Call __ro2lo (s_6_7_t2.O)
>>>>>>    5: vector := Call vector (s_6_4_t1.S, __ro2lo)
>>>>>>    10: if ($63 "user_aggr_notfirst" =  1 ) then 25 else 14 unkn 14
>>>>>>    14: $63 "user_aggr_notfirst" :=  := artm  1
>>>>>>    18: user_aggr_ret := Call DB.DBA.SPARQL_CONSTRUCT_INIT ($64
>>>>>> "user_aggr_env")
>>>>>>    25: user_aggr_ret := Call DB.DBA.SPARQL_CONSTRUCT_ACC ($64
>>>>>> "user_aggr_env", vector, vector, vector,  0 )
>>>>>>    32: BReturn 0
>>>>>> }
>>>>>> time      -nan% fanout         1 input         1 rows
>>>>>> skip node  1  <none> set_ctr
>>>>>>
>>>>>> After code:
>>>>>>    0: DB.DBA.SPARQL_CONSTRUCT_FIN := Call
>>>>>> DB.DBA.SPARQL_CONSTRUCT_FIN ($64 "user_aggr_env")
>>>>>>    7: callret-0 := Call DB.DBA.SPARQL_INSERT_DICT_CONTENT (__bft,
>>>>>> DB.DBA.SPARQL_CONSTRUCT_FIN,  0 , <DB_NULL>,  0 )
>>>>>>    14: BReturn 0
>>>>>> time      -nan% fanout         0 input         1 rows
>>>>>> skip node  1  <none> set_ctr
>>>>>>
>>>>>> After code:
>>>>>>    0: DB.DBA.SPARQL_CONSTRUCT_FIN := Call
>>>>>> DB.DBA.SPARQL_CONSTRUCT_FIN ($64 "user_aggr_env")
>>>>>>    7: callret-0 := Call DB.DBA.SPARQL_INSERT_DICT_CONTENT (__bft,
>>>>>> DB.DBA.SPARQL_CONSTRUCT_FIN,  0 , <DB_NULL>,  0 )
>>>>>>    14: BReturn 0
>>>>>> time      -nan% fanout         0 input         1 rows
>>>>>> Subquery Select(callret-0)
>>>>>> }
>>>>>>
>>>>>>    8: $184 "vector" := Call vector ($185 "scalar")
>>>>>>    13: $183 "DB.DBA.SPARUL_RUN" := Call DB.DBA.SPARUL_RUN ($184
>>>>>> "vector")
>>>>>>    20:  <none>  := Call set_row_count ($183 "DB.DBA.SPARUL_RUN")
>>>>>>    25: BReturn 0
>>>>>> END Node
>>>>>> }
>>>>>> ^@^B<80>^@<BD>^@^P<C3><D7><C1><BC>+<BD>^@^@8Z<D3>^K8^X^PqP^@ESC
>>>>>> <<BC>^@<BC>^@<B5>
>>>>>>       127.0.0.1<B5>^Cdba<CC>^S<BD>^@#k<A2><BD>^@^@G <B5>^Nlog_enable
>>>>>> (3)^A<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@
>>>>>> <BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<B6>^@^@^@W{
>>>>>>
>>>>>>
>>>>>>
>>>>>> Precode:
>>>>>>    0:  <none>  := Call log_enable ( 3 )
>>>>>>    5: BReturn 0
>>>>>> END Node
>>>>>> }
>>>>>> ^@^A@^@<BC>^@<C1><BC>+<BD>^@^@8[<D3>^K8^X^PqP^@^\ <<BC>^@<BC>^@<B5>
>>>>>> 127.0.0.1<B5>^Cdba<CC>^S<BD>^@#k<A3><BD>^@^@G
>>>>>> <B5>^Xcheckpoint_interval
>>>>>> (60)^A<BC>^@<BC>^A<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@
>>>>>> <BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<B6>^@^@^@a{
>>>>>>
>>>>>>
>>>>>>
>>>>>> Precode:
>>>>>>    0:  <none>  := Call checkpoint_interval ( 60 )
>>>>>>    5: BReturn 0
>>>>>> END Node
>>>>>> }
>>>>>> ^@^A@^@<BC>^@<C1><BC>+<BD>^@^@8\<D3>^K8^X^PqP^@^^ <<BC>^@<BC>^@<B5>
>>>>>> 127.0.0.1<B5>^Cdba<CC>^S<BD>^@#k<B6><BD>^@^@G
>>>>>> <B5>^Wcheckpoint_interval
>>>>>> (0)^A<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@
>>>>>> <BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<B6>^@^@^@`{
>>>>>>
>>>>>>
>>>>>>
>>>>>> Precode:
>>>>>>    0:  <none>  := Call checkpoint_interval ( 0 )
>>>>>>    5: BReturn 0
>>>>>> END Node
>>>>>> }
>>>>>> ^@^A@^@<BC>^@<C1><BC>+<BD>^@^@8]<D3>^K8^X^PqP^@^_ <<BC>^@<BC>^@<B5>
>>>>>> 127.0.0.1<B5>^Cdba<CC>^S<BD>^@#k<B6><BD>^@^@G   <B5>^Nlog_enable
>>>>>> (0)^A<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>
>>>>>> ^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<BC>^@<B6>^@^@^@W{
>>>>>>
>>>>>>
>>>>>>
>>>>>> Precode:
>>>>>>    0:  <none>  := Call log_enable ( 0 )
>>>>>>    5: BReturn 0
>>>>>> END Node
>>>>>> }
>>>>>> I would expect the next query to show up here but it did not. The
>>>>>> change to the checkpoint interval and logging status show that the
>>>>>> two statements before the SPARUL succeeded.
>>>>>>
>>>>>> The exception caught from the java side is
>>>>>> Exception:virtuoso.jdbc4.VirtuosoException: Virtuoso Communications
>>>>>> Link Failure (timeout) : Connection to the server lost
>>>>>> at
>>>>>> virtuoso.sesame2.driver.VirtuosoRepositoryConnection.executeSPARUL(Unknown
>>>>>>
>>>>>>
>>>>>> Source)
>>>>>> at
>>>>>> virtuoso.sesame2.driver.VirtuosoRepositoryConnection$4.execute(Unknown
>>>>>>
>>>>>> Source)
>>>>>>
>>>>>> Is there a way I can change the error log level to be more
>>>>>> verbose/helpfull?
>>>>>>
>>>>>> Regards,
>>>>>> Jerven
>>>>>>
>>>>>> --
>>>>>> -------------------------------------------------------------------
>>>>>> Jerven Bolleman                        jerven.bolle...@isb-sib.ch
>>>>>> SIB Swiss Institute of Bioinformatics  Tel: +41 (0)22 379 58 85
>>>>>> CMU, rue Michel Servet 1               Fax: +41 (0)22 379 58 58
>>>>>> 1211 Geneve 4,
>>>>>> Switzerland     www.isb-sib.ch - www.uniprot.org
>>>>>> Follow us at https://twitter.com/#!/uniprot
>>>>>> -------------------------------------------------------------------
>>>>>> <virtuoso-config-expasy4j-sparql702803043962519654.ini><virtuoso.log>------------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>>>>>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>>>>>> Critical Workloads, Development Environments & Everything In Between.
>>>>>> Get a Quote or Start a Free Trial Today.
>>>>>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk_______________________________________________
>>>>>>
>>>>>>
>>>>>> Virtuoso-users mailing list
>>>>>> Virtuoso-users@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/virtuoso-users
>>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> Jerven Bolleman jerven.bolle...@isb-sib.ch
>>>> <mailto:jerven.bolle...@isb-sib.ch>
>>>> SIB Swiss Institute of Bioinformatics      Tel: +41 (0)22 379 58 85
>>>> CMU, rue Michel Servet 1               Fax: +41 (0)22 379 58 58
>>>> 1211 Geneve 4,
>>>> Switzerland www.isb-sib.ch <http://www.isb-sib.ch> - www.uniprot.org
>>>> <http://www.uniprot.org>
>>>> Follow us at https://twitter.com/#!/uniprot
>>>> -------------------------------------------------------------------
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>>
>>>>
>>>> CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>>>> Learn Why More Businesses Are Choosing CenturyLink Cloud For
>>>> Critical Workloads, Development Environments & Everything In Between.
>>>> Get a Quote or Start a Free Trial Today.
>>>> http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
>>>>
>>>>
>>>> _______________________________________________
>>>> Virtuoso-users mailing list
>>>> Virtuoso-users@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/virtuoso-users
>>>
>>
>

-- 
-------------------------------------------------------------------
  Jerven Bolleman                        jerven.bolle...@isb-sib.ch
  SIB Swiss Institute of Bioinformatics  Tel: +41 (0)22 379 58 85
  CMU, rue Michel Servet 1               Fax: +41 (0)22 379 58 58
  1211 Geneve 4,
  Switzerland     www.isb-sib.ch - www.uniprot.org
  Follow us at https://twitter.com/#!/uniprot
-------------------------------------------------------------------

------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users

Reply via email to