|
Re: [CDO] Some observations after upgrading to the current integration build [message #1834218 is a reply to message #1826563] |
Thu, 05 November 2020 09:27   |
|
Robert Schulk wrote on Mon, 27 April 2020 09:46Recently, we upgraded from an old CDO version (R20170614-0227) to a new integration build (I20200410-0100).
First, I would like to thank the CDO team (Eike?) for the work. We are very happy with CDO, especially the new version.
Thank you very much! And sorry for this late reply.
Quote:After upgrading, our integration tests found some new potential issues which I would like to discuss.
1.) Occasional exception when updating the security realm. See attachment: stacktrace_1._securityrealm.txt. This happens only in rare cases. But the impact is quite severy for us: repeating the action with a new transaction also fails.
That looks like https://bugs.eclipse.org/bugs/show_bug.cgi?id=545114 . I'm very interested in finding and fixing the cause of this problem, but so far I haven't been able to reproduce it. Perhaps you can help with a test case?
Quote:2.) Accessing a resource from a view shortly after a transaction created the resource. See attachment: stacktrace_2_cdoid.txt. The exception points to a CDOResourceFolder which contains the new resource. Maybe this is a problem on our side? Do we need to ensure a proper timeout between a commit and accessing the resource?
The only view that is updated in sync with a commit is the committing transaction itself. All other views/transaction of all other sessions on all clients are updated asynchronously. You can not expect them to be in sync with the server unless you call CDOView.waitForUpdate(timeStamp), where the timeStamp should be the time of the commit. You can get this timeStamp like so:
CDOCommitInfo info = tx.commit();
long commitTime = info.getTimeStamp();
otherLocalView.waitForUpdate(commitTime);
Quote:3.) Under heavy load, we sometimes see the this exception. See attachment: stacktrace_3_heavyload.txt.
Unfortunately the stacktrace is slightly out of sync with the current tip of master. But I think that this exception is just an artifact caused by two things happening concurrently:
a) The conflict resolver of a transaction TX is notified about a remote change and is about to handle it.
b) The same transaction TX is currently in state INACTIVE, i.e., has been closed before.
(rest risk: the NPE is caused by event== null, not transaction==null)
If you submit a bugzilla I could try to avoid logging exceptions in this case.
Quote:4.) Potentially a false-positive exception? Occurs during heavy load, but seems to have no bad effect on our side. See: stacktrace_4_unknownvalue.txt
That looks like https://bugs.eclipse.org/bugs/show_bug.cgi?id=568214 , which I've fixed 10 days ago ;-)
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.02196 seconds