Andy, I was not suggesting to wait. That is a misunderstanding. I understand that releasing often has benefits. I just hope that principle will also apply once 256 is fixed (assuming it can be fixed). I.e. a quick release especially if the performance regression was unnecessary.
On a side note: you seem to believe that 256 will be difficult to fix. That may be, but I am not sure if it _has_ to be difficult. The performance difference between May 15 and the release is so big that there must be something obvious that caused it (I am saying this intuitively, I can't prove this obviously). If that thing cannot easily be changed then so be it. At least, it is understood why the regression was introduced. Right now, it just startling that in the span of a few weeks, a serious performance regression got introduced and that it is not understood. As for IBM teams using Jena, yes, I am sure it is used a lot. I don't know all of them and some are more open than others. As you can imagine, IBM has 400k employees and we are not exactly one organization. IBM teams will not quickly go open with their adoption, because it may require permissions or other loopholes. I can't do anything about that. I know that in my group, we can communicate and even provide limited fixes (always requires review and approval though). If some teams in IBM use TDB as the performance baseline then you should see that as a compliment. It is probably because Jena/TDB is the most significant open source RDF/Sparql implementation right now. Simon From: Andy Seaborne <[email protected]> To: Simon Helsen/Toronto/IBM@IBMCA Cc: [email protected] Date: 06/19/2012 11:10 AM Subject: Re: [] [] () TDB Transactional error logged by Fuseki server for all update operations 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) > > >
