Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Francois Armand
    @fanf
    tu peux aussi essayer zio-zmx pour faire des fiber dumps (mais peut-être que ca ne marcherait pas à cause du deadlock)
    @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)
            }
        }
    Francois 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
    Francois 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 :/
    Francois 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
    Francois 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
    Francois 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
    Francois 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
    Francois 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)
    Francois 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:
    Francois 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.
    Loïc Descotte
    @loicdescotte
    désolé on m'avait envoyé un jeu de données foireux , j'efface ma question
    lmeyer
    @LeonardMeyer
    Bonjour les scalaistes français. Je viens vers vous car j'ai pas eu de réponse via les canaux officiels. Quelqu'un a déjà fait des requêtes via Oauth2 en Scala via HTTP4s ? Mon besoin est juste côté client, et non serveur, que via API, pas de web. Je ne trouve rien de très concret en Scala pour faire ça. Actuellement j'ai juste un endpoint qui me renvoie le token via des credentials. Donc je pourrais sans doute faire une requête au startup pour récupérer un token et le mettre dans toutes mes requêtes. Mais je me demande s'il y a pas un truc intégré
    Francois Armand
    @fanf
    @LeonardMeyer désolé, jamais fait ce genre de choses
    lmeyer
    @LeonardMeyer
    Oui je vois que personne a jamais fait sur genre de chose sur tout gitter ahah
    rimeh bennjima
    @rimeh-bennjima

    Bonjour,

    object webSocketSpec extends MessagingSpec with RestCall {
    override def is: SpecStructure = "Specification to check the messaging".title ^ sequential ^
        s2"""
              UserCreatedMessage    ${e1.pendingUntilFixed}
          """
    
    
    override def userId: UserId = PostUser("user1")
    override def token: String = postSession("admin")
    
    
    def e1 = todo
    
    }
    
    
    abstract class MessagingSpec  extends TestKit(ActorSystem("messagingTests"))
        with ImplicitSender
        with SpecificationLike
        with ClassLogging {
    
      def userId: UserId
      def token: String
    
    ....
    }

    lorsque j'exécute la spécification, je constate que le contenu de l'ID utilisateur et du token est nul, car l'exécution des deux méthodes postUser et postSession n'est pas encore terminée.
    y a-t-il des propositions pour attendre la fin des deux méthodes et prendre les bonnes valeurs ?