Not all intervals are transferred at shutdown #230
Comments
|
Hm, very strange, this is new to me. Could you debug a bit into this, please? |
|
Sure, will do |
|
👍 |
|
I have some more info after debugging for a while. I've added some print statements, resulting in the following log: So, as you can see, some intervals are not added to the set of intervals to persist. In particular, when shutting down, four intervals still need to be closed. However, only one of those intervals is actually added to the set of intervals to persist. Therefore, at the end only two intervals are transferred to the server and the other intervals are simply lost. When an interval is not correctly added, the return value of set.add() is false. Therefore, it seems like this issue is caused by a defect in the equality checks of the intervals. I'll look further into this bug tomorrow morning and try to fix it |
|
In addition, in the log shown above you can see that the bug does not only appear before shutting down. The ReadingInterval is also lost due to this bug, which is already closed before shutdown. This means that this seems to be a quite severe bug, as we are losing quite some data in this way. |
|
Thanks a lot for the bug fix. |
Adds an EqualsVerifier test to detect possible problems in our equals implementation. Purposefully breaks the build, as the contract is violated (test fails). Refs #230
|
Sorry for reopening this, but see #243, which will fail in a few minutes :-) Could you take care of fixing it? |
|
#243 indeed fails, but not because of the problem described (at least not in this build). However, I've checked out the branch and the test does actually fail. I'll see if I can easily fix this |
|
OK, I fixed the fail and now the build actually fails for the right reason (double-fail) ;-) |
|
👍 I've now fixed that hashCode error by adding a hashCode method to IntervalBase. Unfortunately this results in new errors... The question I have now is: can an instance of IntervalBase be equal to an instance of WatchDogTransferable or vice versa? |
|
BTW, as WatchDogTransferable is an abstract class there can never be another instance of it except for instances of IntervalBase or EventBase. These two options both override the equals method of WDT, which eliminates the situation described in my question above (as they can never be equal) or am I wrong? |
|
After adding several different new equals and hashCode methods to WatchDogTransferable and IntervalBase as well as canEqual methods as described here, errors still appear when running the test. Furthermore, I still don't really get what problem/situation we are actually trying to fix here... |
|
Niels, can you refer me to the commits you speak about? |
|
I haven't committed anything as I never got the test to pass, so I'm not referring to any commits here |
|
The problem is that we are violating the equals contract -- at least according to the EqualsVerifier. As you also said, I think this is more of a theoretical problem at this point. However, I would like to understand precisely why it complains and will investigate this later myself. Removing the WD-2.0 tag for now, so we can release. |
|
Exactly, practically every change I made based on the given error messages did not change the test results, so it seems to be a theoretical issue indeed. However, I don't know if it is even possible to fix this in practice, but we'll see. I started with a missing hashcode error so I generated a hashCode and new equals method for IntervalBase. Then a new error appeared. Trying to fix that one (and subsequent errors) using the explanations here finally results in "equals not final". However, when you make the equals final, you can't use mutable fields inside it. Unfortunately, almost all field are mutable and can't be made final either. So, then you can start all over again. For me, this process of different subsequent errors just continued whatever I changed. So finally, I just gave up for now;) |
It seems like there is a bug in transferring the closed intervals to the server when WD is shut down. Any intervals that are still open are closed before shutting down WD and the remaining intervals are transferred to the server. However, not all of these intervals are actually tranferred.
For instance, see the following log:
As you can see, 6 intervals are created and they are also closed before shutting down. However, only two intervals are received at the server that I run locally: IDE_OPEN and USER_ACTIVE. Therefore, the remaining four intervals seem to be lost.
P.S. Is this issues related to #122 @Inventitech?
The text was updated successfully, but these errors were encountered: