Paul,
I would expect that onError should be called with an ISE if any of the
limits set by MultipartConfig are exceeded, just as the existing getParts()
method throws.
Some of these (eg overall size) might be able to be passed before any parts
are delivered, but other (individual part size) may come mid stream.
Note that parts are often processed out of order, so the async API in this
case is just to prevent blocking during IO and is not there to allow stream
processing of arbitrarily large content. The limits that apply to
getParts still apply, so all parts must be able to exist in memory and/or
filesystem at once.
cheers
On 8 January 2016 at 03:36, Paul Benedict <pbenedict_at_apache.org> wrote:
> What is the specified behavior if many parts are processed but fails
> midway because the request exceeds a byte threshold? Is onError() expected
> to be called like any other error? I am thinking about a clean-up mechanism
> so the listener has a chance to undo any changes it was accumulating.
>
> Cheers,
> Paul
>
> On Wed, Jan 6, 2016 at 11:55 PM, Greg Wilkins <gregw_at_webtide.com> wrote:
>
>>
>> All,
>>
>> To further this discussion, here are two more fully formed interfaces for
>> what I think might be suitable for parameters and multipart, with a bit of
>> javadoc
>>
>> Note that I'm not proposing we change the Part API - which has a blocking
>> aspect via it's input stream. However, I propose that a Part is only
>> returned to the listener when it is fully read - eitehr into memory or into
>> a file (as per the current configuration).
>>
>> thoughts?
>>
>> --
>> Greg Wilkins <gregw@webtide.com> CTO http://webtide.com
>>
>
>
--
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com