[SUPPORT] Querying Hudi tables with Spark+Velox(C++), ObjectSizeCalculator.getObjectSize hangs causing about a 50-second delay in queries
- Dominant language
- Java
- Stars
- 6.2k
- Forks
- 2.5k
- Avg merge
- 2d 8h
- Merged PRs (30d)
- 111
Description
**Describe the problem you faced**
When I query Hudi tables using Spark+Velox, I encounter a timeout error when it gets to ObjectSizeCalculator.getObjectSize.
The main issue occurs after enabling Velox, during the initialization of ServiceabilityAgentSupport and the execution of the needSudo method, where an error prevents obtaining the result, causing a hang for 50 seconds followed by a timeout error, and then a default singleton is returned. This problem occurs on my Spark cluster's driver and each executor the first time they start up. However, when Velox is disabled, this method usually completes in just over a second.
Although this problem can currently be circumvented by setting jol.skipHotspotSAAttach=true, its occurrence is unexpected. Is anyone aware of the cause of this problem? Could there be an incompatibility issue between the method called and Velox? Is a rollback necessary?
WARNING INFORMATION:
```
# WARNING: Unable to attach Serviceability Agent. You can try again with escalated privileges. Two options: a) use -Djol.tryWithSudo=true to try with sudo; b) echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope
24/01/26 11:40:04 INFO HoodieBackedTableMetadata: Opened 1 metadata log files (dataset instant=20240103095853633, metadata instant=20231215140043588001) in 48126 ms
```
**To Reproduce**
Steps to reproduce the behavior:
1. query Hudi tables using Spark+Velox
**Expected behavior**
A clear and concise description of what you expected to happen.
**Environment Description**
* Hudi version : 0.14.0
* Spark version : 3.3
* Running on Docker? (yes/no) : yes
**Additional context**
Add any other context about the problem here.
**Stacktrace**
```
java.lang.Object.wait(Native Method)
java.lang.Object.wait(Object.java:502)
java.lang.UNIXProcess.waitFor(UNIXProcess.java:395)
org.apache.hudi.org.openjdk.jol.vm.sa.ServiceabilityAgentSupport.callAgent(ServiceabilityAgentSupport.java:190)
org.apache.hudi.org.openjdk.jol.vm.sa.ServiceabilityAgentSupport.needSudo(ServiceabilityAgentSupport.java:109)
org.apache.hudi.org.openjdk.jol.vm.sa.ServiceabilityAgentSupport.(ServiceabilityAgentSupport.java:88)
org.apache.hudi.org.openjdk.jol.vm.sa.ServiceabilityAgentSupport.instance(ServiceabilityAgentSupport.java:77)
org.apache.hudi.org.openjdk.jol.vm.VM.current(VM.java:77)
org.apache.hudi.org.openjdk.jol.info.GraphWalker.walk(GraphWalker.java:97)
org.apache.hudi.org.openjdk.jol.info.GraphLayout.parseInstance(GraphLayout.java:54)
org.apache.hudi.common.util.ObjectSizeCalculator.getObjectSize(ObjectSizeCalculator.java:57)
```
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reproducing the delay with Spark 3.3, Hudi 0.14.0, and Velox, then trace ObjectSizeCalculator.getObjectSize through GraphLayout, VM, and ServiceabilityAgentSupport in the stack trace. Compare behavior with jol.skipHotspotSAAttach=true; done means identifying the cause of the 50-second wait and defining a verified fix or documented compatibility limitation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp, docker, java, spark
- Domain
- data-engineering, performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100