I've noticed that large enough (>40MB but it could start lower) spark event log files aren't being parsed successfully by the spark history server:
```
# ~40MB
24/01/05 08:18:00 INFO FsHistoryProvider: Parsing hdfs://analytics-hadoop/var/log/spark/application_1695896957545_622877 for listing data...
# ~40MB
24/01/05 08:18:00 INFO FsHistoryProvider: Parsing hdfs://analytics-hadoop/var/log/spark/application_1695896957545_622893.lz4 for listing data...
# ~40KB
24/01/05 08:18:01 INFO FsHistoryProvider: Parsing hdfs://analytics-hadoop/var/log/spark/application_1695896957545_622725 for listing data...
24/01/05 08:18:01 INFO FsHistoryProvider: Finished parsing hdfs://analytics-hadoop/var/log/spark/application_1695896957545_622893.lz4
# 40MB
24/01/05 08:18:01 INFO FsHistoryProvider: Parsing hdfs://analytics-hadoop/var/log/spark/application_1695896957545_622678.lz4 for listing data...
```
For the "large" files, we don't see the `Finished parsing` log, meaning that we're stuck somewhere in https://github.com/apache/spark/blob/fbbcf9434ac070dd4ced4fb9efe32899c6db12a9/core/src/main/scala/org/apache/spark/deploy/history/FsHistoryProvider.scala#L788-L835
We see the following HDFS audit logs on an-master1001.eqiad.wmnet:
So this is not a permission issue. As we have a way to regenerate these "big" files by executing a Spark job from Jupyter, I decided to delete all these files from HDFS, to see what the system looks like when it has nothing to do. To do this, I ran `kill -3 <spark history server PID>` on the worker node the container was scheduled on.
```
24/01/05 08:27:53 INFO HistoryServer: Bound HistoryServer to 0.0.0.0, and started at http://spark-history-analytics-hadoop-57774468c-sn6vl:18080
2024-01-05 08:32:44
Full thread dump OpenJDK 64-Bit Server VM (11.0.21+9-post-Debian-1deb11u1 mixed mode, sharing):
garbage-first heap total 8388608K, used 75734K [0x0000000600000000, 0x0000000800000000)
region size 4096K, 19 young (77824K), 6 survivors (24576K)
Metaspace used 39853K, capacity 40854K, committed 41216K, reserved 1085440K
class space used 5315K, capacity 5794K, committed 5888K, reserved 1048576K
```
We see the following thread:
```
"IPC Client (137659163) connection to an-master1001.eqiad.wmnet/10.64.5.26:8020 from spark/spark-history.svc.eqiad.wmnet@WIKIMEDIA" #28 daemon prio=5 os_prio=0 cpu=71.32ms elapsed=280.46s tid=0x00007f123005a800 nid=0x48 in Object.wait() [0x00007f12477d2000]
```
I initially thought that thread was blocking in the case of the "large" files, but it seems that it's a long running connection, not a data transfer thread.
I had already taken another thread dump of the spark history server (at a time where 2 large files were in HDFS), and wrote a small python script that nicely formats the thread names and their associate state:
-IPC Client (137659163) connection to an-master1001.eqiad.wmnet/10.64.5.26:8020 from spark/spark-history.svc.eqiad.wmnet@WIKIMEDIA TIMED_WAITING (on object monitor)
+IPC Client (1196716338) connection to an-master1001.eqiad.wmnet/10.64.5.26:8020 from spark/spark-history.svc.eqiad.wmnet@WIKIMEDIA TIMED_WAITING (on object monitor)
We see that 2 `log-replay-executor` threads are in WAITING state:
```diff
+log-replay-executor-0 WAITING (parking)
+log-replay-executor-1 WAITING (parking)
```
I'm not sure whether they are blocked on receiving the file, or if the receiving of the file failed, and the threads are waiting for something else to do.