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.
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é
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 ?
