Quoting Niclas Hedhman <[email protected]>:
On Mon, Jan 4, 2010 at 5:30 PM, Niclas Hedhman <[email protected]> wrote:
But, no slow performance must be a general problem. I am not happy
that deleting an entity in Qi4j will take 100s of milliseconds.
Brrrrrr....
2) are you sure the latest Sesame is used? The latest release has increased
performance quite a lot, so make sure that not an older version is used.
2.3-pr1 was used. I'll check with 2.3.0 tomorrow.
2.3.0 is the same result.
I ran to this same issue myself a couple days ago. Well, my issue is
regarding strictly to creating of entities. I'm not sure about
deleting, as it seems that it gets stuck at
41188 [main] INFO org.openrdf.sail.nativerdf.NativeStore - Waiting for
active connections to close before shutting down...
for indefinite amount of time whenever I shut down - maybe I should
have waited even longer. Actually came to think about it, this might
be exactly that - the other thread is doing deleting, which is taking
huge amount of time, and when shutdown is initated from another
thread, it waits till that gets completed - apparently a very long time.
The problem manifested itself already with couple thousand entities or
so. And that wasn't even a fairly large usecase in our project. Of
course I might need to re-work on architecture a bit and maybe turn
those entities into value-composites or something.
Anyway, I was using old (2.2.4) Sesame. Perhaps I should try a newer
version, but because of my discovery, I don't think it will help much.
Here's the case.
I downloaded and installed TPTP for Eclipse (profiling plug-in).
Having lots of trouble running it (our code was Eclipse plug-in in
itself, so had to profile the whole thing as Eclipse application, thus
ending up with profiler eating over 2.5GB of memory), it finally
crashed and corrupted itself, so I am now unable to run further tests
without a proper cleanup of my Eclipse (gee, thanks). Before that
happened though, I managed to find out that when the commit of the
unit of work began, roughly half of the time was spent somewhere in
info.aduna.concurrent.locks.Lock.getExclusiveLock() . I tried to find
source for that component but it seems there isn't available one. But,
because of the nature of this concurrent problem (it sometimes
actually doesn't take long time to commit uow at all - time varies
between 3 sec and 1min with current load), and Niclas reporting same
performance issues in 2.3.0, I doubt the problem has been solved.
Additionally, I tried to divide my process into several smaller uow's
but it didn't help.
So, as a conclusion, it seems that Sesame has got some concurrency
problems regarding locking (possibly a file? or some other resource?).
I did not have time nor energy to perform deep-in investigation as to
what kind of problem exactly there is. I guess next step would be
either localizing the problem and reporting it and hope for a
(proper!) fix, or continue to endure it and try to work around it and
use a little 'hacks', or step away from Sesame.
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
