Optimiser la formation de paymentFlat pour que ça ne crash pas

[alice-telescoop]

Le constat est que le cli payment-flat init plante même avec un container XL, par maque de mémoire vive. Ça plante pendant la création des entités dans toPaymentFlatChorusEntities. Je mets les logs plus bas
Cette méthode forme autant de paymentFlatEntity que de lignes chorus en mode non agrégé pour pouvoir faire cette agrégation. Je pense que c'est le stockage de tout ça qui est trop gros. Il faut donc que l'agrégation soit faite ou bien au fur et à mesure ou bien carrément en base de données. Je jette quelques idées.

---

Pour ne pas avoir toutes les données en mémoire en même temps (ce qui est nécessaire pour régler le pb), il faut que l'agrégation soit faite en base. Soit

1. avant la mise en lien avec dataBretagne (et on inverse donc l'ordre d'exécution)
2. soit après (mais donc il faudrait écrire en base les données complétées non agrégées)

Je constate que l'agrégation se fait à partir d'un id agrégé d'arguments qui proviennent uniquement de chorus (et non de dataBretagne). Si cela est vrai, on doit pouvoir faire l'agrégation en base. Quasiment tous les éléments sont maintenus à l'identique, sauf le montant qui est sommé. Je pense donc qu'on peut faire l'option 1. ci-dessus, qui me semble plus simple.

1. le chorusPort peut sortir un aggregate qui corresponde à l'agrégation nécessaire, et qui serait lue par lot pour y ajouter les éléments de dataBretagne et écrire dans paymentFlat dans la foulée
2. on pourrait se limiter à sortir les donées chorus triées par uniqueId, mais il faut déjà un aggregate pour créer cet identifiant donc à mon sens autant faire l'option ci-dessus.

[alice-telescoop]

<--- Last few GCs --->

[37:0x72e3a80] 392585 ms: Mark-sweep 1019.3 (1042.8) -> 1017.4 (1042.8) MB, 847.8 / 0.0 ms (average mu = 0.114, current mu = 0.031) allocation failure; scavenge might not succeed
[37:0x72e3a80] 393435 ms: Mark-sweep 1019.5 (1042.8) -> 1017.5 (1043.1) MB, 846.3 / 0.0 ms (average mu = 0.062, current mu = 0.005) allocation failure; scavenge might not succeed

<--- JS stacktrace --->

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
1: 0xb83f50 node::Abort() [node]
2: 0xa94834 [node]
3: 0xd647c0 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
4: 0xd64b67 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
5: 0xf42265 [node]
6: 0xf43168 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [node]
7: 0xf53673 [node]
8: 0xf544e8 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
9: 0xf2ee4e v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
10: 0xf30217 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
11: 0xf10760 v8::internal::Factory::AllocateRaw(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) [node]
12: 0xf07d2c v8::internal::FactoryBasev8::internal::Factory::AllocateRawArray(int, v8::internal::AllocationType) [node]
13: 0xf07ea5 v8::internal::FactoryBasev8::internal::Factory::NewFixedArrayWithFiller(v8::internal::Handlev8::internal::Map, int, v8::internal::Handlev8::internal::Oddball, v8::internal::AllocationType) [node]
14: 0x114a43f v8::internal::FastGetOwnValuesOrEntries(v8::internal::Isolate*, v8::internal::Handlev8::internal::JSReceiver, bool, v8::internal::Handlev8::internal::FixedArray) [node]
15: 0x114aa38 v8::internal::GetOwnValuesOrEntries(v8::internal::Isolate, v8::internal::Handlev8::internal::JSReceiver, v8::internal::PropertyFilter, bool, bool) [node]
16: 0x12e0af7 v8::internal::Runtime_ObjectValues(int, unsigned long*, v8::internal::Isolate*) [node]
17: 0x17035b9 [node]
Aborted (core dumped)

[mxmeunier]

Le dev devra faire des allers-retours sur la PREPROD et rend le ticket plus long à réalisé

1. essayer par exercice (faire une nouvelle méthode cli qui récupère les exercices possible et fait du byExercice)
2. faire une agrégation des lignes chorus et itérer sur ce résultat puis l'enregistré par batch avec l'insertion des données dataBretagne => attention aux doublons si ça plante (ou alors on s'assure de tout supprimer avant d'exécuter init)
3. faire une itération par champ composant l'identifiant (comme l'EJ) pour faire des petites batch et s'assurer qu'on a toutes les lignes à agréger ensemble