On 19/06/12 15:50, Simon Helsen wrote:
Andy,
I was basing that conclusion on the observations by Laurent. While I
understand that it is possible 0.9.0 had actual functional problems
(allowing it to be "faster"), the logic I am employing goes like this:
Release twice?
1) Laurent finds that 0.9.0 is considerably faster than 0.9.1 release
Probably - last we heard, it was a read/write mix. Be good to
understand the result properly; it will save a large amount of time
investigating and also provide a second test case.
2) I find that 0.9.1 (May 15) is considerably faster than 0.9.1 release
(reported in Jena-256)
3) we did significant performance and functional testing (with massive
concurrency etc.) with the 0.9.1 May 15 build which showed by our
standards that 0.9.1 May 15 appears functionally correct from our point
of view
4) my past experience with previous tx problems shows me that our
internal test coverage is quite extensive
5) there is another team here I loosely collaborate with who has been
using and functionally testing 0.9.0 for a while now and they have not
reported any problems
Yes - several groups in IBM use Jena; some say some publicly, some
don't. Seems like there are more TDB users than I was aware of. Maybe
they will de-cloak and report their experiences.
Now, to point 4), of course, it is biased. We use Jena in a specific
manner and thus we miss a large class of functional testing that does
not concern us. So, yes, it is possible that whatever happened after May
15 was important to fix functional problems. And of course, it is also
quite possible there were or even are other problems we are simply not
yet aware of.
It's not the only issue that, given infinite resources, would be fixed.
I guess I am trying to point out that performance could be important
enough to produce a new release as well as it may keep people from
upgrading if they find the new release is visibly slower without
significant other gains (for them)
err - as do log files with nasty looking exceptions and bad handling of
transaction 0.2.1 release. That can be fixed now.
Fuseki 0.2.2 is better than 0.2.1; otherwise people are using snapshots
to work round data robustness issues.
Performance of TDB is something that other groups in IBM has been keen
to mention in public presentations.
I confess I don't really see your overall argument to force a wait
rather than have several releases, each of which reduces the support
costs each time.
Andy
Simon
From: Andy Seaborne <[email protected]>
To: [email protected]
Date: 06/19/2012 10:31 AM
Subject: Re: [] [] () TDB Transactional error logged by Fuseki server
for all update operations
------------------------------------------------------------------------
Simon,
As someone who did not use 0.9.0, do you not think that we ought to move
cautiously?
Fixing the JENA-256 is a more major investigation and having fixed it
needs testing, if indeed, it is a regression rather than being more
careful, correctly, about the data - i.e. 0.9.0 may have been wrong.
The workaround for JENA-260 has been confirmed, and hopefully the proper
fix will be soon too.
Andy
On 19/06/12 15:23, Simon Helsen (JIRA) wrote:
>
> [
https://issues.apache.org/jira/browse/JENA-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13396795#comment-13396795
<https://issues.apache.org/jira/browse/JENA-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13396795#comment-13396795>]
>
> Simon Helsen commented on JENA-260:
> -----------------------------------
>
> right, like the performance regression in JENA-256 (that will be
quite visible for clients who came from 0.9.0)
