Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    François Armand
    @fanf
    je ne sais pas si ca suffirait à mettre en évidence ton problème :/
    François Armand
    @fanf
    @ubourdon j'ai ajouté un exemple avec le pattern Layer
    @ugobourdon
    @ubourdon
    yep je vais essayer de regarder. Bon ça a l'air d'être plus compliqué que ça. Car j'ai lancé mon app en debug, et j'ai toujours des logs d'hikari qui tourne, des log de blaze (j'utilise htt4s pour mmon app) mais pourtant plus aucune connexion entrante surmon appli
    François Armand
    @fanf
    oui, donc c'est clairement un deadlock sur le pool default-async. Il doit y avoir quelque part un effect bloquant qui n'est pas mis dans un blocker
    threaddump ? (kill -3 pidjvm)
    François Armand
    @fanf
    tu peux aussi essayer zio-zmx pour faire des fiber dumps (mais peut-être que ca ne marcherait pas à cause du deadlock)
    (https://zio.github.io/zio-zmx/docs/overview/overview_diagnostics)
    @ugobourdon
    @ubourdon
    @fanf Bon j'ai confirmation, ce n'est pas doobie qui déconne
    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 :/
    @ugobourdon
    @ubourdon
    Donc apriori un soucis avec htt4s/blaze
    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)
        }
    }
    François Armand
    @fanf
    je ne vais pas pouvoir t'aider là dessus, je ne connais pas du tout.
    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
    @ugobourdon
    @ubourdon
    Ouais mais c'est ça qui est chelou, le EC passé à Blaze est pour traiter l'éxécution des requêtes (en gros du code des API)
    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
    François Armand
    @fanf
    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 ?
    @ugobourdon
    @ubourdon
    non non elle ne fait aucun IO
    J'ai mis un EC ZIO bloquant à la place et je n'ai plus le bug :/
    François Armand
    @fanf
    que des calculs ou des trucs CPU? Pas de log, de fichiers, etc ?
    @ugobourdon
    @ubourdon
    Bon bah j'ai gagné un voyage sur le discord ZIO
    On s'y retrouvera :D
    Oui y a des logs tu as raison
    François Armand
    @fanf
    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
    @ugobourdon
    @ubourdon
    Oui je vais faire ça, un projet minimal pour reproduire le bug, mantenant que j'ai réussi à savoir où était le bug
    @ugobourdon
    @ubourdon
    Je publierais ça sur le discord ZIO
    Merci pour ton aide @fanf c'est très sympa
    François Armand
    @fanf
    ca fait partie des choses normales pour avoir un ecosytème fonctionnel ;) Et je suis sûr que ca me servira un jour :)
    @ugobourdon
    @ubourdon
    Bon bah pour donner du feedback sur ce forum, le résulat est que Http4s crée un future par requête entrante :/
    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
    @ugobourdon
    @ubourdon
    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
    François Armand
    @fanf
    :thumbsup:
    Jonathan Winandy
    @ahoy-jon
    c'est bon à savoir dans les faits, merci pour l'info!
    idir
    @iDumbo_gitlab
    slt tous le mode je voudrai savoir s'il exist un moyen d'impoter une lib compiler (un .jar ) durant l'exécution d'un prg scala ? ( et de l'utiliser bien sûr )
    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
    François Armand
    @fanf
    @iDumbo_gitlab oui, mais il n'y a rien de spécifique à scala ici, ca utilise les mêmes infrastructure que java, en regardant comment faire pour java tu devrais pouvoir
    idir
    @iDumbo_gitlab
    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)
    François Armand
    @fanf
    @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
    @ugobourdon
    @ubourdon
    Sinon tu as OSGi => ok je sors
    idir
    @iDumbo_gitlab
    @fanf carrément :thumbsup:
    François Armand
    @fanf
    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.