Home » Modeling » EMF "Technology" (Ecore Tools, EMFatic, etc) » [EMFStore] Recovery from checksum error
| |
| Re: [EMFStore] Recovery from checksum error [message #1164448 is a reply to message #1164321] |
Thu, 31 October 2013 17:43   |
 Scott Dybiec
Messages: 148
Registered: July 2009 |
Senior Member |
|
|
Thanks for that explanation, Maximilian. Good to know that there is a
simple way to resolve checksum problems for production situations.
As a developer like you that has to support users, I very much
understand the need for good forensic data to diagnose problems.
Unfortunately, I've only been able to make this problem occur once in my
application and have not been able to create a test case that
demonstrates the problem. I'll avoid using the AUTOCORRECT feature in my
development environment so I'll know if it occurs again. Does the
EMFStore client or server log any data that would be useful in getting
to root cause? I suspect that root cause of the corruption occurs long
before the checksum finds the problem, so I understand your interest in
the model.
Yes, I can share my ecore model --- both the .ecore and .genmodel are
attached. And, yes, I have a small amount of custom code in the
generated EObjects. The vast majority of the custom code is outside the
generated classes themselves, though. I stay with EMF's standard
generated code for most everything. What sort of custom code could cause
checksum errors?
It's possible that this checksum is somehow related to the exception
thrown, because the problem has not recurred since I started removing
all model elements from their Resources before adding them to EMFStore.
You know your code, so you could speak to the actual likelihood of that.
Scott
On 10/31/2013 11:45 AM, Maximilian Koegel wrote:
> Hi Scott,
>
> sorry for the late reply, we have been at EclipseCon during the last
> couple of days and were pretty busy with our talks.
> By default EMFStore will check the consistency of the model on the
> client with the model on the server on update and commit. The server
> sends a checksum of the model in a particular version to the client and
> the client compares it with its checksum. In case they are not equal the
> client will call a ChecksumErrorHandler. The default error handler just
> cancels the commit or update, since a checksum error is usually a sign
> that something is wrong with your model. I will go into details about
> what this could be in the following. You can register an Checksum
> at the extension point
> org.eclipse.emf.emfstore.client.checksumErrorHandler. If you want the
> mismatch between client and server automatically resolved (without data
> loss) you could register ChecksumErrorHandler.AUTOCORRECT in package
> org.eclipse.emf.emfstore.internal.client.model.util in
> org.eclipse.emf.emfstore.client.model. (The class is internal at the
> moment.) The handler will re-checkout the project and reapply local
> changes as necessary.
> However I think it is usually important to find out why the mismatch of
> checksums occurred. From my experience it could be custom code in your
> model or some special configuration in your Ecore. Do you have custom
> code in your model? Can you share your Ecore here or privately?
> Maybe your workaround is related to the new problem? How did you work
> around your other problem?
>
> Cheers,
> Maximilian
>
>
>
>
> Am 30.10.2013 04:03, schrieb scott@xxxxxxxx:
>> I'm making good progress getting EMFStore to work with my application. I
>> found a workaround for the exception thrown when a model element
>> contained in a Resource is added to EMFStore.
>>
>> Since the robustness of the store is critical for my application, this
>> checksum problem I've run into worries me.
>>
>> How do I recover from a checksum error like the one in the screenshot?
>> EMFStore is attempting to do an update from the server and fails. Does
>> recovery from this kind of error result in data loss?
>>
>> Scott
>>
>
>
|
|
|
| Re: [EMFStore] Recovery from checksum error [message #1165535 is a reply to message #1164448] |
Fri, 01 November 2013 10:59 |
Scott Dybiec
Messages: 148
Registered: July 2009 |
Senior Member |
|
|
I spoke too soon. The checksum occurred again.
Is there some diff-type utility and/or procedure to determine the
difference between the models with different checksums on the client and
server? Could EMFStore be instrumented to log some forensic data when
the checksum occurs to determine the immediate cause of the checksum?
Maybe this would lead us one step closer to root cause.
Scott
On 10/31/2013 1:43 PM, Scott Dybiec wrote:
> Thanks for that explanation, Maximilian. Good to know that there is a
> simple way to resolve checksum problems for production situations.
>
> As a developer like you that has to support users, I very much
> understand the need for good forensic data to diagnose problems.
> Unfortunately, I've only been able to make this problem occur once in my
> application and have not been able to create a test case that
> demonstrates the problem. I'll avoid using the AUTOCORRECT feature in my
> development environment so I'll know if it occurs again. Does the
> EMFStore client or server log any data that would be useful in getting
> to root cause? I suspect that root cause of the corruption occurs long
> before the checksum finds the problem, so I understand your interest in
> the model.
>
> Yes, I can share my ecore model --- both the .ecore and .genmodel are
> attached. And, yes, I have a small amount of custom code in the
> generated EObjects. The vast majority of the custom code is outside the
> generated classes themselves, though. I stay with EMF's standard
> generated code for most everything. What sort of custom code could cause
> checksum errors?
>
> It's possible that this checksum is somehow related to the exception
> thrown, because the problem has not recurred since I started removing
> all model elements from their Resources before adding them to EMFStore.
> You know your code, so you could speak to the actual likelihood of that.
>
> Scott
>
> On 10/31/2013 11:45 AM, Maximilian Koegel wrote:
>> Hi Scott,
>>
>> sorry for the late reply, we have been at EclipseCon during the last
>> couple of days and were pretty busy with our talks.
>> By default EMFStore will check the consistency of the model on the
>> client with the model on the server on update and commit. The server
>> sends a checksum of the model in a particular version to the client and
>> the client compares it with its checksum. In case they are not equal the
>> client will call a ChecksumErrorHandler. The default error handler just
>> cancels the commit or update, since a checksum error is usually a sign
>> that something is wrong with your model. I will go into details about
>> what this could be in the following. You can register an Checksum
>> at the extension point
>> org.eclipse.emf.emfstore.client.checksumErrorHandler. If you want the
>> mismatch between client and server automatically resolved (without data
>> loss) you could register ChecksumErrorHandler.AUTOCORRECT in package
>> org.eclipse.emf.emfstore.internal.client.model.util in
>> org.eclipse.emf.emfstore.client.model. (The class is internal at the
>> moment.) The handler will re-checkout the project and reapply local
>> changes as necessary.
>> However I think it is usually important to find out why the mismatch of
>> checksums occurred. From my experience it could be custom code in your
>> model or some special configuration in your Ecore. Do you have custom
>> code in your model? Can you share your Ecore here or privately?
>> Maybe your workaround is related to the new problem? How did you work
>> around your other problem?
>>
>> Cheers,
>> Maximilian
>>
>>
>>
>>
>> Am 30.10.2013 04:03, schrieb scott@xxxxxxxx:
>>> I'm making good progress getting EMFStore to work with my application. I
>>> found a workaround for the exception thrown when a model element
>>> contained in a Resource is added to EMFStore.
>>>
>>> Since the robustness of the store is critical for my application, this
>>> checksum problem I've run into worries me.
>>>
>>> How do I recover from a checksum error like the one in the screenshot?
>>> EMFStore is attempting to do an update from the server and fails. Does
>>> recovery from this kind of error result in data loss?
>>>
>>> Scott
>>>
>>
>>
>
|
|
| |
| Re: [EMFStore] Recovery from checksum error [message #1170606 is a reply to message #1170485] |
Mon, 04 November 2013 19:18 |
Scott Dybiec
Messages: 148
Registered: July 2009 |
Senior Member |
|
|
Thanks, Edgar.
It'll be great to have a checksum handler that can log data to help with
getting to the bottom of checksum problems. Glad to hear it's already on
the TODO list.
EMFCompare's diff utility would seem to be the right tool for finding
the differences, since it can report more EMF model-level difference
information ---- graphically in Eclipse.
Would you expect diff'ing the client and server XMI artifacts to yield
clues to the cause of the checksum? I don't understand the process that
EMF goes through during an update when I see this problem, so I have a
question:
What versions are being compared using their checksums during an update?
The checksum surfaces during an update. For example, in the situation
where the server has V2 of the project and the client has V1, does the
update action cause the change set to be downloaded, applied to V1
making it V2 and checksum computed on the client's new V2 and compared
with the server's V2 checksum? Or are the V1 checksums on both sides
compared before the operations are downloaded and applied? I ask because
this would impact what diff's would be meaningful to compare.
Scott
On 11/4/2013 12:28 PM, Edgar Mueller wrote:
> Hi Scott,
>
> you can diff the projectstates of the client/server with any text-based
> diff utility, since, by default, EMFStore is saving EMF resources as XMI
> files. You would need to compare the contents of the projectstate-x.ups
> file in your .emfstore/server/profiles/default/projext-<ID>/ directory
> with the one from .emfstore/client/profiles/default/ps-<ID>/project.ecp
> (assuming that you are using the default profile).
>
> We are planning to provide an additional checksum error handler which
> will report the differences between the projectstates soon.
>
> Cheers,
> Edgar
>> Is there some diff-type utility and/or procedure to determine the
>> difference between the models with different checksums on the client and
>> server? Could EMFStore be instrumented to log some forensic data when
>> the checksum occurs to determine the immediate cause of the checksum?
>> Maybe this would lead us one step closer to root cause.
>>
>> Scott
>
>
|
|
|
| Re: [EMFStore] Recovery from checksum error [message #1171508 is a reply to message #1170606] |
Tue, 05 November 2013 09:27 |
Edgar Mueller
Messages: 89
Registered: March 2011 |
Member |
|
|
Hi Scott,
your initial assumption about the checksum computation is almost
correct. There's only one additional subtlety, that is, that you have to
deal with local pending changes, too. Therefore here's the detailed
process for computing the checksums for both commit and update.
In case of an update, the project being updated will first resolve the
version to update to on the server (in most cases this will be HEAD).
The resolved version will contain a project state checksum field which
has been generated while the most recent commit on the server did happen
for the project. The resovled version is also used to fetch the
changepackage that contains all operations that need to be applied on
the project.
Now, while updating, all pending local changes on the project are first
being reverted. This leaves you with a 'clean' project, without any
local operations. Than the incoming changepackage from the server will
be applied upon the project and the checksum is computed. This checksum
will be compared against the checksum that is contained in the version.
The update process then continues by re-applying the local changes.
In case of a commit, the client will receive the most recent version as
a return value. This version contains the checksum as computed by the
server. We don't have to care about any local pending changes, since a
project can't contain such after a commit. So, the client may compute
its own checksum for the project and compare it against the checksum of
the version.
We also know about EMFCompare, but for error diagnosis it often is
enough to just load both project states files in a diff editor and
hightlight the lines that differ. In most cases this already gave us a
clue about what why the checksum computations did fail.
I hope this helps.
Cheers,
Edgar
Am 04.11.2013 20:18, schrieb Scott Dybiec:
> Thanks, Edgar.
>
> It'll be great to have a checksum handler that can log data to help with
> getting to the bottom of checksum problems. Glad to hear it's already on
> the TODO list.
>
> EMFCompare's diff utility would seem to be the right tool for finding
> the differences, since it can report more EMF model-level difference
> information ---- graphically in Eclipse.
>
> Would you expect diff'ing the client and server XMI artifacts to yield
> clues to the cause of the checksum? I don't understand the process that
> EMF goes through during an update when I see this problem, so I have a
> question:
>
> What versions are being compared using their checksums during an update?
> The checksum surfaces during an update. For example, in the situation
> where the server has V2 of the project and the client has V1, does the
> update action cause the change set to be downloaded, applied to V1
> making it V2 and checksum computed on the client's new V2 and compared
> with the server's V2 checksum? Or are the V1 checksums on both sides
> compared before the operations are downloaded and applied? I ask because
> this would impact what diff's would be meaningful to compare.
>
> Scott
>
> On 11/4/2013 12:28 PM, Edgar Mueller wrote:
>> Hi Scott,
>>
>> you can diff the projectstates of the client/server with any text-based
>> diff utility, since, by default, EMFStore is saving EMF resources as XMI
>> files. You would need to compare the contents of the projectstate-x.ups
>> file in your .emfstore/server/profiles/default/projext-<ID>/ directory
>> with the one from .emfstore/client/profiles/default/ps-<ID>/project.ecp
>> (assuming that you are using the default profile).
>>
>> We are planning to provide an additional checksum error handler which
>> will report the differences between the projectstates soon.
>>
>> Cheers,
>> Edgar
>>> Is there some diff-type utility and/or procedure to determine the
>>> difference between the models with different checksums on the client and
>>> server? Could EMFStore be instrumented to log some forensic data when
>>> the checksum occurs to determine the immediate cause of the checksum?
>>> Maybe this would lead us one step closer to root cause.
>>>
>>> Scott
>>
>>
>
--
Edgar Mueller
Get Professional Eclipse Support: http://eclipsesource.com/munich
|
|
|
| Re: [EMFStore] Recovery from checksum error [message #1196434 is a reply to message #1171508] |
Tue, 19 November 2013 12:11 |
Scott Dybiec
Messages: 148
Registered: July 2009 |
Senior Member |
|
|
Thanks for that excellent explanation. I read it through a few times and
think I understand it.
My application listens on EMF notifications and, in some cases, makes
changes to the model in the body of the notifyChanged method:
public void notifyChanged(Notification notification) {}
I'm wondering whether these notification side-effects, which do occur
during the EMFStore update process, would cause a checksum error during
update. Based on your description, I think so.
I'm not currently using a TransactionEditingDomain, because my
application is single threaded. Would using a TransactionalEditingDomain
catch problems like this?
Scott
On 11/5/2013 4:27 AM, Edgar Mueller wrote:
> Hi Scott,
>
> your initial assumption about the checksum computation is almost
> correct. There's only one additional subtlety, that is, that you have to
> deal with local pending changes, too. Therefore here's the detailed
> process for computing the checksums for both commit and update.
>
> In case of an update, the project being updated will first resolve the
> version to update to on the server (in most cases this will be HEAD).
> The resolved version will contain a project state checksum field which
> has been generated while the most recent commit on the server did happen
> for the project. The resovled version is also used to fetch the
> changepackage that contains all operations that need to be applied on
> the project.
> Now, while updating, all pending local changes on the project are first
> being reverted. This leaves you with a 'clean' project, without any
> local operations. Than the incoming changepackage from the server will
> be applied upon the project and the checksum is computed. This checksum
> will be compared against the checksum that is contained in the version.
> The update process then continues by re-applying the local changes.
>
> In case of a commit, the client will receive the most recent version as
> a return value. This version contains the checksum as computed by the
> server. We don't have to care about any local pending changes, since a
> project can't contain such after a commit. So, the client may compute
> its own checksum for the project and compare it against the checksum of
> the version.
>
> We also know about EMFCompare, but for error diagnosis it often is
> enough to just load both project states files in a diff editor and
> hightlight the lines that differ. In most cases this already gave us a
> clue about what why the checksum computations did fail.
>
> I hope this helps.
>
> Cheers,
> Edgar
>
> Am 04.11.2013 20:18, schrieb Scott Dybiec:
>> Thanks, Edgar.
>>
>> It'll be great to have a checksum handler that can log data to help with
>> getting to the bottom of checksum problems. Glad to hear it's already on
>> the TODO list.
>>
>> EMFCompare's diff utility would seem to be the right tool for finding
>> the differences, since it can report more EMF model-level difference
>> information ---- graphically in Eclipse.
>>
>> Would you expect diff'ing the client and server XMI artifacts to yield
>> clues to the cause of the checksum? I don't understand the process that
>> EMF goes through during an update when I see this problem, so I have a
>> question:
>>
>> What versions are being compared using their checksums during an update?
>> The checksum surfaces during an update. For example, in the situation
>> where the server has V2 of the project and the client has V1, does the
>> update action cause the change set to be downloaded, applied to V1
>> making it V2 and checksum computed on the client's new V2 and compared
>> with the server's V2 checksum? Or are the V1 checksums on both sides
>> compared before the operations are downloaded and applied? I ask because
>> this would impact what diff's would be meaningful to compare.
>>
>> Scott
>>
>> On 11/4/2013 12:28 PM, Edgar Mueller wrote:
>>> Hi Scott,
>>>
>>> you can diff the projectstates of the client/server with any text-based
>>> diff utility, since, by default, EMFStore is saving EMF resources as XMI
>>> files. You would need to compare the contents of the projectstate-x.ups
>>> file in your .emfstore/server/profiles/default/projext-<ID>/ directory
>>> with the one from .emfstore/client/profiles/default/ps-<ID>/project.ecp
>>> (assuming that you are using the default profile).
>>>
>>> We are planning to provide an additional checksum error handler which
>>> will report the differences between the projectstates soon.
>>>
>>> Cheers,
>>> Edgar
>>>> Is there some diff-type utility and/or procedure to determine the
>>>> difference between the models with different checksums on the client
>>>> and
>>>> server? Could EMFStore be instrumented to log some forensic data when
>>>> the checksum occurs to determine the immediate cause of the checksum?
>>>> Maybe this would lead us one step closer to root cause.
>>>>
>>>> Scott
>>>
>>>
>>
>
>
|
|
|
| Re: [EMFStore] Recovery from checksum error [message #1196668 is a reply to message #1196434] |
Tue, 19 November 2013 14:30 |
Edgar Mueller
Messages: 89
Registered: March 2011 |
Member |
|
|
Hi Scott,
comments inline.
> Thanks for that excellent explanation. I read it through a few times and
> think I understand it.
You're welcome :)
> I'm wondering whether these notification side-effects, which do occur
> during the EMFStore update process, would cause a checksum error during
> update. Based on your description, I think so.
Yes, this is likely. It depends on when exactly you try to modify your
model instance (before or after the checksum computation), and if
EMFStore is able to track these changes.
Generally, i would not advise you to modify the model instance while an
update/commit is happening, since the checksum is based on the state of
your project and the model instances it contains. If you modify your
project during an update the project state of the client will differ
from the project state on the server and you will receive a checksum
error. Can you explain a bit more in detail why you modify your model
instance during an update and what you are trying to achieve? Maybe you
are able to use one of the update hooks in ESUpdateObserver.
> I'm not currently using a TransactionEditingDomain, because my
> application is single threaded. Would using a TransactionalEditingDomain
> catch problems like this?
I don't think the use of a TransactionalEditingDomain will solve this
issue, since the problem of a client having a different project state
than on the server remains.
Cheers
Edgar
--
Edgar Mueller
Get Professional Eclipse Support: http://eclipsesource.com/munich
|
|
|
| Re: [EMFStore] Recovery from checksum error [message #1201073 is a reply to message #1196668] |
Thu, 21 November 2013 15:06 |
Scott Dybiec
Messages: 148
Registered: July 2009 |
Senior Member |
|
|
Edgar,
Given your comments it's likely that some of the checksum errors I've
encountered are due to model changes my code makes made during
notifications triggered by EMFStore update().
You asked what these model-updates-triggered-on-notification do.
1. Sorting: If a new element is added to a reference list, sort the list.
2. Synchronization between elements of the model.
3. Other things I can't remember now.
It's convenient to have these tasks triggered on model changes. I'll
have to think about how to do these in another way. Any ideas are welcome.
One approach is to put this logic in a service layer of code in front of
my application's model as a single point of entry (API) for model
updates. Won't work for all the use cases, but should work for some.
I have another follow-up question ;-)
Is it safe to turn off notifications temporarily for some updates?
EObject.eSetDeliver(false);
Does EMFStore use notification to gather the model operations? More
generally, I'd like to know how to avoid all the coding practices that
could cause EMFStore checksums.
$cott
On 11/19/2013 9:30 AM, Edgar Mueller wrote:
> Hi Scott,
>
> comments inline.
>
>> Thanks for that excellent explanation. I read it through a few times and
>> think I understand it.
> You're welcome :)
>
>> I'm wondering whether these notification side-effects, which do occur
>> during the EMFStore update process, would cause a checksum error during
>> update. Based on your description, I think so.
> Yes, this is likely. It depends on when exactly you try to modify your
> model instance (before or after the checksum computation), and if
> EMFStore is able to track these changes.
> Generally, i would not advise you to modify the model instance while an
> update/commit is happening, since the checksum is based on the state of
> your project and the model instances it contains. If you modify your
> project during an update the project state of the client will differ
> from the project state on the server and you will receive a checksum
> error. Can you explain a bit more in detail why you modify your model
> instance during an update and what you are trying to achieve? Maybe you
> are able to use one of the update hooks in ESUpdateObserver.
>
>> I'm not currently using a TransactionEditingDomain, because my
>> application is single threaded. Would using a TransactionalEditingDomain
>> catch problems like this?
> I don't think the use of a TransactionalEditingDomain will solve this
> issue, since the problem of a client having a different project state
> than on the server remains.
>
> Cheers
> Edgar
>
|
|
|
| Re: [EMFStore] Recovery from checksum error [message #1202718 is a reply to message #1201073] |
Fri, 22 November 2013 09:28 |
Edgar Mueller
Messages: 89
Registered: March 2011 |
Member |
|
|
Hi Scott,
yes, this should be safe and your assumptions about EMFStore's inner
workings are correct. EMFStore is using the notification mechanism to
create operations if any project content changes. The checksum error
encountered by you happens because change tracking is deactivated while
an update is happening, since this would cause the operations that are
applied by the update to be recorded again. If modifying the content
during the update, like you do, EMFStore has no possiblity to track
these changes. This means, these modifications will not be sent to the
server, what causes the different project states.
So, the general rule to follow to avoid checksum errors is: do not
modify a project or the contents of it while EMFStore's change tracking
is deactivated (which is only the case during an update)
Regarding your alternative approach: I think that's a good idea, since
in most cases sorting should not be an integral property of the model
itself, but rather should be handled as an representation issue, e.g. as
if in a table, where sorting can be applied dependent on the clicked column.
Hope this helps.
Cheers,
Edgar
Am 21.11.2013 16:06, schrieb scott@xxxxxxxx:
> Edgar,
>
> Given your comments it's likely that some of the checksum errors I've
> encountered are due to model changes my code makes made during
> notifications triggered by EMFStore update().
>
> You asked what these model-updates-triggered-on-notification do.
> 1. Sorting: If a new element is added to a reference list, sort the list.
> 2. Synchronization between elements of the model.
> 3. Other things I can't remember now.
>
> It's convenient to have these tasks triggered on model changes. I'll
> have to think about how to do these in another way. Any ideas are welcome.
>
> One approach is to put this logic in a service layer of code in front of
> my application's model as a single point of entry (API) for model
> updates. Won't work for all the use cases, but should work for some.
>
> I have another follow-up question ;-)
>
> Is it safe to turn off notifications temporarily for some updates?
>
> EObject.eSetDeliver(false);
>
> Does EMFStore use notification to gather the model operations? More
> generally, I'd like to know how to avoid all the coding practices that
> could cause EMFStore checksums.
>
> $cott
>
> On 11/19/2013 9:30 AM, Edgar Mueller wrote:
>> Hi Scott,
>>
>> comments inline.
>>
>>> Thanks for that excellent explanation. I read it through a few times and
>>> think I understand it.
>> You're welcome :)
>>
>>> I'm wondering whether these notification side-effects, which do occur
>>> during the EMFStore update process, would cause a checksum error during
>>> update. Based on your description, I think so.
>> Yes, this is likely. It depends on when exactly you try to modify your
>> model instance (before or after the checksum computation), and if
>> EMFStore is able to track these changes.
>> Generally, i would not advise you to modify the model instance while an
>> update/commit is happening, since the checksum is based on the state of
>> your project and the model instances it contains. If you modify your
>> project during an update the project state of the client will differ
>> from the project state on the server and you will receive a checksum
>> error. Can you explain a bit more in detail why you modify your model
>> instance during an update and what you are trying to achieve? Maybe you
>> are able to use one of the update hooks in ESUpdateObserver.
>>
>>> I'm not currently using a TransactionEditingDomain, because my
>>> application is single threaded. Would using a TransactionalEditingDomain
>>> catch problems like this?
>> I don't think the use of a TransactionalEditingDomain will solve this
>> issue, since the problem of a client having a different project state
>> than on the server remains.
>>
>> Cheers
>> Edgar
>>
>
--
Edgar Mueller
Get Professional Eclipse Support: http://eclipsesource.com/munich
|
|
|
Goto Forum:
Current Time: Fri Apr 19 11:21:35 GMT 2024
Powered by FUDForum. Page generated in 0.02685 seconds |
] 
Search
Help
Register
Login
Home
