[
https://issues.apache.org/jira/browse/NET-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13967257#comment-13967257
]
Sebb commented on NET-535:
--------------------------
URL: http://svn.apache.org/r1586800
Log:
NET-535 IMAP FETCH can overflow reply buffer; provide for partial responses
Add TRUE_CHUNK_LISTENER
Modified:
commons/proper/net/trunk/src/main/java/org/apache/commons/net/imap/IMAP.java
> IMAP FETCH can overflow reply buffer; provide for partial responses
> -------------------------------------------------------------------
>
> Key: NET-535
> URL: https://issues.apache.org/jira/browse/NET-535
> Project: Commons Net
> Issue Type: New Feature
> Affects Versions: 3.3
> Reporter: Sebb
> Fix For: 3.4
>
>
> A single IMAP request can return huge amounts of data (e.g. FETCH)
> An application gets access to this data by calling one of the methods
> getReplyString() or getReplyStrings() only after the request has completed.
> As well as delaying the response to the application, this may cause the
> application to run out of memory.
> IMAP replies which return large amounts of data use untagged multi-line
> responses followed by a tagged status line.
> It would be useful if applications could register to receive such responses
> in chunks as they arrived. The array list could then be cleared once the
> chunk had been processed. e.g. the listener could return a boolean to say
> whether to clear the array.
> If the array was cleared, this would obviously affect any listeners as these
> are currently only called at the end of the response.
> In this case, listeners could be called with a new status of PARTIAL so they
> could distinguish the different case if necessary.
> The chunk listener could be passed the IMAP instance; this would give access
> to the getString[s]() methods. This would be more flexible than passing a
> String or String[] directly.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
