• Exemple de back-pressure avec Vert.x

    back pressure valve

    Dans le billet de début juin, je montrais les difficultés à charger un gros fichier en mémoire en utilisant les APIs de Vert.x. En conclusion, ces APIs n’étaient pas faite pour ça, mais pour gérer des flux.

    Aujourd’hui, je vais me placer dans un cas de flux. Plutôt que de charger le fichier, je vais voir comment Vert.x peut le servir en téléchargement. Et pour voir l’efficacité, on va essayer de faire ça avec le mimimum de mémoire, de l’ordre de quelques Mo.

  • Lecture de gros fichier avec Vert.x

    File

    Dans mon billet de mai, je racontais l’histoire de la OutOfMemmoryError avec la direct buffer memory, en utilisant la méthode Files.readAllBytes(path) et un pool de threads. En réalité, le problème ne s’était pas posé en utilisant directement ces éléments, mais indirectement dans Vert.x.

    Dans ce billet-ci, je vais reprendre l’histoire en la replaçant dans son contexte original : du Vert.x et des gros fichiers.

    Vert.x n’est pas fait pour ça mais on y arrive quand même.

  • Lecture de fichier et performances

    File

    Dans le billet précédent, j’ai présenté plusieurs façons de lire des gros fichiers en Java, en me focalisant sur la consommation en mémoire pour buffers directs. J’y ai ajouté quelques vagues considérations de performances.

    Je présente ici quelques données chiffrées sur ces comparaisons de performances.

  • Lecture de fichier et consommation mémoire

    File

    C’est l’histoire d’une erreur de mémoire comme il en existe tant dans les applications Java. Sa particularité c’est qu’il suffit d’augmenter la heap pour la résoudre alors que l’erreur ne concerne pas la heap.

    OK, j’arrête les mystères. Le besoin est de lire des fichiers assez gros (200 à 500 Mo) de façon séquentielle. La heap de 1 Go est assez grosse pour charger tout le fichier en mémoire et travailler dessus. Malgré la marge de manoeuvre, on a des erreurs OOME qui ressemblent à ça:

    java.lang.OutOfMemoryError: Direct buffer memory

    Le message associé nous indique que ce n’est pas un problème de heap et pourtant en doublant la heap, l’erreur ne se produit plus.

    D’où vient le problème ? Et comment peut-on le résoudre ?

  • Back-pressure avec RxJava

    back pressure valve

    Avec RxJava 1, on manipulait des observables et des observers. Puis est arrivé RxJava 2 (en 2016) avec une grande nouveauté, le support de la back-pressure. Pour ça, la classe Flowable est apparue, avec un aspect très proche de Observable, mais un comportement très différent.

    Une fois qu’on a dit ça, il va falloir qu’on voit ce que signifie back-pressure et qu’on le mette en lumière avec un exemple simple. Et c’est justement à cause de la simplicité excessive de mon exemple que j’ai dû slalomer dans quelques subtilités de RxJava.

Abonnement via RSS