Несколько биндингов slf4j в одном класспасе

Какие-то зависимости тащат альтернативные биндинги

что такое биндинг?

Slf4j - это api, который позволяет с помощью биндинга логгировать в орган системы логгирования

Например в log4j или logback

спасибо, а можно пожалуйста  ссылку где это можно починить?

У меня сейчас нет, но надо посмотреть дерево зависимостей и удалить всё лишнее, связанное с slf4j

спасибо!

там прям в варнинге есть ссылка

slf4j это фасад (интерфейс) над различными фреймворками логирования. то есть ты пишешь «в интерфейс», а он под капотом сам находит его реализацию и использует её. ну как сам, в помнике надо указать конкретную реализацию типа slf4j-log4j2. когда какие-то зависимости транзитивно приносят с собой реализации slf4j, он не может отдуплить, какую ему взять и берет первую попавшуюся, но пишет такой варнинг, типа чувак вообще-то их тут несколько шоб ты знал. он никому не мешает, но если бесит, то экслюдами надо отовсюду выпиливать slf4j.

если ворнинг я бы не парился, а тут же  error )

Так и есть: недетерминированное поведение должно быть ошибкой

Ааа у нас не тот логгер мы все умрём)

Ну скажем так: не тот логгер - не то и не туда логгируется - странное поведение будет неудобно искать, ошибки в логах не будет, а вероятно и самих логов не будет

Ох! Хотел про логирование спросить, а его тут уже обсуждают 🤩 памагити, привет всем)

Запускаю джобу в ярне в кластерном режиме, пытаюсь отдебажить сабж и разобраться, почему логирование настраивается не так как нужно, знакомлюсь с кодом попутно. Спарк 3.0.1

- В launchcintainer.sh вижу в конце  java .... org.apache.spark.deploy.yarn.ApplicationMaster. Окей, видим там
- https://github.com/apache/spark/tree/2b147c4cd50da32fe2b4167f97c8142102a0510d/resource-managers/yarn/src/main/scala/org/apache/spark/deploy/yarn/ApplicationMaster.scala#L841
- прям первой строкой SignalUtils.registerLogger(log)
- смотрим в Logging.log()  https://github.com/apache/spark/tree/2b147c4cd50da32fe2b4167f97c8142102a0510d/core/src/main/scala/org/apache/spark/internal/Logging.scala#L49
- два вызова, можно там прям посмотреть, ничего сложного, попадаем в initializeLogging
- https://github.com/apache/spark/tree/2b147c4cd50da32fe2b4167f97c8142102a0510d/core/src/main/scala/org/apache/spark/internal/Logging.scala#L124
- там проверка на то, что Logging.isLog4j12() == true, у меня это так, потому что в stderr контейнера вижу
- SLF4J: Found binding in [jar:file:/home/yarn/local-dirs/filecache/13/spark-3.0.1-bin-hadoop3.2.jar/slf4j-log4j12-1.7.30.jar!/org/slf4j/impl/StaticLoggerBinder.class] + еще сам дополнительно чекнул из самой джобы

Я к чему -- видно, что

https://github.com/apache/spark/tree/2b147c4cd50da32fe2b4167f97c8142102a0510d/core/src/main/scala/org/apache/spark/internal/Logging.scala#L137

должно вывестить в stderr
- "Using Spark's default log4j profile: $defaultLogProps"
- "либо Spark was unable to load $defaultLogProps"

Я ни того, ни другого не вижу, следовательно log4j12Initialized = true.

Вопрос -- в какой момент эта фигня настраивается?

ребят

а вы знали что spark.read.parquet("path") может внезапно начать читать партииции вида 20200720 внезапно как int

хотя все предыдущие версии читали как инт

spark.sql.sources.partitionColumnTypeInference.enabled

я знаю что бай дизайн тру)