[jira] [Commented] (JAMES-2997) hasAttachment SHOULD be metadata read level

["Benoit Tellier (Jira)" <se...@james.apache.org>]

    [ https://issues.apache.org/jira/browse/JAMES-2997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17098642#comment-17098642 ] 

Benoit Tellier commented on JAMES-2997:
---------------------------------------

https://github.com/linagora/james-project/pull/3335 is merged and did contribute attachment strong typing

> hasAttachment SHOULD be metadata read level
> -------------------------------------------
>
>                 Key: JAMES-2997
>                 URL: https://issues.apache.org/jira/browse/JAMES-2997
>             Project: James Server
>          Issue Type: Improvement
>            Reporter: René Cordier
>            Priority: Major
>             Fix For: 3.6.0
>
>
> The description is well detailed in this mail : https://www.mail-archive.com/server-dev@james.apache.org/msg63511.html
> We are working on JMAP, and EMail::hasAttachments metadata is listed as
> a fast property.
> However to retrieve it today, we need to do a full message read in order
> to load attachment (as JMAP hasAttachment do not take inlined
> attachments into account and mailbox property do).
> Also, while inspecting the code, MessageResult::getLoadedAttachments is
> never used with attachment bytes. This means that given an email with a
> 10 MB attachment, upon GetMessages call with full profile, we are going
> to read the full eml (10 MB) then load attachment bytes (10 MB) while
> the attachment could have not been loaded in the first place. In our
> little example we read 20MB while only 10 MB could have been necessary.
> This attachment over-reading results in both performance and cost issue
> on the object storage - what is the topic me, René and Duc are currently
> working on.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org