Neda,
What is the call stack from the exception? it would be nice to know what
it says as that would point to the location of the error.
I suspect that you are not including all the necessary Jena libraries, but
can not be certain.
Claude
On Thu, Nov 23, 2017 at 1:25 AM, Neda Alipanah
wrote:
Hello there,
I have a quick question. I am loading a 25 Meg Owl file to the memory using
the following commands. My code is working fine through the IDE(IntelliJ),
but when I create a runnable Jar, it does not find the file. I already put
the owl file directory in the class path but I get Exception
Hello there,
I have a quick question. I am loading a 25 Meg Owl file to the memory using
the following commands. My code is working fine through the IDE(IntelliJ),
but when I create a runnable Jar, it does not find the file. I already put
the owl file directory in the class path but I get Exception
Hi Mikael!
Sorry, I probably misunderstood - I somehow read "similar" as meaning
"fuzzy" but they are of course not the same thing. So if you mean "give
me documents similar to document X", that's called MoreLikeThis in
Lucene, and it's currently not supported by jena-text. What's your use
ca
Hi Mikael!
Fuzzy search is a basic Lucene feature, just like prefix searches. You
should be able to use it directly via jena-text using a query like
?s text:query "word~"
or
?s text:query "word~1"
There is AFAICT nothing to implement on the jena-text side as this
already works right now.
-O
The behavior Andy describes is guided by the rule that generally, applications
hosted in JEE containers are supposed to let the container manage threading. (I
think that's written down somewhere in the JEE specs, but I can't remember
where, and if it was, it is often "honored in the breach"!). M
On 22/11/17 13:37, Marco Neumann wrote:
On Wed, Nov 22, 2017 at 2:15 PM, Andy Seaborne wrote:
On 22/11/17 10:55, Marco Neumann wrote:
i have noticed that a single fuseki instance spans quite a number of
worker process (~32-35) on one of our root servers ( x86_64 GNU/Linux)
with 8 cores an
Are there any plans on implementing similar text search for Jena?
Until similarity is implemented, is it possible to query similar texts
using Lucene directly, bypassing Jena, but with the same data set?
Br,
--
Lingsoft - 30 years of Leading Language Management
www.lingsoft.fi
Speech Appli
On Wed, Nov 22, 2017 at 2:15 PM, Andy Seaborne wrote:
>
>
> On 22/11/17 10:55, Marco Neumann wrote:
>>
>> i have noticed that a single fuseki instance spans quite a number of
>> worker process (~32-35) on one of our root servers ( x86_64 GNU/Linux)
>> with 8 cores and 128gb ram + ssd.
>>
>> does j
On 22/11/17 10:55, Marco Neumann wrote:
i have noticed that a single fuseki instance spans quite a number of
worker process (~32-35) on one of our root servers ( x86_64 GNU/Linux)
with 8 cores and 128gb ram + ssd.
does jena fuseki /tdb take full advantage of the extras cores on full
load with
On 22/11/17 12:35, Laura Morales wrote:
Fuseki uses TDB which relies on memory mapped files
Do you know if the same "memory mapped files" applies to other backends too,
for example HDT?
You'll have to check each of the backends - it's an implementation issue.
Andy
On 22/11/17 00:40, John Sanders wrote:
Hi, I'm running a Fuseki server on a rather small server. I'm willing to
upgrade it a little bit (since it's handling a lot of requests) so I was
wondering which single component I could upgrade to get the best possible
return. This I suppose boils d
> Fuseki uses TDB which relies on memory mapped files
Do you know if the same "memory mapped files" applies to other backends too,
for example HDT?
OK, I think I can answer my own question here. in the java doc of
version 1 it is explicitly mentioned that :
"This API is derived from the SiRPAC API, most recently maintained by
Sergey Melnik. It borrows from the subject centric approach of David
Megginson's DATAX API and the cascading calls sty
great Andy, thank you. this will come in handy for us and future
generations to trace the evolution of the Jena effort.
btw was SiRPAC a direct precursor to the work at HP in Bristol or was
the use of a java servlet containers generally in the air at the time
and an obvious choice for a RDF proces
i have noticed that a single fuseki instance spans quite a number of
worker process (~32-35) on one of our root servers ( x86_64 GNU/Linux)
with 8 cores and 128gb ram + ssd.
does jena fuseki /tdb take full advantage of the extras cores on full
load with these workers?
On Wed, Nov 22, 2017 at 11:2
On 21/11/17 18:08, Marco Neumann wrote:
congratulations to the entire Jena community it's a great open source
for many projects, products and research activities around the world.
is there a copy of the first release available with source code
(http://www-uk.hpl.hp.com/people/bwm/rdf/jena 4/2
Upgrades are application specific. You need to look at the logs for your
current system and see if processor is maxing out of memory is swapping out to
disk too much. 2GB RAM looks a bit small but that is irrelevant if your
processor is at 100% all the time. You might also consider your disk acc
Upgrading the RAM would have more benefit. Fuseki uses TDB which relies on
memory mapped files so if you can provide more RAM more of your data can be
kept in memory by the OS. Bear in mind that this memory is off-heap so if you
do upgrade your RAM there should be no need to set the heap size
19 matches
Mail list logo