Hi Kim
The following example script is used for illustrative purposes. In two places
the VFS payload is copied. Into a property, and in the JSScript. In full
scenario the property value is used later in a chain of Web service but
needs to be stored temporily, as the request will be replaced by
request/responce of next web service. The file drop will be replaced by FTP.
Issue is we get 'big' files by FTP that we need to submit to a Web Service.
The Web Service is OK with the large data, but will Synapse cope.
Issues:
1) What if the payload gets large;
What is large (5MB, 20 MB ?) and
What problems will this mean for this code e.g. Memory etc.
Synapse, especially the NIO transport, is written to never exhaust with
OOM with large payloads - i.e. it does not bite more than it can chew.
But this does not mean your configuration is safe - for example, reading
any payload into a String is bad.. even if its 1MB.. and I see your
script mediator doing that - which is worse.. You could maybe use a
simple class/POJO mediator to save or process large payload etc.
2) The JSScript could be replaced with a Java Mediator and use a
stream to better copy the VFS text element {data}. However still means
it would
copy whole string into memory.
No, in Java, you could get the payload written safely into a file
stream, without reading into memory.
3) Storing the payload temporarily, e.g. alternative to property. How big
can Property be ?
This will depend on how much memory you allocate and how many of these
messages are processed concurrently. Ideally, properties should not take
much space
4) using the XPath to get the payload into property.
Not sure I understand.. again, if you are dealing with large payloads,
you would need to be careful. Can you state how large your files are,
whats the frequency of processing, and the number of files per each
batch etc, and the type of file - XML, Text, CSV etc and what type of
operations you want to take on this data..
One thing I always ask users is to state their business problem or the
requirement, and ask us for the best technical solution. Once we
understand your problem, we could look into alternatives and weigh pros
and cons to help you decide
cheers
asankha
--
Asankha C. Perera
http://adroitlogic.org
http://esbmagic.blogspot.com