Hi Hugh,
Running it as a preparedStatement does change the outcome
I see these again
14:12:30 * Monitor: Low query memory limit, try to increase MaxQueryMem
again,
While running I had a look at status();
And it gives a very long list of
16384: IER 8
80: ISR NO OWNER
76: ISR NO OWNER
72: ISR NO OWNER
68: ISR NO OWNER
64: ISR NO OWNER
60: ISR NO OWNER
56: ISR NO OWNER
52: ISR NO OWNER
48: ISR NO OWNER
44: ISR NO OWNER
40: ISR NO OWNER
36: ISR NO OWNER
32: ISR NO OWNER
28: ISR NO OWNER
24: ISR NO OWNER
20: ISR NO OWNER
etc.. etc..
Yet in the end using a prepared statement or not does not make a difference.
Also using isql.
SQL> sparql 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 .
}
}
}Type the rest of statement, end with a semicolon (;)> Type the rest of
statement, end with a semicolon (;)> Type the rest of statement, end
with a semicolon (;)> Type the rest of statement, end with a semicolon
(;)> Type the rest of statement, end with a semicolon (;)> Type the rest
of statement, end with a semicolon (;)> Type the rest of statement, end
with a semicolon (;)> Type the rest of statement, end with a semicolon
(;)> Type the rest of statement, end with a semicolon (;)> Type the rest
of statement, end with a semicolon (;)> ;
*** Error 08S01: [Virtuoso Driver]CL065: Lost connection to server
in lines 2-12 of Top-Level:
#line 2 "(console)"
sparql 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 .
}
}
}
Regards,
Jerven
On 17/02/14 14:04, Jerven Bolleman wrote:
> Hi Hugh,
>
> It is run via sesame. I will try running it directly as a prepared
> statement via JDBC and see if that makes a difference.
>
> Regards,
> Jerven
>
> On 17/02/14 14:02, Hugh Williams wrote:
>> Hi Jerven,
>>
>> Not a waste of time as you still have an apparent issue ...
>>
>> Going back to the original issue I am downloading the go.rdf.gz dataset
>> to load and run the test SPARQL insert query you provided against the
>> Virtuoso instance. Can you confirm if this query is executed via Sesame
>> or can it be run via isql to see the same problem ?
>>
>> 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 17 Feb 2014, at 08:53, Jerven Bolleman <jerven.bolle...@isb-sib.ch
>> <mailto:jerven.bolle...@isb-sib.ch>> wrote:
>>
>>> Hi Hugh,
>>>
>>> Sorry for wasting your time. I finally got the cause down.
>>>
>>> When I saw this for the first time in the gdb
>>>
>>> Program terminated with signal SIGKILL, Killed.
>>> The program no longer exists.
>>>
>>> And this in dmesg
>>>
>>> Out of memory: Kill process 14738 (virtuoso-t) score 763 or sacrifice
>>> child
>>> Killed process 14738, UID 21059, (virtuoso-t) total-vm:16179784kB,
>>> anon-rss:12910420kB, file-rss:152kB
>>>
>>>
>>>
>>>
>>> The total-vm size in that dmesg line is surprising its is nearly 16gb
>>> of memory use.
>>>
>>> Yet the NumberOfBuffers is 904897 (about 8 gb assuming 9KB pages) and
>>> MaxDirtyBuffers 500000. The odd size of the NumberOfBuffers is due to
>>> auto sizing this setting in the conf from the managing process as
>>> virtuoso is basically running in a embedded/lite mode.
>>>
>>> The server is in O_DIRECT mode (set to 1)
>>>
>>> What can I set so that this does not happen? i.e. why is the memory
>>> consumption so large during this SPARQL update? Is it because my max
>>> result size?
>>>
>>> Regards,
>>> Jerven
>>>
>>> On 13/02/14 20:57, Jerven Bolleman wrote:
>>>> Hi Hugh,
>>>>
>>>> Yes, that should be the file (all those are the same)
>>>> I switched back to the stable branch because the develop/7 branch
>>>> would not build cleanly when I tried.
>>>> This happened before and you guys normally fix it and I was not in a
>>>> hurry.
>>>> I finally have the debug build working and ulimit set etc… so I think
>>>> I will send the backtrace tomorrow.
>>>>
>>>> Regards,
>>>> Jerven
>>>>
>>>> On 13 Feb 2014, at 17:52, Hugh Williams <hwilli...@openlinksw.com
>>>> <mailto:hwilli...@openlinksw.com>> wrote:
>>>>
>>>>> Hi Jerven,
>>>>>
>>>>> From our point of view there is no real value in building from the
>>>>> stable/7 branch from July last year, as it is about to be superseded
>>>>> in the new VOS 7 release by develop/7 when finalised, which is what
>>>>> we would be more interested in knowing of any problem being
>>>>> encountered using ?
>>>>>
>>>>> In your email below you mention loading the go.rdf.gz uniprot
>>>>> dataset, do you have URL to what you loaded or is it one of:
>>>>>
>>>>> <resources>
>>>>> <url type="ftp" location="ch" preference="100">
>>>>> ftp://ftp.expasy.org/databases/uniprot/current_release/rdf/go.rdf.gz
>>>>> </url>
>>>>> <url type="ftp" location="uk" preference="100">
>>>>> ftp://ftp.ebi.ac.uk/pub/databases/uniprot/current_release/rdf/go.rdf.gz
>>>>>
>>>>> </url>
>>>>> <url type="ftp" location="us" preference="100">
>>>>> ftp://ftp.uniprot.org/pub/databases/uniprot/current_release/rdf/go.rdf.gz
>>>>>
>>>>> </url>
>>>>> </resources>
>>>>>
>>>>> and I can load here to try recreate your problem with develop/7 ?
>>>>>
>>>>> 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 13 Feb 2014, at 10:14, Jerven Bolleman
>>>>> <jerven.bolle...@isb-sib.ch> wrote:
>>>>>
>>>>>> 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
>>>>>
>>>>
>>>> -------------------------------------------------------------------
>>>> 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
>>>> -------------------------------------------------------------------
>>>>
>>>
>>> --
>>> -------------------------------------------------------------------
>>> 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
>>> -------------------------------------------------------------------
>>> <virtuoso-config-expasy4j-sparql5626626525761327524.ini>------------------------------------------------------------------------------
>>>
>>> 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
>>
>
--
-------------------------------------------------------------------
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
