You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Sebb (JIRA)" <ji...@apache.org> on 2014/04/10 02:16:16 UTC

[jira] [Updated] (NET-535) IMAP FETCH can overflow reply buffer; provide for partial responses

     [ https://issues.apache.org/jira/browse/NET-535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sebb updated NET-535:
---------------------

    Affects Version/s: 3.3

> 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)