From 151a5f9c602aab0ecfee903e66d7e1caa9bad860 Mon Sep 17 00:00:00 2001 From: Martijn Dirkse Date: Mon, 8 Jul 2024 15:41:12 +0200 Subject: [PATCH] Fix typo --- docs/source/advancedDevelopment/muchData/muchData.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/source/advancedDevelopment/muchData/muchData.rst b/docs/source/advancedDevelopment/muchData/muchData.rst index 553d5939..443501ad 100644 --- a/docs/source/advancedDevelopment/muchData/muchData.rst +++ b/docs/source/advancedDevelopment/muchData/muchData.rst @@ -22,4 +22,4 @@ Files stored on disk are stored in ``${java.io.tmpdir}/${instance.name}/temp-mes The Frank!Framework in general `streams` messages flowing through a pipeline. This means that the Frank!Framework only holds in memory the bytes it is currently working with, not entire messages. This helps the Frank!Framework to process large messages without getting out of memory, but there is a caveat. The caveat is related to XSLT processing. When XSLT version 2.0 or version 3.0 is being applied (attribute ``xsltVersion=2`` or ``xsltVersion=3``), then XSLT processor Saxon is used. This XSLT processor does not support streaming. This means that if some message is transformed using an XSLT transformation and if XSLT version 2.0 or 3.0 is used for this, then the entire message has to be stored in memory. This can cause an out of memory exception for large messages. -This issue can be fixed by using `xsltVersion=1`. In that case, XSLT processor Xalan is used. Xalan does implement streaming and hence large messages can be processed without memory issues. The price to pay is that XSLT 1.0 is less feature-rich than version 2.0 and version 3.0, making it harder to code the intended XSLT transformation. Most XSLT processing senders and pipes use Saxon by default. The exception is the ``ForEachChildElementPipe``. That pipe uses Xalan by default. This exception has been made by WeAreFrank! because the ``ForEachChildElementPipe`` is meant to iterate over large messages. +This issue can be fixed by using ``xsltVersion=1``. In that case, XSLT processor Xalan is used. Xalan does implement streaming and hence large messages can be processed without memory issues. The price to pay is that XSLT 1.0 is less feature-rich than version 2.0 and version 3.0, making it harder to code the intended XSLT transformation. Most XSLT processing senders and pipes use Saxon by default. The exception is the ``ForEachChildElementPipe``. That pipe uses Xalan by default. This exception has been made by WeAreFrank! because the ``ForEachChildElementPipe`` is meant to iterate over large messages.