Repository navigation
Fixed ClassCastException during Multi-Stage Queries on real-time segments - #16607
nozjkoitop wants to merge 15 commits into
Conversation
…hat include columns of HLLSketch type resulted in a ClassCastException.
| if (val == null) { | ||
| return ByteArrays.EMPTY_ARRAY; | ||
| } else if (val instanceof byte[]) { | ||
| return (byte[]) val; | ||
| } else { |
There was a problem hiding this comment.
I think this is incorrect because there might exist a serde where the deserialized value is byte[], however, the serialized value can be something else.
For example, different compression techniques can transform a deserialized byte[] array to a different serialized byte[] array. This would be unique to the complex type, so it shouldn't be a universal change. Instead, the following changes can be made:
- If this only occurs in the HllSketchBuild serde, you can make this change specific to the HllSketchBuild serde.
- Else, if this occurs with all the complex types while running MSQ tasks on complex metrics, you can make the changes in MSQ-specific classes (after confirming where the byte[] array is coming from).
There was a problem hiding this comment.
Thanks for pointing that out! It looks like this issue might not be limited to just the HLLSketch. None of the ObjectStrategies seem to fit this scenario, as they all expect specific objects for the toBytes() method. Using it with a byte array directly would lead to the CCE. I'll look into why selector.getObject is returning a byte array for a real-time segment maybe it could be fixed there as well. It is not appears in MSQ classes directly tho, it shows up at ComplexFieldWriter.writeTo()
There was a problem hiding this comment.
np! Since the issue is bubbling up from the column value selectors, you can check who creates those, and why they are returning a byte array instead of the desired object type.
There was a problem hiding this comment.
I made some research and it looks like it's normal for selector.getObject to return a byte[] for real-time segments. This happens because it uses RowBasedColumnValueSelector instead of ObjectColumnSelector. It doesn't go through GenericIndexed.copyBufferAndGet() and strategy.fromByteBuffer(), and just grabs the byte[] directly from the ByteBuffer using rowSupplier.get() (at least in case of ComplexType from RealTime segment MSQ).
Right now, we don't have an ObjectStrategy that needs a byte[] as input, so initial setup would likely cause CCE failures. But you're right, we might need to handle this in the future. So, I've moved this check to the ObjectStrategy as a defaul void, making it easy to override if needed.
…ith-hllsketch-in-realtime
|
Thanks for the changes @nozjkoitop. I'll review them shortly. |
@LakshSingla Could I remind you to have a look on that please? |
|
Sorry for the delay @nozjkoitop and thanks for the update 🚀 The new approach is a lot cleaner than the previous one, but I still wanna see if there's a way to restrict the change to MSQ, since I suspect that there's a faulty selector at play. The MSQ test case would help in debugging this as well. |
…ith-hllsketch-in-realtime
I've added new test-case with hyperUnique column in select from realtime segment, please have a look |
|
@LakshSingla WDYT? |
|
Hey @nozjkoitop apologies for the delay. Let me take a look at the patch and get back to you in a couple of days. It seems correct for the most part. I just need to think if there's a less invasive way to do this given that the regression is in MSQ. I wasn't able to get to it due to a few other patches I was working on, but I'll prioritize this change. Thanks a lot for being patient with me! |
|
Hey @LakshSingla, just a kindly reminder about this PR :) |
|
@nozjkoitop I think @LakshSingla's comment was to only make changes that affect MSQ, since the bug is seen only there. I think your changes might affect other queries as well. |
Hi @adarshsanjeev ! The main issue is in |
|
This pull request has been marked as stale due to 60 days of inactivity. |
…ith-hllsketch-in-realtime # Conflicts: # extensions-core/multi-stage-query/src/test/java/org/apache/druid/msq/test/MSQTestBase.java
|
Hi @LakshSingla I've checked the latest druid and described issue is still there, although now there is a NPE on the ui, but provided patch still resolves an issue, so I merged the changes from master. Please take a look. |
|
This pull request has been marked as stale due to 60 days of inactivity. |
|
Issue is still there in v32, merged master to solve conflicts |
|
This pull request has been marked as stale due to 60 days of inactivity. |
|
This pull request/issue has been closed due to lack of activity. If you think that |
|
Something seems off with the rebase on master, there's a bunch of extra files. That being said, it seems to me like this error points at a situation where some aspect of the design is sketchy. I will reopen it. @adarshsanjeev has been looking recently into realtime queries in MSQ- would you mind taking a look at this bug? |
|
Sure, I can take a look at this bug |
|
@adarshsanjeev i see that i messed up the merging before, now ive reset the branch to here and merged it properly. Shall i push that? |
…ith-hllsketch-in-realtime
6ca88c6 to
7ffe8b5
Compare
|
This pull request has been marked as stale due to 60 days of inactivity. |
|
This pull request/issue has been closed due to lack of activity. If you think that |
Fixed issue when msq queries throw ClassCastException with
"includeSegmentSource": "REALTIME"and supervisor running.After some investigation was found that selector's getObject() for real-time segments was returning a byte array representation of HllSketch but still was trying to convert it to a byte[]. While HllSketchHolderObjectStrategy expects to have HllSketchHolder instance in toBytes() leading to the ClassCastException.
This PR has: