[jira] [Created] (JAMES-3269) MessageFastView should be using moving averages
Lan Khuat created JAMES-3269: Summary: MessageFastView should be using moving averages Key: JAMES-3269 URL: https://issues.apache.org/jira/browse/JAMES-3269 Project: James Server Issue Type: Improvement Reporter: Lan Khuat MessageFastViewProjection health check currently relies on total count since last reboot and thus, does not correctly reflect latest server state, especially for a long running server instance. *DOD:* Replace the current metric with a counter keeping track of events that happen within a 5 minutes time window. -- 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
Gradle migration proposal - take 1
Hello, This is a request for early feedback on the Gradle migration. I'm assuming we are going to adopt Gradle since IMO it does deliver on it's promises and opens us for new possibilities. TLDR: The migration will be ready for review in ~2 days; when it's done, please try it out and give feedback. If no blockers, let's push for Gradle build by default in the next 2 weeks. == Long version As we discussed, I started working on a Gradle migration proposal that I hope we make sooner rather than later. The main goals of this migrations is to improve the developer experience and also the change-build-test feedback loop. See https://issues.apache.org/jira/browse/JAMES-3260 and related issues. Please go through my observations and the code changes, build it locally and provide feedback. The work is IN PROGRESS but does most of what it promises. To try out, checkout the branch and build with ./gradlew build . == Current status I worked on a git branch and created a PR https://github.com/apache/james-project/pull/217 and https://github.com/apache/james-project/tree/JAMES-3260-gradle-poc . I followed the migration guide at https://docs.gradle.org/current/userguide/migrating_from_maven.html : - I ran the maven build scan - took 2h+ to build james and it failed at the end - Ran gradle init and I got the first gradle structure - Started the build - check - update loop to make sure the whole project builds. At the moment I'm able to build most of the components - up to webadmin and guice application modules. I believe in 1-2 days we will be able to build all of James-project with Gradle. == We need You to help out ! I believe that Gradle delivers on it's promises to make the build faster. I would like for you to help out and test it. The migration will require quite some work and collaboration. Bellow there are some things we need, please add others, choose one and work on it (we need to sync, so let everyone know) - We need to make sure the current developers are onboard - please do your part and check the build locally. - We need a checklist to verify the builds produce similar output / the same arifacts - We need to make sure we can release with Gradle - OFBiz does that - we can ask there (some others projects also do) - We need to add ASF copyright headers to all gradle files (Intellij has a nice feature. Also Search and replace can be of good help). - We need documentation for developers on how to work with the new builds system Let's make this happen. Please share your feedback, -- Eugen Stan +40720 898 747 / netdava.com <> signature.asc Description: OpenPGP digital signature
[jira] [Created] (JAMES-3268) Reactivate MOVE and ACL capabilities in docker image
Rémi Kowalski created JAMES-3268: Summary: Reactivate MOVE and ACL capabilities in docker image Key: JAMES-3268 URL: https://issues.apache.org/jira/browse/JAMES-3268 Project: James Server Issue Type: Bug Components: docker Affects Versions: 3.5.0 Reporter: Rémi Kowalski On the docker image IMAP configuration, the `MOVE` and `ACL` capabilities are disabled. This could have an impact on integration testing as the imap client will use `COPY` + `EXPUNGED` in place of `MOVE` which could lead to Quota limit when the quota limit is reached and we try to move a mail to the trash. -- 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
[jira] [Commented] (JAMES-3267) ImapRequestFrameDecoder.decode should not force the temporary file deletion
[
https://issues.apache.org/jira/browse/JAMES-3267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17142968#comment-17142968
]
Gautier DI FOLCO commented on JAMES-3267:
-
This PR contributed to it: [https://github.com/linagora/james-project/pull/3469]
> ImapRequestFrameDecoder.decode should not force the temporary file deletion
> ---
>
> Key: JAMES-3267
> URL: https://issues.apache.org/jira/browse/JAMES-3267
> Project: James Server
> Issue Type: Improvement
> Components: IMAPServer
>Reporter: Gautier DI FOLCO
>Priority: Trivial
>
> ImapRequestFrameDecoder.decode relies on a temporary file to operate.
> At the end, it forcefully tries to delete it, which fails when the file does
> not exists anymore:
>
> {code:java}
> org.apache.james.mailbox.exception.MailboxException: Unable to parse
> message
> at
> org.apache.james.mailbox.store.StoreMessageManager.appendMessage(StoreMessageManager.java:344)
> at
> org.apache.james.imap.processor.AppendProcessor.appendToMailbox(AppendProcessor.java:130)
> at
> org.apache.james.imap.processor.AppendProcessor.processRequest(AppendProcessor.java:75)
> at
> org.apache.james.imap.processor.AppendProcessor.processRequest(AppendProcessor.java:55)
> at
> org.apache.james.imap.processor.AbstractMailboxProcessor.doProcess(AbstractMailboxProcessor.java:100)
> at
> org.apache.james.imap.processor.AbstractMailboxProcessor.doProcess(AbstractMailboxProcessor.java:77)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:58)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imapserver.netty.ImapChannelUpstreamHandler.messageReceived(ImapChannelUpstreamHandler.java:198)
> at
> org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
> at
>
[jira] [Created] (JAMES-3267) ImapRequestFrameDecoder.decode should not force the temporary file deletion
Gautier DI FOLCO created JAMES-3267:
---
Summary: ImapRequestFrameDecoder.decode should not force the
temporary file deletion
Key: JAMES-3267
URL: https://issues.apache.org/jira/browse/JAMES-3267
Project: James Server
Issue Type: Improvement
Components: IMAPServer
Reporter: Gautier DI FOLCO
ImapRequestFrameDecoder.decode relies on a temporary file to operate.
At the end, it forcefully tries to delete it, which fails when the file does
not exists anymore:
{code:java}
org.apache.james.mailbox.exception.MailboxException: Unable to parse
message
at
org.apache.james.mailbox.store.StoreMessageManager.appendMessage(StoreMessageManager.java:344)
at
org.apache.james.imap.processor.AppendProcessor.appendToMailbox(AppendProcessor.java:130)
at
org.apache.james.imap.processor.AppendProcessor.processRequest(AppendProcessor.java:75)
at
org.apache.james.imap.processor.AppendProcessor.processRequest(AppendProcessor.java:55)
at
org.apache.james.imap.processor.AbstractMailboxProcessor.doProcess(AbstractMailboxProcessor.java:100)
at
org.apache.james.imap.processor.AbstractMailboxProcessor.doProcess(AbstractMailboxProcessor.java:77)
at
org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:58)
at
org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
at
org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
at
org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
at
org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
at
org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
at
org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
at
org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
at
org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
at
org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
at
org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
at
org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
at
org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
at
org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
at
org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
at
org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
at
org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
at
org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
at
org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
at
org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
at
org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
at
org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
at
org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
at
org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
at
org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
at
org.apache.james.imapserver.netty.ImapChannelUpstreamHandler.messageReceived(ImapChannelUpstreamHandler.java:198)
at
org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
at
org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
at
org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
at
org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296)
at
org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:462)
at
[jira] [Closed] (JAMES-3247) Do not throw in StoreMessageManager.appendMessage close
[
https://issues.apache.org/jira/browse/JAMES-3247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gautier DI FOLCO closed JAMES-3247.
---
Resolution: Not A Bug
It was not the right issue.
> Do not throw in StoreMessageManager.appendMessage close
> ---
>
> Key: JAMES-3247
> URL: https://issues.apache.org/jira/browse/JAMES-3247
> Project: James Server
> Issue Type: Improvement
>Reporter: Gautier DI FOLCO
>Priority: Trivial
>
> From time to time, StoreMessageManager.appendMessage throws when the closes
> happen, when the temporary file disappears:
>
> {code:java}
> org.apache.james.mailbox.exception.MailboxException: Unable to parse message
> at
> org.apache.james.mailbox.store.StoreMessageManager.appendMessage(StoreMessageManager.java:344)
> at
> org.apache.james.imap.processor.AppendProcessor.appendToMailbox(AppendProcessor.java:130)
> at
> org.apache.james.imap.processor.AppendProcessor.processRequest(AppendProcessor.java:75)
> at
> org.apache.james.imap.processor.AppendProcessor.processRequest(AppendProcessor.java:55)
> at
> org.apache.james.imap.processor.AbstractMailboxProcessor.doProcess(AbstractMailboxProcessor.java:100)
> at
> org.apache.james.imap.processor.AbstractMailboxProcessor.doProcess(AbstractMailboxProcessor.java:77)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:58)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imap.processor.base.AbstractChainedProcessor.process(AbstractChainedProcessor.java:67)
> at
> org.apache.james.imapserver.netty.ImapChannelUpstreamHandler.messageReceived(ImapChannelUpstreamHandler.java:198)
> at
> org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70)
> at
> org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)
> at
> org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791)
> at
>
[jira] [Created] (JAMES-3266) Distributed James: make ElasticSearch indexing optional?
Benoit Tellier created JAMES-3266:
-
Summary: Distributed James: make ElasticSearch indexing optional?
Key: JAMES-3266
URL: https://issues.apache.org/jira/browse/JAMES-3266
Project: James Server
Issue Type: New Feature
Components: elasticsearch, guice
Affects Versions: master
Reporter: Benoit Tellier
Fix For: 3.6.0
{code:java}
Raphaël Ouazana-Sustowski Thu, 11 Jun 2020 09:02:24 -0700
Hi,
Here is a proposal to make ElasticSearch optional in our distributed
product/flavor/server.
Comments are welcome.
## Why?
Some people have expressed the need of using a distributed James without
ElasticSearch:
- in some comment here: https://issues.apache.org/jira/browse/JAMES-3086
- one of our customers plan to deploy a distributed James server for serving
POP3 encrypted emails. This deployment does not rely on searching features.
However as part of current Distributed James server he is forced to rely on
ElasticSearch email indexing.
This results in wasted resources as maintaining an ElasticSearch cluster to
keep up with the volume is expensive. Maintaining an ElasticSearch cluster when
not needed is costly at several levels:
- cost of infrastructure to deploy it
- cost of people having to maintain it
- performance cost on James to unnecessarily index data
## How ?
Scanning search is a search implementation that is running on top of any
mailbox implementation, even distributed ones and does not require to index
data.
Scanning Search is tested both at the component level (unit test) but also
passes IMAP (MPT) tests on top of Cassandra implementation, as well as JMAP
memory tests, thus delivers correct results. Of course it does not support full
text search.
We should allow Distributed James to optionally rely on scanning search instead
of ElasticSearch.
- Scanning search should be advised for deployments rarely searching data
- ElasticSearch should be advised when search is frequent or requires high
performance
We could use module choosing [1] to choose between scanning search and
ElasticSearch.
To be noted that scanning search introduces no other dependencies as it is part
of mailbox-store thus causes no risk of library clashes.
To be noted also that metric collection and log collection using ElasticSearch
is unaffected.
## Alternative
The alternative would be to build a different product/flavor/server than the
distributed one, where the only difference with the distributed one is that
indexing will rely on scanning instead of ElasticSearch.
The maintenance cost of such a product/flavor/server is higher than of a
configuration option (Docker images to release, time and energy to run
integration tests on it).
Such a product/flavor is hard to brand because even if it answers a need, it is
not so far of the distributed one, and does not answer needs that are very far
from it neither.
The advantage is that is would allow to more fine tune this solution to answer
to the exact needs.
## Work in Progress
See pull request: https://github.com/linagora/james-project/pull/3425
Regards,
Raphaël.
[1]
https://github.com/apache/james-project/blob/master/src/adr/0036-against-use-of-conditional-statements-in-guice-modules.md
{code}
Mailing list thread:
https://www.mail-archive.com/server-dev@james.apache.org/msg66319.html
PR: https://github.com/linagora/james-project/pull/3425
--
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
Re: Distributed James: make ElasticSearch indexing optional?
Hi, I've looking again at this thread and I see strong arguments over a technical issue. The proposal in question is whether we should add a configuration switch to OPT-IN/OUT of a large, useful dependency. This is a technical decision that has implications mostly for users and less for developers - since the code seems simple to follow. @Matthieu: To me it appears like this: - It means that users can do it via a configuration switch, if they chose too. - It does not mean it should be disabled by default ( it's for another discussion) - The configuration code looks easy to maintain Let's leave what users will want or not out of the discussion since we can't speak for them anyway. We can only say what we would do as users or what the users we worked with already did. Looking at the code size and changes for this feature and the benefits of having the option to disable search (faster initial setup, solution for niche use-cases ) I think the PR can be merged. La 23.06.2020 11:38, Matthieu Baechler a scris: > Hi, > > On Wed, 2020-06-17 at 17:53 +0200, Raphaël Ouazana-Sustowski wrote: >> Hi Matthieu, >> >> I don't see much new arguments in your last answer. > It's weird because I think I didn't really repeat what I said > previously. > >> I can answer your >> questions one by one, but I would like to go forward. > It's your freedom of course, it's a bit sad that such a debate don't > end in a consensus but it happens. > >> Would it make a consensus for you if we work on merging the current >> PR, >> with always the option to revert it and go to a product if needed? > No, that's not what I call consensus as it doesn't take into account my > opinion. > >> Or do you prefer that we ask for a vote? > Feel free to do it or not. I won't stand in your way. > > Cheers, > > -- Matthieu Baechler > > > - > To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org > For additional commands, e-mail: server-dev-h...@james.apache.org > -- Eugen Stan +40720 898 747 / netdava.com <> signature.asc Description: OpenPGP digital signature
Re: Distributed James: make ElasticSearch indexing optional?
Hi, On Wed, 2020-06-17 at 17:53 +0200, Raphaël Ouazana-Sustowski wrote: > Hi Matthieu, > > I don't see much new arguments in your last answer. It's weird because I think I didn't really repeat what I said previously. > I can answer your > questions one by one, but I would like to go forward. It's your freedom of course, it's a bit sad that such a debate don't end in a consensus but it happens. > Would it make a consensus for you if we work on merging the current > PR, > with always the option to revert it and go to a product if needed? No, that's not what I call consensus as it doesn't take into account my opinion. > Or do you prefer that we ask for a vote? Feel free to do it or not. I won't stand in your way. Cheers, -- Matthieu Baechler - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-3265) Investigate Slow IMAP SELECT (26 minutes +)
[
https://issues.apache.org/jira/browse/JAMES-3265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17142682#comment-17142682
]
Benoit Tellier commented on JAMES-3265:
---
https://github.com/linagora/james-project/pull/3468 is a proposed fix
> Investigate Slow IMAP SELECT (26 minutes +)
> ---
>
> Key: JAMES-3265
> URL: https://issues.apache.org/jira/browse/JAMES-3265
> Project: James Server
> Issue Type: Task
> Components: cassandra, IMAPServer
>Affects Versions: master
>Reporter: Benoit Tellier
>Priority: Major
> Labels: perf
> Fix For: 3.6.0
>
> Attachments: Capture_d_écran_de_2020-06-22_11-42-01.png,
> Capture_d_écran_de_2020-06-22_11-48-28.png
>
>
> Using glowroot APM on Linagora run instances, I noticed some select commands
> takes around 20 minutes.
> A performance review shows thousands of MODSEQ updates undermines the
> performance.
> {code:java}
> Transaction type: IMAP
> Transaction name: IMAP processor :
> org.apache.james.imap.processor.SelectProcessor
> Start: 2020-06-22 2:28:04.433 am (+07:00)
> Duration: 1,618,718.3 milliseconds
> {code}
> I noticed a high allocation of new ModSeq (28.000 instead of 1) due to uid
> set disjonction.
> I believe a solution would be to implement a new MessageMapper method:
> Mono removeRecentFlags(Mailbox mbox);
> That would enable some Cassandra query optimizations...
> # DOD
> - unlock significant performance improvments for such queries (x100)
> Attached you will find the query stats and flame graph backing up the
> analysis.
--
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
[jira] [Created] (JAMES-3265) Investigate Slow IMAP SELECT (26 minutes +)
Benoit Tellier created JAMES-3265:
-
Summary: Investigate Slow IMAP SELECT (26 minutes +)
Key: JAMES-3265
URL: https://issues.apache.org/jira/browse/JAMES-3265
Project: James Server
Issue Type: Task
Components: cassandra, IMAPServer
Affects Versions: master
Reporter: Benoit Tellier
Fix For: 3.6.0
Attachments: Capture_d_écran_de_2020-06-22_11-42-01.png,
Capture_d_écran_de_2020-06-22_11-48-28.png
Using glowroot APM on Linagora run instances, I noticed some select commands
takes around 20 minutes.
A performance review shows thousands of MODSEQ updates undermines the
performance.
{code:java}
Transaction type: IMAP
Transaction name: IMAP processor :
org.apache.james.imap.processor.SelectProcessor
Start: 2020-06-22 2:28:04.433 am (+07:00)
Duration: 1,618,718.3 milliseconds
{code}
I noticed a high allocation of new ModSeq (28.000 instead of 1) due to uid set
disjonction.
I believe a solution would be to implement a new MessageMapper method:
Mono removeRecentFlags(Mailbox mbox);
That would enable some Cassandra query optimizations...
# DOD
- unlock significant performance improvments for such queries (x100)
Attached you will find the query stats and flame graph backing up the analysis.
--
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
[jira] [Created] (JAMES-3264) MAILBOX details are read 3 times upon indexing
Nguyễn Việt Đức created JAMES-3264: -- Summary: MAILBOX details are read 3 times upon indexing Key: JAMES-3264 URL: https://issues.apache.org/jira/browse/JAMES-3264 Project: James Server Issue Type: Improvement Reporter: Nguyễn Việt Đức !https://ci.linagora.com/linagora/lgs/openpaas/james/uploads/e66e59cdfb7bf1e09e103a71ebad7b89/Capture_d_%C3%A9cran_de_2020-06-22_12-05-54.png! We can notice 3 mailbox reads for each indexed message This is too much, we should reduce this to a single mailbox read. *Definition of done* * Indexing a mail do the same count (or less) of mailbox reads (compared to messages reads) -- 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
