threaddump ? (
kill -3 pidjvm)
J'ai réussi à faire péter le serveur avec 10 connexions simultanée en attaquant une API qui ne fait pas de requête dans la base de données
Donc mauvaise hypothèse de ma part
Mais c'est encore plus inquiétant :/
eut être que j'ai foiré le config
Pour démarrer le serveur je fais ceci :
def start_server(config: AppConfig)
(implicit runtime: Runtime[ZConfig[AppConfig]]): ZIO[AppLayer, StartServerError, Nothing] = {
httpAppR.flatMap { httpApp =>
BlazeServerBuilder[Task](runtime.platform.executor.asEC)
.bindHttp(config.webAppPort, "0.0.0.0")
.withHttpApp(
Logger.httpApp[Task](logHeaders = true, logBody = false)(httpApp.orNotFound)
)
.resource
.toManaged
.useForever
.mapError(StartServerError)
}
}
enfin, je dirais que l'executor, ca ne devrait pas être
runtime.platform.executor mais le blocking, vu le genre de truc que fait blaze (attendre des requetes, faire des io, etc)
en tout cas, si tu as un moyen de reproduire simplement, c'est chouette, tu vas pouvoir cibler le pb beaucoup plus simplement. Par ex, faire une API qui ne fait que
sleep un moment, et voir si ca pete, et si c'est le cas, c'est forcément dans la config du serveur http
Mais du coup tout cas c'est sensé etre non bloquant non ?
Le truc bizarre c'est :
L'appli bloque, mais quand on lance une req on n'a pas de réponse mais on a un log de blaze qui nous dit qu'il accepte l'a connexion entrante
ok, donc ce que j'imagine avec ces infos:
- blaze a un threadpool (ou fiber, je ne sais pas trop comment ca se passe avec cats-effet) pour l'acceptation des réponses, qui ne fait que "j'accepte, je délegue à une autre pool pour le traitement". Ce qui est une bonne technique.
- ce premier pool fait son job. S'il ne peut pas déléguer, il bloque (ce qui n'est pas trop bien, il devrait peut être faire une erreur en cas de saturation, mais bon)
- donc le problème est sûrement sur le second pool, qui semble être un pool non blocant (ce qui est raisonnable par défaut), mais qui bloque s'il y a des IO de faites
ton api sans doobie qui bloque, elle fait d'autres IO/trucs bloquants ?
J'ai mis un EC ZIO bloquant à la place et je n'ai plus le bug :/
On s'y retrouvera :D
Oui y a des logs tu as raison
le top du top, ca serait d'avoir un projet minimal qui montre que ca bloque, comme ca les gens ont les versions/le code/etc. Parfois, c'est un truc qui n'a l'air de n'avoir rien à voir, et pour un autre c'est évident (ou c'est le truc qui met la puce à l'oreille). Ca m'arrive tout le temps. Et parfois (souvent), en essayant de faire le projet de démo, je comprends le problème
Merci pour ton aide @fanf c'est très sympa
Et que si le pool de thread qui gère l'éxécution des requêtes est borné, ça risque de rapidement partir en cacahuète
Mon collègue a fait un mini-projet pour montrer qu'un EC borné conduit à des dead lock avec Http4s https://git.performance.immo/oss/test-zio-http4s-blocking
j'ai vu un peu scala reflection mais je crois que c'est plus pour créer dynamiquement des instance de class déja défini dans le code
merci @fanf je me disais aussi que je devais passer par java car scala peux exécuter du java nativement j'ai trouver ça comme debut de solution : https://stackoverflow.com/questions/14741338/java-reflection-running-a-external-jar-and-referring-to-its-classes
si tu a des ressource sur ça en java ça serai avec plaisir ( même des mots clé :D)
si tu a des ressource sur ça en java ça serai avec plaisir ( même des mots clé :D)
@iDumbo_gitlab nous on utilise https://github.com/ronmamo/reflections pour pouvoir charger des plugins au lancement de notre appli, ca marche bien (ie: les jar sont déjà dans le classpath, mais on charge les implémentations au boot)
je ne sais pas si ca correspond à tes besoins
OSGi, c'est bien, c'est juste que son design space est compliqué et qu'en vrai, peu de gens veulent/ont réellement besoin de cette complexitée - mais le coût en API à supporté est souvent rédibitoire (ie: ca ne semble pas facile d'avoir un sous-ensemble "mais en fait, je n'ai pas besoin du rechargement à chaud" qui simplifie vraiment les API)
bref. C'est comme ça qu'on se retrouve à redémarrer nos applis.
