2006/2/3, Jochen Wiedmann <[EMAIL PROTECTED]>:
> Henri Gomez wrote:
>
> > Well I'm more usefull in IO area. Also I will be more than happy to see if
> > we could 'arrange' the spec and avoid the use of byte[] in execute call
> > returns since I'm using huge XML-RPC replies in my day jobs and it hurt
> > badly the JVM. IO will be more interesting in such case
>
> Don't know, what exactly you are thinking of, but one of the primary
> targets of the streaming branch was being able to get rid of byte[].
>
> However, while we are talking about, there might be a different topic,
> which came up just yesterday in a discussion here:
>
> We do have an application which deals with large strings and large
> base64 streams (aka byte arrays). It is not desirable to put them into
> memory. A nice extension (which I am going to realize at some point
> anyways, if you won't do it) would be like the following:
>
> - Create configurable options maxByteArraySize and maxCharArraySize
> with default values 0 and a configurable option tmpArrayDir with
> default System.getProperty("java.io.tmpDir").
> - Change the readers for byte[] and String (ByteArrayParser and ...
> heck, the latter one might be tricky, because String may sit directly
> within the value tag, so it's the RecursiveTypeParserImpl itself)
> as follows: If the created object is within the configured size,
> then the byte array or String is returned, as usual. However, if
> that is not the case, then a temporary file is created and a
> reference to the file is returned. The reference should have
> streaming accessors, of course.
Using filesystem as cache could be a good idea but it may
introduce performance penalties. BTW, it could be proposed as
extension to those who want minimal memory footprint.
> - Create a utility class, that recursively scans an array,
> collection, or map for such references and replaces them with
> the byte arrays or strings. (Not all software locations are
> prepared for such things.)
bytes arrays or strings of Java Objects to be stored in the file cache
? And at a latter time transform them into XML stream ? Did the two
passes won't introduce again some penalties ?
> How about that? Other ideas quite welcome. This is just my proposal how
> I'd try to attack the problem.
Well the implementation must be seens to see how it works and if it
didn't slow down to much the server.
