Community
Participate
Working Groups
Opened up a review with 3 patchsets, but the section appears empty. Collapsing/expanding doesn't change this state seen on: Mylyn Reviews Connector: Gerrit 2.0.1.I20130712-2204
Created attachment 233636 [details] patchset section not showing patchsets
a refresh of the editor made them appear. nothing in the error log
Actually, I just updated the gerrit connector and this happens on all my offline cached reviews. version I updated from: Mylyn Reviews Connector: Gerrit 2.0.0.I20130506-1308 Could be sever if this happens when updating from a released version
ok, no, this happens on each review that I open. Once I manually select "Synchronize Incoming Changes" in the task editor, it renders. So this is a persistant issue.
could be related to bug 413363, as an error appeared in the error log a few minutes after I have seen this issue the first time
Now that I think about it, maybe this only happens when upgrading from a weekly build. After you refresh the editor, does it happen again for the same review?
Yes. This happens again and again on every review I try. I actually reverted to the last released version as this together with the reappearing stack overflow from bug 413363 made the connector unusable for me.
When opening the editor @ReviewSetSection.createContent(FormToolkit, Composite)@ is called to create "Patch Sets" section and to reveal the current patch set. In Thomas' case (which I'm able to reproduce), @getReview().getSets()@ returns an empty collection, thus no patch set is displayed. However, when I synchronized the query containing the review first, the editor rendered as expected.
(In reply to comment #8) > When opening the editor @ReviewSetSection.createContent(FormToolkit, Composite)@ > is called to create "Patch Sets" section and to reveal the current patch set. In > Thomas' case (which I'm able to reproduce), @getReview().getSets()@ returns an > empty collection, thus no patch set is displayed. However, when I synchronized > the query containing the review first, the editor rendered as expected. The interesting thing is that I had this over and over again, so whatever causes getSets() to be filled when I synchronize the task (from the open task editor), it doesn't get persisted. Closing the editor and reopening reproduces this (so not sure whether it's the same cause or not)
I believe the behavior is expected in the sense that the section does not render when the data is not cached. In Thomas case it sounds like the review caching is broken and hence it always happens. It's odd that there is no logging. Tomek, could you check if errors are expected to be logged if stuff can't be persisted? Thomas, to recover you could try to delete the offline cache in workspace/.metadata/.mylyn/reviews_bin.
(In reply to comment #10) > In Thomas case it sounds like the review caching is broken ...which could be related to to the EMF stack overflow reported on bug 413363...
(In reply to comment #10) > Thomas, to recover you could try to delete the offline cache in > workspace/.metadata/.mylyn/reviews_bin. I actually reverted to the last released Gerrit as I cannot afford to be impeded that much during the end of the release cycle :(.
(In reply to comment #10) > In Thomas case it sounds like the review caching is broken and hence it always > happens. It's odd that there is no logging. Tomek, could you check if errors are > expected to be logged if stuff can't be persisted? Right. Bug 413363 is the cause of this. Otherwise as Steffen states, this is working as expected (better in fact, because it's not actually totally choking, it just won't persist properly.) > Thomas, to recover you could try to delete the offline cache in > workspace/.metadata/.mylyn/reviews_bin. Thomas, as soon as release is over, please try deleting the cache. But *before* you do that :), I'd also like to see a copy of the cache if you can save it.
I checked with Thomas and he is using a directory with spaces for workspace, e.g. "C:\work\workspaces\to work from". So I'm pretty sure this is a dup of bug 413363 which is likely a dup of bug 413480. :) *** This bug has been marked as a duplicate of bug 413363 ***
Miles, While it appears the stack overflow is not happening, I am now observing bug 414460, bug 414461 and bug 414464 (the latter sounds a lot like it's related to this one and bug 413363).
