New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix serialization of PendingClusterTask.timeInQueue. #8077
Conversation
This parameter is serialized as a vLong while it could sometimes be negative.
LGTM |
This parameter is serialized as a vLong while it could sometimes be negative. Close #8077
This parameter is serialized as a vLong while it could sometimes be negative. Close #8077
we just hit this in our BWC test here http://build-us-00.elasticsearch.org/job/es_bwc_1x/7637/CHECK_BRANCH=tags%2Fv1.1.2,jdk=JDK7,label=bwc/testReport/junit/org.elasticsearch.snapshots/SnapshotBackwardsCompatibilityTest/testSnapshotAndRestore/ maybe we should make sure the value to vlong is positive? |
@jpountz ping |
@s1monw we use -1 to signal stuff in the queue which are not updateTasks (as far as I can tell those are timeout notifications). See https://github.com/elasticsearch/elasticsearch/blob/master/src/main/java/org/elasticsearch/cluster/service/InternalClusterService.java#L306 I think this is what is broken. We should have a common queue item base class that gives as the time inserted + a source and only have these in queue (UpdateTask should inherit from it). |
I just wanna fix the assertion here. We arlready have new code that transfers it correctly. WE can't fix this differently sorry. |
^^ by that I mean for nodes < 1.4.0 |
My suggestion implies we never write negative values. if we never have to write a negative value, I think the problem is solved for <1.4 as well.
maybe you meant writing a 0 where we see -1 (which is a valid value now). This is also a workaround but is not the "right" thing. Just wanted to share the idea of a proper fix. |
again the issue is fixed we use |
@s1monw are you suggesting we should fix it by removing the assertion? |
no I am suggesting to fix the BWC code to send |
Makes sense to me. +1 |
`#writeVLong` can only serialize positive values, yet this BWC code in `PendingClusterTask` passes occational `-1` causing assertions to trip. It also yields completely wrong values ie. if `-1 is deserialized it yields `9223372036854775807`. This commit ensure that `timeInQueue` is positive ie. at least `0` Relates to elastic#8077
`#writeVLong` can only serialize positive values, yet this BWC code in `PendingClusterTask` passes occational `-1` causing assertions to trip. It also yields completely wrong values ie. if `-1 is deserialized it yields `9223372036854775807`. This commit ensure that `timeInQueue` is positive ie. at least `0` Relates to #8077
`#writeVLong` can only serialize positive values, yet this BWC code in `PendingClusterTask` passes occational `-1` causing assertions to trip. It also yields completely wrong values ie. if `-1 is deserialized it yields `9223372036854775807`. This commit ensure that `timeInQueue` is positive ie. at least `0` Relates to #8077 Conflicts: src/main/java/org/elasticsearch/cluster/service/PendingClusterTask.java
…ds that go into InternalClusterService.updateTasksExecutor At the moment we sometime submit generic runnables, which make life slightly harder when generated pending task list which have to account for them. This commit adds an abstract TimedPrioritizedRunnable class which should always be used. This class also automatically measures time in queue, which is needed for the pending task reporting. Relates to elastic#8077 Closes elastic#9354
…ds that go into InternalClusterService.updateTasksExecutor At the moment we sometime submit generic runnables, which make life slightly harder when generated pending task list which have to account for them. This commit adds an abstract TimedPrioritizedRunnable class which should always be used. This class also automatically measures time in queue, which is needed for the pending task reporting. Relates to elastic#8077 Closes elastic#9354 Closes elastic#9671
…ds that go into InternalClusterService.updateTasksExecutor At the moment we sometime submit generic runnables, which make life slightly harder when generated pending task list which have to account for them. This commit adds an abstract TimedPrioritizedRunnable class which should always be used. This class also automatically measures time in queue, which is needed for the pending task reporting. Relates to elastic#8077 Closes elastic#9354 Closes elastic#9671
…ds that go into InternalClusterService.updateTasksExecutor At the moment we sometime submit generic runnables, which make life slightly harder when generated pending task list which have to account for them. This commit adds an abstract TimedPrioritizedRunnable class which should always be used. This class also automatically measures time in queue, which is needed for the pending task reporting. Relates to #8077 Closes #9354 Closes #9671
This parameter is serialized as a vLong while it could sometimes be negative. Close elastic#8077
`#writeVLong` can only serialize positive values, yet this BWC code in `PendingClusterTask` passes occational `-1` causing assertions to trip. It also yields completely wrong values ie. if `-1 is deserialized it yields `9223372036854775807`. This commit ensure that `timeInQueue` is positive ie. at least `0` Relates to elastic#8077
…ds that go into InternalClusterService.updateTasksExecutor At the moment we sometime submit generic runnables, which make life slightly harder when generated pending task list which have to account for them. This commit adds an abstract TimedPrioritizedRunnable class which should always be used. This class also automatically measures time in queue, which is needed for the pending task reporting. Relates to elastic#8077 Closes elastic#9354 Closes elastic#9671
`#writeVLong` can only serialize positive values, yet this BWC code in `PendingClusterTask` passes occational `-1` causing assertions to trip. It also yields completely wrong values ie. if `-1 is deserialized it yields `9223372036854775807`. This commit ensure that `timeInQueue` is positive ie. at least `0` Relates to elastic#8077 Conflicts: src/main/java/org/elasticsearch/cluster/service/PendingClusterTask.java
This parameter is serialized as a vLong while it could sometimes be negative.