Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Graphiti » Race condition on save
Race condition on save [message #1385009] Tue, 03 June 2014 15:30 Go to next message
Hernan Gonzalez is currently offline Hernan GonzalezFriend
Messages: 181
Registered: October 2010
Location: Buenos Aires, Argentina
Senior Member
I've spent too much time debugging this ugly problem.

My symptoms: I modified my diagram in the editor (dirty mark appears), save it (dirty mark goes out), switch to another editor instance, return to the previous... and the original editor appeared marked as dirty; actually, it isn't, and the save is disabled - worst, the problem is not fully reproducible, it happens sometimes (strangely enough, more in my Linux VM than in my Windows host). And when debuggin I see lot of strange things happening during the editor reactivation (a handleResourceChanged is triggered, which triggers a resource unload so that a refresh reloads it, but while the resource is unloaded there are quite a few of isDirty() calls, which get rather confused - they don't expect to be called when there is no accesible diagram... ) A nightmare.

Anyway. I'm still not sure if all that strange things points to some hidden programming issues inside my code or Graphiti code, but I finally discovered that the root problem occured earlier, and it was simpler.

The problem is in DomainModelWorkspaceSynchronizerDelegate.handleResourceChanged()
which is called by Eclipse when it detects changes in the resources (at the Eclipse level, not at the EMF domain level - typically, changed files). Graphiti current logic is to compare the file timestamp with the resource timestamp and set resourceChanged=true if and only if these don't coincide.

There is a potential (and, in my case actual) race condition here. The resource timestamp is set after the file has been writen and closed.
Can we be sure that the Eclipse notification of changed file will reach us AFTER the timestamp on the resource has been set? Apparently we can't. And apparently, for me it happened earlier - and this messed up everything. Empirically, I found that adding a to DomainModelWorkspaceSynchronizerDelegate.handleResourceChanged() a mere Thread.sleep(5) before resource.getTimeStamp() fixed the problem.

Of course, I'm not very happy with this solution Razz but anyway, I think something should be done. Is anyone aware of some related issue? Should I fill a bug?

[Updated on: Tue, 03 June 2014 15:33]

Report message to a moderator

Re: Race condition on save [message #1385013 is a reply to message #1385009] Tue, 03 June 2014 15:54 Go to previous messageGo to next message
Hernan Gonzalez is currently offline Hernan GonzalezFriend
Messages: 181
Registered: October 2010
Location: Buenos Aires, Argentina
Senior Member
Perhaps, I'm thinkin, a more clean solution would be: after a save, call getUpdateBehavior().setResourceChanged(false);
Re: Race condition on save [message #1385103 is a reply to message #1385013] Wed, 04 June 2014 11:06 Go to previous messageGo to next message
Michael Wenz is currently offline Michael WenzFriend
Messages: 1635
Registered: July 2009
Location: Walldorf, Germany
Senior Member
Hernan,

thanks, and again, please file a Bugzilla for this. This looks like a
remains from the migration from our previous modeling infrastructure...

Michael
Re: Race condition on save [message #1385150 is a reply to message #1385009] Wed, 04 June 2014 15:31 Go to previous message
Hernan Gonzalez is currently offline Hernan GonzalezFriend
Messages: 181
Registered: October 2010
Location: Buenos Aires, Argentina
Senior Member

Done
https://bugs.eclipse.org/bugs/show_bug.cgi?id=436601
Previous Topic:Problem with EReference
Next Topic:Problem with EReference
Goto Forum:
  


Current Time: Sun Nov 23 12:36:05 GMT 2014

Powered by FUDForum. Page generated in 0.01669 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software