[ https://issues.apache.org/jira/browse/JAMES-2997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093509#comment-17093509 ]
Benoit Tellier commented on JAMES-2997: --------------------------------------- https://github.com/linagora/james-project/pull/3335 contributes strong typing for Attachment content type Discovered bug: - TextExtractor doing comparison on the full field instead of mimeType - Wrong charset management in text extractors > 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-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org