[jira] [Commented] (JAMES-3140) Provide a CachedDumbBlobStore
[
https://issues.apache.org/jira/browse/JAMES-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17096280#comment-17096280
]
Matthieu Baechler commented on JAMES-3140:
--
https://github.com/linagora/james-project/pull/3320 contributes to this
> Provide a CachedDumbBlobStore
> -
>
> Key: JAMES-3140
> URL: https://issues.apache.org/jira/browse/JAMES-3140
> Project: James Server
> Issue Type: Improvement
>Reporter: René Cordier
>Priority: Major
>
> {{This DumbBlobStore wraps another dumbBlobStore and compose it with a
> Cache.}}
> Blobs are cached upon writes
> Only blobs of the default bucket are cached.
> Upon reads:
> * the cache is queried
> * if the cache is empty then load it's value from the blobStore
> * and populate the cache
> Provide guice bindings in james-distributed guice product:
> * configure CassandraBlobStoreCache
> * enable caching if {{blobStore.cache.enabled=true}}
--
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] [Closed] (JAMES-3153) Upgrade reactor to make use of retryWhen and RetrySpec
[ https://issues.apache.org/jira/browse/JAMES-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Baechler closed JAMES-3153. Fix Version/s: 3.6.0 Resolution: Fixed > Upgrade reactor to make use of retryWhen and RetrySpec > -- > > Key: JAMES-3153 > URL: https://issues.apache.org/jira/browse/JAMES-3153 > Project: James Server > Issue Type: Improvement >Reporter: Matthieu Baechler >Priority: Major > Fix For: 3.6.0 > > > Latest reactor version include some new features regarding retry backoff (see > https://github.com/reactor/reactor-core/pull/1979 ) > As we were limited by the previous API, we did copy some code from reactor to > workaround the limitations. > Now that they implement a RetrySpec, we should be able to get rid of this > code duplication and rely on their well-tested feature. > h2. Definition of done: > * All reactive code should still work as before > * The code should use RetryWhen with RetrySpec instead of previous solutions -- 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] [Updated] (JAMES-3153) Upgrade reactor to make use of retryWhen and RetrySpec
[ https://issues.apache.org/jira/browse/JAMES-3153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Baechler updated JAMES-3153: - Description: Latest reactor version include some new features regarding retry backoff (see https://github.com/reactor/reactor-core/pull/1979 ) As we were limited by the previous API, we did copy some code from reactor to workaround the limitations. Now that they implement a RetrySpec, we should be able to get rid of this code duplication and rely on their well-tested feature. h2. Definition of done: * All reactive code should still work as before * The code should use RetryWhen with RetrySpec instead of previous solutions was: Latest reactor version include some new features regarding retry backoff (see https://github.com/reactor/reactor-core/pull/1979 ) As we were limited by the previous API, we did copy some code from reactor to workaround the limitations. Now that they implement a RetrySpec, we should be able to get rid of this code duplication and rely on their well-tested feature. > Upgrade reactor to make use of retryWhen and RetrySpec > -- > > Key: JAMES-3153 > URL: https://issues.apache.org/jira/browse/JAMES-3153 > Project: James Server > Issue Type: Improvement >Reporter: Matthieu Baechler >Priority: Major > > Latest reactor version include some new features regarding retry backoff (see > https://github.com/reactor/reactor-core/pull/1979 ) > As we were limited by the previous API, we did copy some code from reactor to > workaround the limitations. > Now that they implement a RetrySpec, we should be able to get rid of this > code duplication and rely on their well-tested feature. > h2. Definition of done: > * All reactive code should still work as before > * The code should use RetryWhen with RetrySpec instead of previous solutions -- 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] [Closed] (JAMES-3145) Make it poosible to log metrics
[ https://issues.apache.org/jira/browse/JAMES-3145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Baechler closed JAMES-3145. Fix Version/s: 3.6.0 Resolution: Fixed Merged > Make it poosible to log metrics > --- > > Key: JAMES-3145 > URL: https://issues.apache.org/jira/browse/JAMES-3145 > Project: James Server > Issue Type: Improvement > Components: Metrics >Reporter: Matthieu Baechler >Priority: Major > Fix For: 3.6.0 > > > James is currently able to publish metrics in an elasticsearch database. > Once configured correctly, it allows to have nice dashboard giving insights > about a lot of processes happening in the server. > However, output to elasticsearch is not always what users want. > We should be able to publish these metrics to various systems. > This issue is about adding the capability to publish metrics to the log > framework and that we can enable with some logger configuration. -- 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-3153) Upgrade reactor to make use of retryWhen and RetrySpec
Matthieu Baechler created JAMES-3153: Summary: Upgrade reactor to make use of retryWhen and RetrySpec Key: JAMES-3153 URL: https://issues.apache.org/jira/browse/JAMES-3153 Project: James Server Issue Type: Improvement Reporter: Matthieu Baechler Latest reactor version include some new features regarding retry backoff (see https://github.com/reactor/reactor-core/pull/1979 ) As we were limited by the previous API, we did copy some code from reactor to workaround the limitations. Now that they implement a RetrySpec, we should be able to get rid of this code duplication and rely on their well-tested feature. -- 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-3145) Make it poosible to log metrics
Matthieu Baechler created JAMES-3145: Summary: Make it poosible to log metrics Key: JAMES-3145 URL: https://issues.apache.org/jira/browse/JAMES-3145 Project: James Server Issue Type: Improvement Components: Metrics Reporter: Matthieu Baechler James is currently able to publish metrics in an elasticsearch database. Once configured correctly, it allows to have nice dashboard giving insights about a lot of processes happening in the server. However, output to elasticsearch is not always what users want. We should be able to publish these metrics to various systems. This issue is about adding the capability to publish metrics to the log framework and that we can enable with some logger configuration. -- 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-2208) upgrade netty to netty-all
[ https://issues.apache.org/jira/browse/JAMES-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17079142#comment-17079142 ] Matthieu Baechler commented on JAMES-2208: -- I read the report and the 4 vulnerabilities are related to HTTP. We don't use netty 3 for HTTP so we are safe. Still, if you want to contribute the upgrade to Netty 4, we can offer some help. > upgrade netty to netty-all > -- > > Key: JAMES-2208 > URL: https://issues.apache.org/jira/browse/JAMES-2208 > Project: James Server > Issue Type: Improvement > Components: James Core >Affects Versions: 3.0.0 >Reporter: Randymo >Priority: Major > Attachments: dependency-check-report.html > > > James is currently using the netty dependency > > io.netty > netty > 3.10.6.Final > > I think we should upgrade to the newer artifact > > io.netty > netty-all > 4.1.16.Final > -- 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-3140) Provide a CachedDumbBlobStore
[
https://issues.apache.org/jira/browse/JAMES-3140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17077068#comment-17077068
]
Matthieu Baechler commented on JAMES-3140:
--
The real question is "does it happen 1% of the time or 90%"? Because we can
very well have typical sequence of events that trigger this bad behavior.
> Provide a CachedDumbBlobStore
> -
>
> Key: JAMES-3140
> URL: https://issues.apache.org/jira/browse/JAMES-3140
> Project: James Server
> Issue Type: Improvement
>Reporter: René Cordier
>Priority: Major
>
> {{This DumbBlobStore wraps another dumbBlobStore and compose it with a
> Cache.}}
> Blobs are cached upon writes
> Only blobs of the default bucket are cached.
> Upon reads:
> * the cache is queried
> * if the cache is empty then load it's value from the blobStore
> * and populate the cache
> Provide guice bindings in james-distributed guice product:
> * configure CassandraBlobStoreCache
> * enable caching if {{blobStore.cache.enabled=true}}
--
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-3127) Cassandra migrations should not depend on Guice
[ https://issues.apache.org/jira/browse/JAMES-3127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17070807#comment-17070807 ] Matthieu Baechler commented on JAMES-3127: -- > Then how do you know the number associated with each migration, and enforce > there is no conflicts? You have a SchemaVersion for each module (one for mailbox, one for data) > Also, if you attach migration tasks to the Module, then the dependency part > of it might be complicated IMO I don't see why > Cassandra migrations should not depend on Guice > --- > > Key: JAMES-3127 > URL: https://issues.apache.org/jira/browse/JAMES-3127 > Project: James Server > Issue Type: Improvement > Components: cassandra, guice >Reporter: Matthieu Baechler >Priority: Major > > For now, Cassandra migrations are associated to schema versions in a guice > module, preventing the reuse of the versions in other parts of the code. > We don't really need guice to build a Map so we should move this code in the > non-guice module and stop duplicating schema version information in the > codebase. -- 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-3127) Cassandra migrations should not depend on Guice
[ https://issues.apache.org/jira/browse/JAMES-3127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17070782#comment-17070782 ] Matthieu Baechler commented on JAMES-3127: -- We recently added a migration of data-cassandra module so there's no longer a central place to put these migrations. We should probably have a dedicated set of migration for each cassandra module. > Cassandra migrations should not depend on Guice > --- > > Key: JAMES-3127 > URL: https://issues.apache.org/jira/browse/JAMES-3127 > Project: James Server > Issue Type: Improvement > Components: cassandra, guice >Reporter: Matthieu Baechler >Priority: Major > > For now, Cassandra migrations are associated to schema versions in a guice > module, preventing the reuse of the versions in other parts of the code. > We don't really need guice to build a Map so we should move this code in the > non-guice module and stop duplicating schema version information in the > codebase. -- 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-3127) Cassandra migrations should not depend on Guice
Matthieu Baechler created JAMES-3127: Summary: Cassandra migrations should not depend on Guice Key: JAMES-3127 URL: https://issues.apache.org/jira/browse/JAMES-3127 Project: James Server Issue Type: Improvement Components: cassandra, guice Reporter: Matthieu Baechler For now, Cassandra migrations are associated to schema versions in a guice module, preventing the reuse of the versions in other parts of the code. We don't really need guice to build a Map so we should move this code in the non-guice module and stop duplicating schema version information in the codebase. -- 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-3123) Manage properly Cassandra queries concurrency
Matthieu Baechler created JAMES-3123: Summary: Manage properly Cassandra queries concurrency Key: JAMES-3123 URL: https://issues.apache.org/jira/browse/JAMES-3123 Project: James Server Issue Type: Improvement Components: cassandra Reporter: Matthieu Baechler We have several parameters regarding Cassandra usage in James: * cassandra driver queue size * cassandra driver threadpool size * reactor concurrency tuning We frequently fine tune these parameters based on metrics feedback: for example https://github.com/linagora/james-project/pull/3218 tries to limit the impact of counters computation on the user queries However, this "try, measure, fix" strategy could be handle by engineering a better execution framework. I suggest this one: * use two specific reactor workqueues for running cassandra queries, one for interactive queries and another one for background queries * ensure we don't schedule more queries than the Cassandra queue size can handle by using back-pressure * send queries to the right workqueue depending on the expected execution characteristics -- 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] [Closed] (JAMES-3009) Convert event sourcing modules to scala
[ https://issues.apache.org/jira/browse/JAMES-3009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Baechler closed JAMES-3009. Resolution: Fixed merged > Convert event sourcing modules to scala > --- > > Key: JAMES-3009 > URL: https://issues.apache.org/jira/browse/JAMES-3009 > Project: James Server > Issue Type: Improvement >Reporter: Rémi Kowalski >Priority: Major > > This PR aims to convert to scala the event sourcing modules : > - `event-sourcing-core` > - `event-sourcing-pojo` > - `event-store-api` > - `event-store-cassandra` > This will help to standardize the `event-*` modules as `event-store-memory` > is already written in scala. > The use of scala in those modules will avoid interoperability concerns with > the mains consumers of those modules > which are already written in scala : see the distributed task manager. > In the long run this will allow to have a stronger typing in those parts of > the code and to have a much less verbose code. -- 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-3076) Systematically use 'concat' upon denormalization scheduling
[ https://issues.apache.org/jira/browse/JAMES-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17046353#comment-17046353 ] Matthieu Baechler commented on JAMES-3076: -- Ok, the thing missing from this ticket is that we are talking about Flux.concat(Mono, Mono) and Flux.merge(Mono, Mono). I understand that we want things to be sequential in some cases. Thanks Just on thing: Flux.merge doesn't subscribe eagerly, it subscribes concurrently. > Systematically use 'concat' upon denormalization scheduling > --- > > Key: JAMES-3076 > URL: https://issues.apache.org/jira/browse/JAMES-3076 > Project: James Server > Issue Type: Bug > Components: cassandra, mailbox >Reporter: Benoit Tellier >Assignee: Benoit Tellier >Priority: Major > > This ensures the projection is updated if, and only if, the source of truth > is updated. > This limits inconsistencies. -- 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-3076) Systematically use 'concat' upon denormalization scheduling
[ https://issues.apache.org/jira/browse/JAMES-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17046319#comment-17046319 ] Matthieu Baechler commented on JAMES-3076: -- Can you explain what you mean by 'concat'? Do you mean, when using a Reactor Flux to chain Cassandra writes, we should use concatMap? > Systematically use 'concat' upon denormalization scheduling > --- > > Key: JAMES-3076 > URL: https://issues.apache.org/jira/browse/JAMES-3076 > Project: James Server > Issue Type: Bug > Components: cassandra, mailbox >Reporter: Benoit Tellier >Assignee: Benoit Tellier >Priority: Major > > This ensures the projection is updated if, and only if, the source of truth > is updated. > This limits inconsistencies. -- 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-3071) JwtFilter could require authentication headers on OPTIONS
Matthieu Baechler created JAMES-3071: Summary: JwtFilter could require authentication headers on OPTIONS Key: JAMES-3071 URL: https://issues.apache.org/jira/browse/JAMES-3071 Project: James Server Issue Type: Bug Components: JMAP Reporter: Matthieu Baechler Assignee: Antoine Duprat I found that JwtFilter could wrongly require Authentication headers on OPTIONS requests. It's much likely a mistake that need to be fixed. -- 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-3070) RabbitMQ MailQueue should not share Receiver for several purpose
Matthieu Baechler created JAMES-3070: Summary: RabbitMQ MailQueue should not share Receiver for several purpose Key: JAMES-3070 URL: https://issues.apache.org/jira/browse/JAMES-3070 Project: James Server Issue Type: Improvement Components: Queue Reporter: Matthieu Baechler "spool" MailQueue is used in several places in James code. The usage pattern is quite different in those different places. While trying to control accurately the rate of James dequeue, we found that sharing a single RabbitMQ Receiver can prevent from passing it specific parameters at construction. We should try make James work without the MailQueue sharing for RabbitMQ. -- 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-3067) Allowed From headers recursion
[ https://issues.apache.org/jira/browse/JAMES-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038897#comment-17038897 ] Matthieu Baechler commented on JAMES-3067: -- > How do you maintain an in memory graph in a distributed environment? Well, forget that, I was thinking about event driver projection (not event sourcing) but we may have message ordering issues. If we want a graph database without adding yet another datastore, we can consider https://janusgraph.org/ or https://cayley.io/ But obviously I agree that we have to demonstrate the limitation of a more naive approach first. > Allowed From headers recursion > -- > > Key: JAMES-3067 > URL: https://issues.apache.org/jira/browse/JAMES-3067 > Project: James Server > Issue Type: Improvement > Components: JMAP, SMTPServer >Affects Versions: 3.5.0 >Reporter: Gautier DI FOLCO >Assignee: Antoine Duprat >Priority: Minor > > In order to go further than the JAMES-3032 we need to go a recursion-level > further. > They are two propositions now: > * Have a parameterized number of recursions, doing multiple queries on the > current scheme > * Have a specific projection maintaining all the connected aliases > We should discuss it -- 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-3067) Allowed From headers recursion
[ https://issues.apache.org/jira/browse/JAMES-3067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17038872#comment-17038872 ] Matthieu Baechler commented on JAMES-3067: -- What kind of projection would you want to build? What about having a graph, in memory, to solve that problem? The dataset is supposed to be tiny (is it?) and I guess having a graph allows querying for aliases in a straightforward way > Allowed From headers recursion > -- > > Key: JAMES-3067 > URL: https://issues.apache.org/jira/browse/JAMES-3067 > Project: James Server > Issue Type: Improvement > Components: JMAP, SMTPServer >Affects Versions: 3.5.0 >Reporter: Gautier DI FOLCO >Assignee: Antoine Duprat >Priority: Minor > > In order to go further than the JAMES-3032 we need to go a recursion-level > further. > They are two propositions now: > * Have a parameterized number of recursions, doing multiple queries on the > current scheme > * Have a specific projection maintaining all the connected aliases > We should discuss it -- 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] [Closed] (MAILBOX-396) cassandra mailbox reactor code can be improved
[ https://issues.apache.org/jira/browse/MAILBOX-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Baechler closed MAILBOX-396. - Resolution: Fixed merged > cassandra mailbox reactor code can be improved > -- > > Key: MAILBOX-396 > URL: https://issues.apache.org/jira/browse/MAILBOX-396 > Project: James Mailbox > Issue Type: Improvement > Components: cassandra >Reporter: Matthieu Baechler >Priority: Major > > Reactor code for that module has be written in the first days of its > adoption, so there are some details that can be enhanced. -- 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-3065) API projects should not make use of Reactor types
Matthieu Baechler created JAMES-3065:
Summary: API projects should not make use of Reactor types
Key: JAMES-3065
URL: https://issues.apache.org/jira/browse/JAMES-3065
Project: James Server
Issue Type: Improvement
Reporter: Matthieu Baechler
James being built using Hexagonal Architecture, we usually don't use types from
implementation libraries into our API projects.
We should make sure we use {{Publisher}} instead of {{Mono}}/{{Flux}}
--
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] (MAILBOX-396) cassandra mailbox reactor code can be improved
[ https://issues.apache.org/jira/browse/MAILBOX-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032186#comment-17032186 ] Matthieu Baechler commented on MAILBOX-396: --- See https://github.com/linagora/james-project/pull/3088 : basically wrong scheduler, useless Mono.defer and a repeat without backoff/jitter > cassandra mailbox reactor code can be improved > -- > > Key: MAILBOX-396 > URL: https://issues.apache.org/jira/browse/MAILBOX-396 > Project: James Mailbox > Issue Type: Improvement > Components: cassandra >Reporter: Matthieu Baechler >Priority: Major > > Reactor code for that module has be written in the first days of its > adoption, so there are some details that can be enhanced. -- 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-3041) RabbitMQ dequeue is not using the spooler threadpool
Matthieu Baechler created JAMES-3041: Summary: RabbitMQ dequeue is not using the spooler threadpool Key: JAMES-3041 URL: https://issues.apache.org/jira/browse/JAMES-3041 Project: James Server Issue Type: Bug Components: rabbitmq Reporter: Matthieu Baechler In recent load tests, while trying to understand why object storage backend is making mail dequeuing slow, we found that RabbitMQ Mailqueue implementation is still not using the spool threadpool efficiently. We need RabbitMQ to use that threadpool to maximize concurrency in mail dequeuing. -- 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] (MAILBOX-396) cassandra mailbox reactor code can be improved
Matthieu Baechler created MAILBOX-396: - Summary: cassandra mailbox reactor code can be improved Key: MAILBOX-396 URL: https://issues.apache.org/jira/browse/MAILBOX-396 Project: James Mailbox Issue Type: Improvement Components: cassandra Reporter: Matthieu Baechler Reactor code for that module has be written in the first days of its adoption, so there are some details that can be enhanced. -- 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-3025) ConcurrentTestRunner could support basic distribution patterns
Matthieu Baechler created JAMES-3025:
Summary: ConcurrentTestRunner could support basic distribution
patterns
Key: JAMES-3025
URL: https://issues.apache.org/jira/browse/JAMES-3025
Project: James Server
Issue Type: New Feature
Components: tests
Reporter: Matthieu Baechler
In James, we often want to check that under concurrent workload, our components
behave correctly at a unit level.
For that, we implemented ConcurrentTestRunner that helps dealing with defining
the scenarios we want.
However, in case we want operations to be run in a pseudo-random way while
respecting an even distribution, we write similar code:
{code}
switch (random(numberOfCases)) {
case 0: firstOperation
case 1: secondOperation
case 2: thirdOperation
...
}
{code}
We can enhance this situation a bit by providing a method that make the intent
more obvious:
{code}
randomlyDistributedOperations(
firstOperation,
secondOperation,
thirdOperation
)
{code}
--
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] [Closed] (JAMES-3021) When using a docker network, the container ip is not resolved the right way
[ https://issues.apache.org/jira/browse/JAMES-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Baechler closed JAMES-3021. Resolution: Fixed > When using a docker network, the container ip is not resolved the right way > --- > > Key: JAMES-3021 > URL: https://issues.apache.org/jira/browse/JAMES-3021 > Project: James Server > Issue Type: Bug > Components: tests >Reporter: Matthieu Baechler >Priority: Major > > There are various setup of docker use and it's quite hard to know what IP > should be used in those various situations. > Until now, we found a solution that solved local dev on linux and mac and CI > at the same time. > Now we want to use docker networks to run several containers in a network > during tests and container IP is not resolved to the container IP in this > network (that should be reachable because docker takes care of the routing > table). > Let's try to fix all these cases at once (and maybe upstream the solution to > testcontainers project once done) -- 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-3021) When using a docker network, the container ip is not resolved the right way
Matthieu Baechler created JAMES-3021: Summary: When using a docker network, the container ip is not resolved the right way Key: JAMES-3021 URL: https://issues.apache.org/jira/browse/JAMES-3021 Project: James Server Issue Type: Bug Components: tests Reporter: Matthieu Baechler There are various setup of docker use and it's quite hard to know what IP should be used in those various situations. Until now, we found a solution that solved local dev on linux and mac and CI at the same time. Now we want to use docker networks to run several containers in a network during tests and container IP is not resolved to the container IP in this network (that should be reachable because docker takes care of the routing table). Let's try to fix all these cases at once (and maybe upstream the solution to testcontainers project once done) -- 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-3019) Clear and flexible handling of base directory
[ https://issues.apache.org/jira/browse/JAMES-3019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17008842#comment-17008842 ] Matthieu Baechler commented on JAMES-3019: -- Hi [~sergey-b] and thank you for opening this issue. I worked on this very topic recently and came to the following conclusions: * we should behave like any system daemon, that is : read configuration from /etc, write data to /var, and so on, by default * we should allow to override each directory from the command line * we should provide a real command line "launcher" to implement these options WDYT about this? > Clear and flexible handling of base directory > - > > Key: JAMES-3019 > URL: https://issues.apache.org/jira/browse/JAMES-3019 > Project: James Server > Issue Type: Improvement >Affects Versions: 3.3.0, 3.4.0 >Reporter: Sergey B. >Priority: Major > > We need to have a single value from which all relative urls are evaluated. > Now some urls pointing to the same places are specified by different values. > For example var directory for database storage is presented by the value > '../var/' in database.url property, while the same directory for > MailRepository is designated by 'file://var/. > It's confusing. I suggest we make an improvement. > # There must be a single value of basedir, from which all relative urls are > evaluated. > # Algorithm of evaluation of default basedir value must be documented. > # Default basedir must be at top level of all resources. I. e. there must be > no paths like ../. > # Effective basedir must be logged. > # There must be an opportunity for users to specify their own basedir on > server startup. -- 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-3015) DeploymentValidation tests could be promoted as integration-tests
Matthieu Baechler created JAMES-3015: Summary: DeploymentValidation tests could be promoted as integration-tests Key: JAMES-3015 URL: https://issues.apache.org/jira/browse/JAMES-3015 Project: James Server Issue Type: Bug Components: Build System Reporter: Matthieu Baechler When running the Jenkins pipeline for a build, we create docker images for various James products, deploy them and run some smoke tests on it. As great as it is, it's unfortunate that this requires Jenkins because that means we can't easily run the same tests as a developer. We could create the docker images during the maven process and run the smoke tests during an integration-test phase. -- 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] [Closed] (JAMES-3003) Mailbox event delivery should run synchronous listeners concurrently
[ https://issues.apache.org/jira/browse/JAMES-3003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Baechler closed JAMES-3003. Resolution: Fixed > Mailbox event delivery should run synchronous listeners concurrently > > > Key: JAMES-3003 > URL: https://issues.apache.org/jira/browse/JAMES-3003 > Project: James Server > Issue Type: Bug >Reporter: Matthieu Baechler >Priority: Major > > While profiling mail reception I found that latency is higher than needed > because listeners are run sequentially. > We can actually run them all at the same time for a given event and then wait > for the synchronous listeners to complete. > Let's see if it unlock a better reception rate. -- 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] [Closed] (JAMES-3004) Reactor boundedElastic can lead to deadlocks
[ https://issues.apache.org/jira/browse/JAMES-3004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Baechler closed JAMES-3004. Resolution: Fixed > Reactor boundedElastic can lead to deadlocks > > > Key: JAMES-3004 > URL: https://issues.apache.org/jira/browse/JAMES-3004 > Project: James Server > Issue Type: Bug >Reporter: Matthieu Baechler >Priority: Major > > Reactor authors advise users to prefer boundedElastic Scheduler to elastic > one. > With https://issues.apache.org/jira/browse/JAMES-2899 we decided to use it as > it allows to use less threads. > However, we found that it can lead to deadlocks because of complex starvation > scenarios. > The reality is that James is still calling `block` a lot on Mono/Flux for now > and the advice doesn't stand in the context. > We can either create a boundedElastic for each usages or revert > https://issues.apache.org/jira/browse/JAMES-2899 to workaround that risk > waiting for the day James will be async from end to end. -- 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] [Closed] (JAMES-3001) SpamAssassinContract tests are unstable
[ https://issues.apache.org/jira/browse/JAMES-3001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Baechler closed JAMES-3001. Resolution: Fixed > SpamAssassinContract tests are unstable > --- > > Key: JAMES-3001 > URL: https://issues.apache.org/jira/browse/JAMES-3001 > Project: James Server > Issue Type: Bug > Components: tests >Reporter: Matthieu Baechler >Priority: Major > > SpamAssassinContract are failing very often on the CI. > We should try to fix these issues. -- 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-3004) Reactor boundedElastic can lead to deadlocks
Matthieu Baechler created JAMES-3004: Summary: Reactor boundedElastic can lead to deadlocks Key: JAMES-3004 URL: https://issues.apache.org/jira/browse/JAMES-3004 Project: James Server Issue Type: Bug Reporter: Matthieu Baechler Reactor authors advise users to prefer boundedElastic Scheduler to elastic one. With https://issues.apache.org/jira/browse/JAMES-2899 we decided to use it as it allows to use less threads. However, we found that it can lead to deadlocks because of complex starvation scenarios. The reality is that James is still calling `block` a lot on Mono/Flux for now and the advice doesn't stand in the context. We can either create a boundedElastic for each usages or revert https://issues.apache.org/jira/browse/JAMES-2899 to workaround that risk waiting for the day James will be async from end to end. -- 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-3003) Mailbox event delivery should run synchronous listeners concurrently
Matthieu Baechler created JAMES-3003: Summary: Mailbox event delivery should run synchronous listeners concurrently Key: JAMES-3003 URL: https://issues.apache.org/jira/browse/JAMES-3003 Project: James Server Issue Type: Bug Reporter: Matthieu Baechler While profiling mail reception I found that latency is higher than needed because listeners are run sequentially. We can actually run them all at the same time for a given event and then wait for the synchronous listeners to complete. Let's see if it unlock a better reception rate. -- 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-3001) SpamAssassinContract tests are unstable
Matthieu Baechler created JAMES-3001: Summary: SpamAssassinContract tests are unstable Key: JAMES-3001 URL: https://issues.apache.org/jira/browse/JAMES-3001 Project: James Server Issue Type: Bug Components: tests Reporter: Matthieu Baechler SpamAssassinContract are failing very often on the CI. We should try to fix these issues. -- 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-2999) Reuse SpamAssassin container image between test runs
Matthieu Baechler created JAMES-2999: Summary: Reuse SpamAssassin container image between test runs Key: JAMES-2999 URL: https://issues.apache.org/jira/browse/JAMES-2999 Project: James Server Issue Type: Improvement Components: tests Reporter: Matthieu Baechler I found that we built the spamassassin container image everytime we run a test using this container. It's testcontainer default behavior when a container image is built programmatically. However, it not only deletes the image but any cached layer, preventing reuse and thus speed gains. By the way, as images share the same layers, not deleting the images has almost no space usage. We should disable deleteOnExit option. -- 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-2932) Upgrade runtime to Java 11
Matthieu Baechler created JAMES-2932: Summary: Upgrade runtime to Java 11 Key: JAMES-2932 URL: https://issues.apache.org/jira/browse/JAMES-2932 Project: James Server Issue Type: Task Affects Versions: 3.4.0 Reporter: Matthieu Baechler Java 11 is the only "Long Term Support" java release right now so more and more people will use it exclusively. Now that James builds to java 11 for some time, we should target java 11 as the runtime. -- 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] [Closed] (JAMES-2824) Users should be able to build James with Java 11
[ https://issues.apache.org/jira/browse/JAMES-2824?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Baechler closed JAMES-2824. Resolution: Fixed merged for a month or two > Users should be able to build James with Java 11 > > > Key: JAMES-2824 > URL: https://issues.apache.org/jira/browse/JAMES-2824 > Project: James Server > Issue Type: Improvement >Reporter: Matthieu Baechler >Priority: Major > > Java 11 is the only "Long Term Support" java release right now so more and > more people will use it exclusively. > As a first step towards Java 11 support for James, we should make it possible > to build it with a Java 11 compiler (with a "-release 8" javac flag for now). -- 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-2908) Use cassandra-rabbitmq in webadmin integration tests
Matthieu Baechler created JAMES-2908: Summary: Use cassandra-rabbitmq in webadmin integration tests Key: JAMES-2908 URL: https://issues.apache.org/jira/browse/JAMES-2908 Project: James Server Issue Type: Task Components: tests Reporter: Matthieu Baechler webadmin integration tests are not run on all products because it's a bit slow to run. As cassandra-rabbitmq product is now the preferred distributed implementation, we should make webadmin integration tests to run on this product. -- 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-2907) InVMEventBus and RabbitMQEventBus do not agree on redelivery
Matthieu Baechler created JAMES-2907: Summary: InVMEventBus and RabbitMQEventBus do not agree on redelivery Key: JAMES-2907 URL: https://issues.apache.org/jira/browse/JAMES-2907 Project: James Server Issue Type: Bug Components: eventbus Reporter: Matthieu Baechler InVMEventBus attempts several retries on redeliver while RabbitMQEventBus only try once. -- 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] [Closed] (JAMES-2897) Cassandra Lightweight Transaction requires specific consistency level
[ https://issues.apache.org/jira/browse/JAMES-2897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Baechler closed JAMES-2897. Resolution: Fixed merged > Cassandra Lightweight Transaction requires specific consistency level > - > > Key: JAMES-2897 > URL: https://issues.apache.org/jira/browse/JAMES-2897 > Project: James Server > Issue Type: Bug > Components: cassandra >Reporter: Matthieu Baechler >Priority: Major > > After reading > https://docs.datastax.com/en/ddac/doc/datastax_enterprise/dbInternals/dbIntLtwtTransactions.html > , > https://docs.datastax.com/en/ddaccql/doc/cql/cql_reference/cqlsh_commands/cqlshConsistency.html > and > https://docs.datastax.com/en/ddaccql/doc/cql/cql_reference/cqlsh_commands/cqlshSerialConsistency.html > It looks like we should be more careful about consistency when reading > tables that use LWT. > Basically, to ensure we always read the last value, we must read with SERIAL > consistency. -- 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-2897) Cassandra Lightweight Transaction requires specific consistency level
Matthieu Baechler created JAMES-2897: Summary: Cassandra Lightweight Transaction requires specific consistency level Key: JAMES-2897 URL: https://issues.apache.org/jira/browse/JAMES-2897 Project: James Server Issue Type: Bug Components: cassandra Reporter: Matthieu Baechler After reading https://docs.datastax.com/en/ddac/doc/datastax_enterprise/dbInternals/dbIntLtwtTransactions.html , https://docs.datastax.com/en/ddaccql/doc/cql/cql_reference/cqlsh_commands/cqlshConsistency.html and https://docs.datastax.com/en/ddaccql/doc/cql/cql_reference/cqlsh_commands/cqlshSerialConsistency.html It looks like we should be more careful about consistency when reading tables that use LWT. Basically, to ensure we always read the last value, we must read with SERIAL consistency. -- 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-2877) release process should deploy and generate more artifacts
Matthieu Baechler created JAMES-2877: Summary: release process should deploy and generate more artifacts Key: JAMES-2877 URL: https://issues.apache.org/jira/browse/JAMES-2877 Project: James Server Issue Type: Improvement Components: Build System Affects Versions: 3.4.0 Reporter: Matthieu Baechler During the release of James, we lack some artifacts that in theory should be part of the staging repository before the vote then would go to Apache Dist when releasing. Here is the list of artifacts we should produce and deploy to staging: - the zip file containing all the source code (it's generated but not uploaded) - a zip file for each product we provide with compiled artifacts (spring-app is handled but guice products are not) -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Closed] (JAMES-2873) Distributed Task Manager should keep track of nodes emiting events
[ https://issues.apache.org/jira/browse/JAMES-2873?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Baechler closed JAMES-2873. Resolution: Fixed merged to master > Distributed Task Manager should keep track of nodes emiting events > -- > > Key: JAMES-2873 > URL: https://issues.apache.org/jira/browse/JAMES-2873 > Project: James Server > Issue Type: Task >Reporter: Matthieu Baechler >Priority: Major > > For Created and Started events, it makes sense to keep track of the node name > who emitted the event. > We should modify the Task Manager to handle that. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-2873) Distributed Task Manager should keep track of nodes emiting events
Matthieu Baechler created JAMES-2873: Summary: Distributed Task Manager should keep track of nodes emiting events Key: JAMES-2873 URL: https://issues.apache.org/jira/browse/JAMES-2873 Project: James Server Issue Type: Task Reporter: Matthieu Baechler For Created and Started events, it makes sense to keep track of the node name who emitted the event. We should modify the Task Manager to handle that. -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-2870) Handle 3.4 deprecations and removals
[ https://issues.apache.org/jira/browse/JAMES-2870?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16912341#comment-16912341 ] Matthieu Baechler commented on JAMES-2870: -- The OSGi part has been handle by [~BTellier] here https://issues.apache.org/jira/browse/JAMES-2857 > Handle 3.4 deprecations and removals > > > Key: JAMES-2870 > URL: https://issues.apache.org/jira/browse/JAMES-2870 > Project: James Server > Issue Type: Task >Reporter: Matthieu Baechler >Priority: Major > > After a vote organized on the server-dev mailing list, we decided to mark as > deprecated the following components: > > 1/ zookeeper-seq-provider > > > >This module allows to generate sequence numbers for things like IMAP > >modseq or uid. It has been implemented to fulfil the lack of support > >for this kind of feature in HBase. > > > >Cassandra has the same kind of problems, as most distributed > >database, but we solved the problem without requiring yet another > >complex middleware. > > > >As HBase is no longer part of the codebase and to my knowledge the > >component is not used anywhere else, I propose to mark it as > >deprecated for 3.5 in order to target a removal for 3.6. > > > > 2/ OSGi (karaf) > > > >Maven contains some code and the build configuration to generate > >some OSGi bundles. > > > >I have personnaly no interest in OSGi nor extensive knowledge about > >it and as far as I know, no active developer on the project is able > >and/or willing to maintain that. > > > >I didn't tested any James OSGi thing and I suspect that it has bit > >rot with years to the point it's not usable at all. > > > >I will probably propose some Java Module support in the future to > >gain back some interesting features of OSGi (not exporting every > >classes of a Module, declaring proposed services and required ones, > >etc) but in the meantime I think that we have no interest keeping > >that code around. > > > >I thus propose complete removal before 3.4 release -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-2870) Handle 3.4 deprecations and removals
Matthieu Baechler created JAMES-2870: Summary: Handle 3.4 deprecations and removals Key: JAMES-2870 URL: https://issues.apache.org/jira/browse/JAMES-2870 Project: James Server Issue Type: Task Reporter: Matthieu Baechler After a vote organized on the server-dev mailing list, we decided to mark as deprecated the following components: > 1/ zookeeper-seq-provider > >This module allows to generate sequence numbers for things like IMAP >modseq or uid. It has been implemented to fulfil the lack of support >for this kind of feature in HBase. > >Cassandra has the same kind of problems, as most distributed >database, but we solved the problem without requiring yet another >complex middleware. > >As HBase is no longer part of the codebase and to my knowledge the >component is not used anywhere else, I propose to mark it as >deprecated for 3.5 in order to target a removal for 3.6. > > 2/ OSGi (karaf) > >Maven contains some code and the build configuration to generate >some OSGi bundles. > >I have personnaly no interest in OSGi nor extensive knowledge about >it and as far as I know, no active developer on the project is able >and/or willing to maintain that. > >I didn't tested any James OSGi thing and I suspect that it has bit >rot with years to the point it's not usable at all. > >I will probably propose some Java Module support in the future to >gain back some interesting features of OSGi (not exporting every >classes of a Module, declaring proposed services and required ones, >etc) but in the meantime I think that we have no interest keeping >that code around. > >I thus propose complete removal before 3.4 release -- This message was sent by Atlassian Jira (v8.3.2#803003) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Closed] (JAMES-2848) Tests frequently leaks Cassandra connections
[ https://issues.apache.org/jira/browse/JAMES-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Baechler closed JAMES-2848. Resolution: Fixed https://github.com/linagora/james-project/pull/2546 merged > Tests frequently leaks Cassandra connections > > > Key: JAMES-2848 > URL: https://issues.apache.org/jira/browse/JAMES-2848 > Project: James Server > Issue Type: Bug >Reporter: Matthieu Baechler >Priority: Major > > We frequently have to hunt cassandra connections leaks in the tests when we > realize that builds became longer and more unstable. > It's unfortunate to have such a long feedback loop when it would be possible > to detect leak as soon as they are introduced in the codebase. > We should try to enhance these leaks detections. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Closed] (JAMES-2849) JPA tests don't always clean the database between tests
[ https://issues.apache.org/jira/browse/JAMES-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Baechler closed JAMES-2849. Resolution: Fixed merged > JPA tests don't always clean the database between tests > --- > > Key: JAMES-2849 > URL: https://issues.apache.org/jira/browse/JAMES-2849 > Project: James Server > Issue Type: Bug >Reporter: Matthieu Baechler >Priority: Major > > It looks like tests are not well isolated. We should implement a better > mechanism for database cleanup. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-2849) JPA tests don't always clean the database between tests
Matthieu Baechler created JAMES-2849: Summary: JPA tests don't always clean the database between tests Key: JAMES-2849 URL: https://issues.apache.org/jira/browse/JAMES-2849 Project: James Server Issue Type: Bug Reporter: Matthieu Baechler It looks like tests are not well isolated. We should implement a better mechanism for database cleanup. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-2848) Tests frequently leaks Cassandra connections
Matthieu Baechler created JAMES-2848: Summary: Tests frequently leaks Cassandra connections Key: JAMES-2848 URL: https://issues.apache.org/jira/browse/JAMES-2848 Project: James Server Issue Type: Bug Reporter: Matthieu Baechler We frequently have to hunt cassandra connections leaks in the tests when we realize that builds became longer and more unstable. It's unfortunate to have such a long feedback loop when it would be possible to detect leak as soon as they are introduced in the codebase. We should try to enhance these leaks detections. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Closed] (JAMES-2845) we should not use junit TemporaryFolder.getRoot Rule
[ https://issues.apache.org/jira/browse/JAMES-2845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Baechler closed JAMES-2845. Resolution: Fixed merged in master > we should not use junit TemporaryFolder.getRoot Rule > - > > Key: JAMES-2845 > URL: https://issues.apache.org/jira/browse/JAMES-2845 > Project: James Server > Issue Type: Bug >Reporter: Matthieu Baechler >Priority: Major > > This rule is supposed to be used to create new files and folders. > There are related new* methods. > Relying on TemporaryFolder.getRoot defeats the isolation purpose and make > tests unpredictable -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-2845) we should not use junit TemporaryFolder.getRoot Rule
Matthieu Baechler created JAMES-2845: Summary: we should not use junit TemporaryFolder.getRoot Rule Key: JAMES-2845 URL: https://issues.apache.org/jira/browse/JAMES-2845 Project: James Server Issue Type: Bug Reporter: Matthieu Baechler This rule is supposed to be used to create new files and folders. There are related new* methods. Relying on TemporaryFolder.getRoot defeats the isolation purpose and make tests unpredictable -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-2826) Improve compile time
Matthieu Baechler created JAMES-2826: Summary: Improve compile time Key: JAMES-2826 URL: https://issues.apache.org/jira/browse/JAMES-2826 Project: James Server Issue Type: Improvement Reporter: Matthieu Baechler Given that javac is a very fast compiler, we should be able to have a very fast compile phase with maven. However, it takes several minutes right now. We should bring back some sanity to this build. -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-2824) Users should be able to build James with Java 11
Matthieu Baechler created JAMES-2824: Summary: Users should be able to build James with Java 11 Key: JAMES-2824 URL: https://issues.apache.org/jira/browse/JAMES-2824 Project: James Server Issue Type: Improvement Reporter: Matthieu Baechler Java 11 is the only "Long Term Support" java release right now so more and more people will use it exclusively. As a first step towards Java 11 support for James, we should make it possible to build it with a Java 11 compiler (with a "-release 8" javac flag for now). -- This message was sent by Atlassian JIRA (v7.6.14#76016) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-2823) Some cassandra tests don't work when launched individually
Matthieu Baechler created JAMES-2823: Summary: Some cassandra tests don't work when launched individually Key: JAMES-2823 URL: https://issues.apache.org/jira/browse/JAMES-2823 Project: James Server Issue Type: Bug Components: cassandra Reporter: Matthieu Baechler Some tests don't work as expected when run outside the CI. They fail when trying to access CassandraSchemaVersion table but it's not initialized by the Cassandra extension. On CI, we reuse the same tables but just empty them so the tests pass but it adds a dependency on execution order, which is to avoid. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-2819) Upgrade pdfbox following CVE-2019-0228
Matthieu Baechler created JAMES-2819: Summary: Upgrade pdfbox following CVE-2019-0228 Key: JAMES-2819 URL: https://issues.apache.org/jira/browse/JAMES-2819 Project: James Server Issue Type: Task Affects Versions: 3.3.0, 3.4.0 Reporter: Matthieu Baechler James uses pdfbox library and a vulnerability was disclosed recently : CVE-2019-0228 We have to update pdfbox version in supported branches -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-2813) Implement a distributed task manager
Matthieu Baechler created JAMES-2813: Summary: Implement a distributed task manager Key: JAMES-2813 URL: https://issues.apache.org/jira/browse/JAMES-2813 Project: James Server Issue Type: Task Reporter: Matthieu Baechler Following JAMES-2272, we now would like to handle tasks at a cluster level. For that, we intend to use a combination of Event Sourcing for keeping track of Tasks submitted and RabbitMQ for dispatching the tasks in the cluster. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Closed] (JAMES-2792) Deployment tests don't provide server output
[ https://issues.apache.org/jira/browse/JAMES-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Baechler closed JAMES-2792. Resolution: Fixed Fix Version/s: 3.4.0 > Deployment tests don't provide server output > > > Key: JAMES-2792 > URL: https://issues.apache.org/jira/browse/JAMES-2792 > Project: James Server > Issue Type: Improvement >Reporter: Matthieu Baechler >Priority: Major > Fix For: 3.4.0 > > > When running Deployment tests, it would make sense to log James output to > understand what went wrong. > Today, we only log the client-side errors. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Closed] (JAMES-2697) Cassandra tests won't run on my computer
[ https://issues.apache.org/jira/browse/JAMES-2697?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Baechler closed JAMES-2697. Resolution: Fixed Fix Version/s: 3.4.0 finally merged! > Cassandra tests won't run on my computer > > > Key: JAMES-2697 > URL: https://issues.apache.org/jira/browse/JAMES-2697 > Project: James Server > Issue Type: Bug > Components: cassandra >Reporter: Matthieu Baechler >Priority: Major > Fix For: 3.4.0 > > > Cassandra container computes the total memory to use at startup time. > Depending on your computer total memory, it could ask for too much memory and > fail to start. > We should try to limit the amount of memory it uses to make sure it always > starts. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Closed] (JAMES-2803) Some tests leak their Elasticsearch connections
[ https://issues.apache.org/jira/browse/JAMES-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Baechler closed JAMES-2803. Resolution: Fixed Fix Version/s: 3.4.0 > Some tests leak their Elasticsearch connections > --- > > Key: JAMES-2803 > URL: https://issues.apache.org/jira/browse/JAMES-2803 > Project: James Server > Issue Type: Bug >Reporter: Matthieu Baechler >Priority: Major > Fix For: 3.4.0 > > > We found that some tests leak their Elasticsearch connections. We should > ensure connection get shut down after each test. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Closed] (JAMES-2804) CassandraMailRepositoryWithFakeImplementationsTest leaks Cassandra driver connections
[ https://issues.apache.org/jira/browse/JAMES-2804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Baechler closed JAMES-2804. Resolution: Fixed Fix Version/s: 3.4.0 > CassandraMailRepositoryWithFakeImplementationsTest leaks Cassandra driver > connections > - > > Key: JAMES-2804 > URL: https://issues.apache.org/jira/browse/JAMES-2804 > Project: James Server > Issue Type: Bug >Reporter: Matthieu Baechler >Priority: Major > Fix For: 3.4.0 > > > To workaround the fact that junit extensions are setup twice when using > @Nested class, in CassandraMailRepositoryWithFakeImplementationsTest, we > disabled the teardown of the extension. > It leads to a Cassandra driver leak. > We should avoid registering resources in the parent class instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Closed] (JAMES-2801) retrybackoff reactor operator may fail blocking Mono/Flux
[ https://issues.apache.org/jira/browse/JAMES-2801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Baechler closed JAMES-2801. Resolution: Fixed Fix Version/s: 3.4.0 > retrybackoff reactor operator may fail blocking Mono/Flux > - > > Key: JAMES-2801 > URL: https://issues.apache.org/jira/browse/JAMES-2801 > Project: James Server > Issue Type: Bug >Reporter: Matthieu Baechler >Priority: Major > Fix For: 3.4.0 > > > retryBackoff operator allows to use an implicit scheduler and the default one > is parallel. > However, some Mono/Flux are calling some block functions and calling these > functions in parallel is not supported. > We should by default use an elastic scheduler instead to avoid random > failures due to retries. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-2804) CassandraMailRepositoryWithFakeImplementationsTest leaks Cassandra driver connections
Matthieu Baechler created JAMES-2804: Summary: CassandraMailRepositoryWithFakeImplementationsTest leaks Cassandra driver connections Key: JAMES-2804 URL: https://issues.apache.org/jira/browse/JAMES-2804 Project: James Server Issue Type: Bug Reporter: Matthieu Baechler To workaround the fact that junit extensions are setup twice when using @Nested class, in CassandraMailRepositoryWithFakeImplementationsTest, we disabled the teardown of the extension. It leads to a Cassandra driver leak. We should avoid registering resources in the parent class instead. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-2803) Some tests leak their Elasticsearch connections
Matthieu Baechler created JAMES-2803: Summary: Some tests leak their Elasticsearch connections Key: JAMES-2803 URL: https://issues.apache.org/jira/browse/JAMES-2803 Project: James Server Issue Type: Bug Reporter: Matthieu Baechler We found that some tests leak their Elasticsearch connections. We should ensure connection get shut down after each test. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Closed] (JAMES-2800) Missing Singleton binding with Guice
[ https://issues.apache.org/jira/browse/JAMES-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Baechler closed JAMES-2800. Resolution: Fixed Fix Version/s: (was: master) 3.4.0 Done for today ... > Missing Singleton binding with Guice > > > Key: JAMES-2800 > URL: https://issues.apache.org/jira/browse/JAMES-2800 > Project: James Server > Issue Type: Improvement > Components: guice >Affects Versions: master >Reporter: Matthieu Baechler >Priority: Major > Fix For: 3.4.0 > > > Missing singleton bindings leads to many useless injections. > This is the recurring ticket on this ticket: let's have a look at missing > Singleton. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Closed] (JAMES-2802) Docker ElasticSearch container could provide better methods name
[ https://issues.apache.org/jira/browse/JAMES-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Baechler closed JAMES-2802. Resolution: Fixed Fix Version/s: 3.4.0 > Docker ElasticSearch container could provide better methods name > > > Key: JAMES-2802 > URL: https://issues.apache.org/jira/browse/JAMES-2802 > Project: James Server > Issue Type: Improvement >Reporter: Matthieu Baechler >Priority: Major > Fix For: 3.4.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-2802) Docker ElasticSearch container could provide better methods name
Matthieu Baechler created JAMES-2802: Summary: Docker ElasticSearch container could provide better methods name Key: JAMES-2802 URL: https://issues.apache.org/jira/browse/JAMES-2802 Project: James Server Issue Type: Improvement Reporter: Matthieu Baechler -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-2801) retrybackoff reactor operator may fail blocking Mono/Flux
Matthieu Baechler created JAMES-2801: Summary: retrybackoff reactor operator may fail blocking Mono/Flux Key: JAMES-2801 URL: https://issues.apache.org/jira/browse/JAMES-2801 Project: James Server Issue Type: Bug Reporter: Matthieu Baechler retryBackoff operator allows to use an implicit scheduler and the default one is parallel. However, some Mono/Flux are calling some block functions and calling these functions in parallel is not supported. We should by default use an elastic scheduler instead to avoid random failures due to retries. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Updated] (JAMES-2800) Missing Singleton binding with Guice
[ https://issues.apache.org/jira/browse/JAMES-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Baechler updated JAMES-2800: - Component/s: (was: cassandra) > Missing Singleton binding with Guice > > > Key: JAMES-2800 > URL: https://issues.apache.org/jira/browse/JAMES-2800 > Project: James Server > Issue Type: Improvement > Components: guice >Affects Versions: master >Reporter: Matthieu Baechler >Priority: Major > Fix For: master > > > Missing singleton bindings leads to many useless injections. > This is the recurring ticket on this ticket: let's have a look at missing > Singleton. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-2800) Missing Singleton binding with Guice
Matthieu Baechler created JAMES-2800: Summary: Missing Singleton binding with Guice Key: JAMES-2800 URL: https://issues.apache.org/jira/browse/JAMES-2800 Project: James Server Issue Type: Improvement Components: cassandra, guice Affects Versions: master Reporter: Matthieu Baechler Fix For: master Missing singleton bindings leads to double injections. Because of this, Cassandra queries are re-prepared several times. Hence it leads to warnings and sub-optimal code. We should ensure CassandraBlobsDAO and CassandraMessageDAOV2 get injected with scope singleton. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Updated] (JAMES-2800) Missing Singleton binding with Guice
[ https://issues.apache.org/jira/browse/JAMES-2800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Baechler updated JAMES-2800: - Description: Missing singleton bindings leads to many useless injections. This is the recurring ticket on this ticket: let's have a look at missing Singleton. was: Missing singleton bindings leads to double injections. Because of this, Cassandra queries are re-prepared several times. Hence it leads to warnings and sub-optimal code. We should ensure CassandraBlobsDAO and CassandraMessageDAOV2 get injected with scope singleton. > Missing Singleton binding with Guice > > > Key: JAMES-2800 > URL: https://issues.apache.org/jira/browse/JAMES-2800 > Project: James Server > Issue Type: Improvement > Components: cassandra, guice >Affects Versions: master >Reporter: Matthieu Baechler >Priority: Major > Fix For: master > > > Missing singleton bindings leads to many useless injections. > This is the recurring ticket on this ticket: let's have a look at missing > Singleton. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-2796) enhance Docker usage during tests
Matthieu Baechler created JAMES-2796: Summary: enhance Docker usage during tests Key: JAMES-2796 URL: https://issues.apache.org/jira/browse/JAMES-2796 Project: James Server Issue Type: Improvement Reporter: Matthieu Baechler Docker is used extensively for testing. However, it grew organically and the codebase can be enhanced/simplified at this point. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-2792) Deployment tests don't provide server output
Matthieu Baechler created JAMES-2792: Summary: Deployment tests don't provide server output Key: JAMES-2792 URL: https://issues.apache.org/jira/browse/JAMES-2792 Project: James Server Issue Type: Improvement Reporter: Matthieu Baechler When running Deployment tests, it would make sense to log James output to understand what went wrong. Today, we only log the client-side errors. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Closed] (MPT-39) static field injection and deep class hierarchy makes lifecycle management harder than needed
[ https://issues.apache.org/jira/browse/MPT-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Baechler closed MPT-39. Resolution: Fixed Solved with 78cf06abf4c44851c116f71e27326773356c14b7 > static field injection and deep class hierarchy makes lifecycle management > harder than needed > - > > Key: MPT-39 > URL: https://issues.apache.org/jira/browse/MPT-39 > Project: James MPT > Issue Type: Improvement >Reporter: Matthieu Baechler >Priority: Major > > I tried to have a finer management of resources we use in tests but onami + > static field injection + test constructor makes it unmanageable. > It also enforce the use of guice that should not be needed. > We could make mpt tests look like regular tests. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-2757) rabbitmq MailQueueView.isPresent is never called
[ https://issues.apache.org/jira/browse/JAMES-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16836449#comment-16836449 ] Matthieu Baechler commented on JAMES-2757: -- It looks like we don't have any JIRA for it because JAMES-2733 is not related to that issue. > rabbitmq MailQueueView.isPresent is never called > > > Key: JAMES-2757 > URL: https://issues.apache.org/jira/browse/JAMES-2757 > Project: James Server > Issue Type: Improvement > Components: Queue, rabbitmq >Reporter: Matthieu Baechler >Priority: Major > > As far as I know, the design of rabbitmq MailQueue is the following: > On Enqueue: > 1. put the raw message in a blobstore > 2. put the reference to it into rabbitmq > 3. put some metadata about it into cassandra > On Delete: > 1. use cassandra to browse messages in the queue and remove the ones that > match the query > On Dequeue: > 1. take the next message from rabbit > 2. check that the message is not deleted by calling cassandra > MailQueueView.isPresent > On browse: > 1. use cassandra MailQueueView to list not yet deleted messages > It looks like we don't check that the message is not deleted on dequeue. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-2757) rabbitmq MailQueueView.isPresent is never called
Matthieu Baechler created JAMES-2757: Summary: rabbitmq MailQueueView.isPresent is never called Key: JAMES-2757 URL: https://issues.apache.org/jira/browse/JAMES-2757 Project: James Server Issue Type: Improvement Components: Queue, rabbitmq Reporter: Matthieu Baechler As far as I know, the design of rabbitmq MailQueue is the following: On Enqueue: 1. put the raw message in a blobstore 2. put the reference to it into rabbitmq 3. put some metadata about it into cassandra On Delete: 1. use cassandra to browse messages in the queue and remove the ones that match the query On Dequeue: 1. take the next message from rabbit 2. check that the message is not deleted by calling cassandra MailQueueView.isPresent On browse: 1. use cassandra MailQueueView to list not yet deleted messages It looks like we don't check that the message is not deleted on dequeue. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-2702) TimeConverter class should rely on Duration
Matthieu Baechler created JAMES-2702: Summary: TimeConverter class should rely on Duration Key: JAMES-2702 URL: https://issues.apache.org/jira/browse/JAMES-2702 Project: James Server Issue Type: Improvement Reporter: Matthieu Baechler TimeConverter is used to read duration as expressed in configuration files, like "2 days". However, it relies on the false assumption that 2 days are a fixed number of milliseconds and convert the value into long. It has to use Duration instead that handle nicely all the hard logic of duration and date handling. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-2697) Cassandra tests won't run on my computer
Matthieu Baechler created JAMES-2697: Summary: Cassandra tests won't run on my computer Key: JAMES-2697 URL: https://issues.apache.org/jira/browse/JAMES-2697 Project: James Server Issue Type: Bug Components: cassandra Reporter: Matthieu Baechler Cassandra container computes the total memory to use at startup time. Depending on your computer total memory, it could ask for too much memory and fail to start. We should try to limit the amount of memory it uses to make sure it always starts. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Closed] (JAMES-2695) EventCollector should be threadsafe
[
https://issues.apache.org/jira/browse/JAMES-2695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthieu Baechler closed JAMES-2695.
Resolution: Fixed
Fix Version/s: 3.4.0
> EventCollector should be threadsafe
> ---
>
> Key: JAMES-2695
> URL: https://issues.apache.org/jira/browse/JAMES-2695
> Project: James Server
> Issue Type: Bug
>Reporter: Matthieu Baechler
>Priority: Major
> Fix For: 3.4.0
>
>
> We sometime experience this kind of error :
> {code}
> [ERROR]
> SetMessagesMethodTest.lambda$setMessagesShouldCreateMessageInOutboxWhenSendingMessage$3:2326
> » ConcurrentModification
> {code}
> To avoid this exception, we should at least make EventCollector thread-safe.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-2695) EventCollector should be threadsafe
Matthieu Baechler created JAMES-2695:
Summary: EventCollector should be threadsafe
Key: JAMES-2695
URL: https://issues.apache.org/jira/browse/JAMES-2695
Project: James Server
Issue Type: Bug
Reporter: Matthieu Baechler
We sometime experience this kind of error :
{code}
[ERROR]
SetMessagesMethodTest.lambda$setMessagesShouldCreateMessageInOutboxWhenSendingMessage$3:2326
» ConcurrentModification
{code}
To avoid this exception, we should at least make EventCollector thread-safe.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Closed] (JAMES-2683) RabbitMQMailQueueTest leaks threads
[ https://issues.apache.org/jira/browse/JAMES-2683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Baechler closed JAMES-2683. > RabbitMQMailQueueTest leaks threads > --- > > Key: JAMES-2683 > URL: https://issues.apache.org/jira/browse/JAMES-2683 > Project: James Server > Issue Type: Bug >Reporter: Matthieu Baechler >Priority: Major > Fix For: 3.4.0 > > > With current master, running RabbitMQMailQueueTest creates 297 threads, 140 > of which never get closed. > There's 30 AMQPConnection threads and 89 pool-* threads likely created by > RabbitMQ driver. > It makes the testsuite unstable. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (JAMES-2683) RabbitMQMailQueueTest leaks threads
[ https://issues.apache.org/jira/browse/JAMES-2683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Baechler resolved JAMES-2683. -- Resolution: Fixed Fix Version/s: 3.4.0 > RabbitMQMailQueueTest leaks threads > --- > > Key: JAMES-2683 > URL: https://issues.apache.org/jira/browse/JAMES-2683 > Project: James Server > Issue Type: Bug >Reporter: Matthieu Baechler >Priority: Major > Fix For: 3.4.0 > > > With current master, running RabbitMQMailQueueTest creates 297 threads, 140 > of which never get closed. > There's 30 AMQPConnection threads and 89 pool-* threads likely created by > RabbitMQ driver. > It makes the testsuite unstable. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-2683) RabbitMQMailQueueTest leaks threads
Matthieu Baechler created JAMES-2683: Summary: RabbitMQMailQueueTest leaks threads Key: JAMES-2683 URL: https://issues.apache.org/jira/browse/JAMES-2683 Project: James Server Issue Type: Bug Reporter: Matthieu Baechler With current master, running RabbitMQMailQueueTest creates 297 threads, 140 of which never get closed. There's 30 AMQPConnection threads and 89 pool-* threads likely created by RabbitMQ driver. It makes the testsuite unstable. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Updated] (JAMES-2679) Some Mail instance can have a null name
[
https://issues.apache.org/jira/browse/JAMES-2679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthieu Baechler updated JAMES-2679:
-
Affects Version/s: (was: 3.3.0)
3.2.0
Fix Version/s: (was: 3.4.0)
3.3.0
> Some Mail instance can have a null name
> ---
>
> Key: JAMES-2679
> URL: https://issues.apache.org/jira/browse/JAMES-2679
> Project: James Server
> Issue Type: Bug
>Affects Versions: 3.2.0
>Reporter: Matthieu Baechler
>Priority: Major
> Fix For: 3.3.0
>
>
> During a stress test, I encountered this kind of errors :
> {code}
> java.lang.NullPointerException: null
> at
> com.google.common.base.Preconditions.checkNotNull(Preconditions.java:877)
> at
> org.apache.james.queue.rabbitmq.view.api.DeleteCondition.withName(DeleteCondition.java:170)
> at
> org.apache.james.queue.rabbitmq.Dequeuer.lambda$ack$1(Dequeuer.java:106)
> at
> com.github.fge.lambdas.consumers.ThrowingConsumer.accept(ThrowingConsumer.java:22)
> at
> org.apache.james.queue.rabbitmq.Dequeuer$RabbitMQMailQueueItem.done(Dequeuer.java:62)
> at
> org.apache.james.jmap.send.PostDequeueDecorator.done(PostDequeueDecorator.java:80)
> at
> org.apache.james.mailetcontainer.impl.JamesMailSpooler.lambda$run$0(JamesMailSpooler.java:164)
> {code}
> It looks like there's some code path that allows a Mail to have a null name.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Closed] (JAMES-2672) Some Mail instance can have a null name
[
https://issues.apache.org/jira/browse/JAMES-2672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matthieu Baechler closed JAMES-2672.
Resolution: Fixed
Fix Version/s: 3.4.0
merged
> Some Mail instance can have a null name
> ---
>
> Key: JAMES-2672
> URL: https://issues.apache.org/jira/browse/JAMES-2672
> Project: James Server
> Issue Type: Bug
>Affects Versions: 3.3.0
>Reporter: Matthieu Baechler
>Priority: Major
> Fix For: 3.4.0
>
>
> During a stress test, I encountered this kind of errors :
> {code}
> java.lang.NullPointerException: null
> at
> com.google.common.base.Preconditions.checkNotNull(Preconditions.java:877)
> at
> org.apache.james.queue.rabbitmq.view.api.DeleteCondition.withName(DeleteCondition.java:170)
> at
> org.apache.james.queue.rabbitmq.Dequeuer.lambda$ack$1(Dequeuer.java:106)
> at
> com.github.fge.lambdas.consumers.ThrowingConsumer.accept(ThrowingConsumer.java:22)
> at
> org.apache.james.queue.rabbitmq.Dequeuer$RabbitMQMailQueueItem.done(Dequeuer.java:62)
> at
> org.apache.james.jmap.send.PostDequeueDecorator.done(PostDequeueDecorator.java:80)
> at
> org.apache.james.mailetcontainer.impl.JamesMailSpooler.lambda$run$0(JamesMailSpooler.java:164)
> {code}
> It looks like there's some code path that allows a Mail to have a null name.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-2679) Some Mail instance can have a null name
Matthieu Baechler created JAMES-2679:
Summary: Some Mail instance can have a null name
Key: JAMES-2679
URL: https://issues.apache.org/jira/browse/JAMES-2679
Project: James Server
Issue Type: Bug
Affects Versions: 3.3.0
Reporter: Matthieu Baechler
Fix For: 3.4.0
During a stress test, I encountered this kind of errors :
{code}
java.lang.NullPointerException: null
at
com.google.common.base.Preconditions.checkNotNull(Preconditions.java:877)
at
org.apache.james.queue.rabbitmq.view.api.DeleteCondition.withName(DeleteCondition.java:170)
at
org.apache.james.queue.rabbitmq.Dequeuer.lambda$ack$1(Dequeuer.java:106)
at
com.github.fge.lambdas.consumers.ThrowingConsumer.accept(ThrowingConsumer.java:22)
at
org.apache.james.queue.rabbitmq.Dequeuer$RabbitMQMailQueueItem.done(Dequeuer.java:62)
at
org.apache.james.jmap.send.PostDequeueDecorator.done(PostDequeueDecorator.java:80)
at
org.apache.james.mailetcontainer.impl.JamesMailSpooler.lambda$run$0(JamesMailSpooler.java:164)
{code}
It looks like there's some code path that allows a Mail to have a null name.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Closed] (JAMES-2677) cassandra-driver could be updated to 3.7.0
[ https://issues.apache.org/jira/browse/JAMES-2677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthieu Baechler closed JAMES-2677. Resolution: Fixed Fix Version/s: 3.4.0 merged > cassandra-driver could be updated to 3.7.0 > -- > > Key: JAMES-2677 > URL: https://issues.apache.org/jira/browse/JAMES-2677 > Project: James Server > Issue Type: Improvement > Components: cassandra >Reporter: Matthieu Baechler >Priority: Major > Fix For: 3.4.0 > > > James uses cassandra driver 3.5.1 and could be updated to 3.7.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-2677) cassandra-driver could be updated to 3.7.0
Matthieu Baechler created JAMES-2677: Summary: cassandra-driver could be updated to 3.7.0 Key: JAMES-2677 URL: https://issues.apache.org/jira/browse/JAMES-2677 Project: James Server Issue Type: Improvement Components: cassandra Reporter: Matthieu Baechler James uses cassandra driver 3.5.1 and could be updated to 3.7.0 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (MAILBOX-383) Message delivery starts before the EventBus
Matthieu Baechler created MAILBOX-383:
-
Summary: Message delivery starts before the EventBus
Key: MAILBOX-383
URL: https://issues.apache.org/jira/browse/MAILBOX-383
Project: James Mailbox
Issue Type: Bug
Reporter: Matthieu Baechler
When restarting James, it can happen that event delivery starts before the
EventBus is started :
{code}
17:17:45.037 [ERROR] o.a.j.t.m.d.MailDispatcher - Error while storing mail.
java.lang.IllegalStateException: Event Bus is not running
at
org.apache.james.mailbox.events.RabbitMQEventBus.dispatch(RabbitMQEventBus.java:125)
at org.apache.james.mailbox.events.EventBus.dispatch(EventBus.java:54)
at
org.apache.james.mailbox.store.StoreMessageManager.lambda$appendMessage$2(StoreMessageManager.java:456)
at
org.apache.james.mailbox.store.AbstractMailboxPathLocker.executeWithLock(AbstractMailboxPathLocker.java:38)
at
org.apache.james.mailbox.store.StoreMessageManager.appendMessage(StoreMessageManager.java:451)
at
org.apache.james.mailbox.store.StoreMessageManager.appendMessage(StoreMessageManager.java:320)
at
org.apache.james.transport.mailets.delivery.MailboxAppender.appendMessageToMailbox(MailboxAppender.java:82)
at
org.apache.james.transport.mailets.delivery.MailboxAppender.append(MailboxAppender.java:68)
at
org.apache.james.transport.mailets.delivery.MailboxAppender.append(MailboxAppender.java:50)
at
org.apache.james.transport.mailets.delivery.SimpleMailStore.storeMail(SimpleMailStore.java:97)
at
org.apache.james.transport.mailets.delivery.MailDispatcher.deliver(MailDispatcher.java:132)
at
org.apache.james.transport.mailets.delivery.MailDispatcher.customizeHeadersAndDeliver(MailDispatcher.java:120)
at
org.apache.james.transport.mailets.delivery.MailDispatcher.dispatch(MailDispatcher.java:91)
at
org.apache.james.transport.mailets.LocalDelivery.service(LocalDelivery.java:62)
at
org.apache.james.mailetcontainer.impl.camel.CamelProcessor.process(CamelProcessor.java:81)
at
org.apache.james.mailetcontainer.impl.camel.CamelMailetProcessor$MailetContainerRouteBuilder.handleMailet(CamelMailetProcessor.java:178)
at
org.apache.james.mailetcontainer.impl.camel.CamelMailetProcessor$MailetContainerRouteBuilder.lambda$configure$0(CamelMailetProcessor.java:155)
at
org.apache.camel.processor.DelegateSyncProcessor.process(DelegateSyncProcessor.java:63)
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:548)
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:548)
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
at
org.apache.camel.processor.MulticastProcessor.doProcessSequential(MulticastProcessor.java:715)
at
org.apache.camel.processor.MulticastProcessor.doProcessSequential(MulticastProcessor.java:638)
at
org.apache.camel.processor.MulticastProcessor.process(MulticastProcessor.java:248)
at org.apache.camel.processor.Splitter.process(Splitter.java:130)
at
org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:548)
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:138)
at org.apache.camel.processor.Pipeline.process(Pipeline.java:101)
at
org.apache.camel.processor.CamelInternalProcessor.process(CamelInternalProcessor.java:201)
at
org.apache.camel.component.direct.DirectBlockingProducer.process(DirectBlockingProducer.java:53)
at
org.apache.camel.processor.SharedCamelInternalProcessor.process(SharedCamelInternalProcessor.java:186)
at
org.apache.camel.processor.SharedCamelInternalProcessor.process(SharedCamelInternalProcessor.java:86)
at
org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:541)
at
org.apache.camel.impl.ProducerCache$1.doInProducer(ProducerCache.java:506)
at
org.apache.camel.impl.ProducerCache.doInProducer(ProducerCache.java:369)
at
org.apache.camel.impl.ProducerCache.sendExchange(ProducerCache.java:506)
at org.apache.camel.impl.ProducerCache.send(ProducerCache.java:229)
at
org.apache.camel.impl.DefaultProducerTemplate.send(DefaultProducerTemplate.java:144)
at
org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:161)
at
org.apache.camel.impl.DefaultProducerTemplate.sendBody(DefaultProducerTemplate.java:168)
at
org.apache.james.mailetcontainer.impl.camel.CamelMailetProcessor.service(CamelMailetProce
[jira] [Created] (JAMES-2672) Some Mail instance can have a null name
Matthieu Baechler created JAMES-2672:
Summary: Some Mail instance can have a null name
Key: JAMES-2672
URL: https://issues.apache.org/jira/browse/JAMES-2672
Project: James Server
Issue Type: Bug
Affects Versions: 3.3.0
Reporter: Matthieu Baechler
During a stress test, I encountered this kind of errors :
{code}
java.lang.NullPointerException: null
at
com.google.common.base.Preconditions.checkNotNull(Preconditions.java:877)
at
org.apache.james.queue.rabbitmq.view.api.DeleteCondition.withName(DeleteCondition.java:170)
at
org.apache.james.queue.rabbitmq.Dequeuer.lambda$ack$1(Dequeuer.java:106)
at
com.github.fge.lambdas.consumers.ThrowingConsumer.accept(ThrowingConsumer.java:22)
at
org.apache.james.queue.rabbitmq.Dequeuer$RabbitMQMailQueueItem.done(Dequeuer.java:62)
at
org.apache.james.jmap.send.PostDequeueDecorator.done(PostDequeueDecorator.java:80)
at
org.apache.james.mailetcontainer.impl.JamesMailSpooler.lambda$run$0(JamesMailSpooler.java:164)
{code}
It looks like there's some code path that allows a Mail to have a null name.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (MAILBOX-382) EventDeadLetter: rechedule event delivery
[
https://issues.apache.org/jira/browse/MAILBOX-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1642#comment-1642
]
Matthieu Baechler commented on MAILBOX-382:
---
I would remove the second occurrence but we can debate that.
> EventDeadLetter: rechedule event delivery
> -
>
> Key: MAILBOX-382
> URL: https://issues.apache.org/jira/browse/MAILBOX-382
> Project: James Mailbox
> Issue Type: New Feature
>Reporter: Trần Tiến Đức
>Priority: Major
>
> base on: -MAILBOX-373-
> The event bus need a method for re-delivering an event to a group.
> {code:java}
> Mono reDeliver(Group group, Event event);{code}
> In webAdmin implement the following endpoints:
> {code:java}
> curl -POST /events/deadLetter/events?action=reDeliver
> curl -POST
> /events/deadLetter/groups/ListeningQuotaUpdaterGroup/events?action=reDeliver
> curl -POST
> /events/deadLetter/groups/ListeningQuotaUpdaterGroup/events/UUID?action=reDeliver{code}
> And the tasks that backs it up.
> Implement tests for EventBus method addition & for WebAdmin new routes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (MAILBOX-382) EventDeadLetter: rechedule event delivery
[
https://issues.apache.org/jira/browse/MAILBOX-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1620#comment-1620
]
Matthieu Baechler commented on MAILBOX-382:
---
deadLetter could be used in several contexts, I think it makes sense to prefix
it by events to know what context we are talking about (paths should go from
more general concepts to more specific).
> EventDeadLetter: rechedule event delivery
> -
>
> Key: MAILBOX-382
> URL: https://issues.apache.org/jira/browse/MAILBOX-382
> Project: James Mailbox
> Issue Type: New Feature
>Reporter: Trần Tiến Đức
>Priority: Major
>
> base on: -MAILBOX-373-
> The event bus need a method for re-delivering an event to a group.
> {code:java}
> Mono reDeliver(Group group, Event event);{code}
> In webAdmin implement the following endpoints:
> {code:java}
> curl -POST /events/deadLetter/events?action=reDeliver
> curl -POST
> /events/deadLetter/groups/ListeningQuotaUpdaterGroup/events?action=reDeliver
> curl -POST
> /events/deadLetter/groups/ListeningQuotaUpdaterGroup/events/UUID?action=reDeliver{code}
> And the tasks that backs it up.
> Implement tests for EventBus method addition & for WebAdmin new routes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (MAILBOX-381) [DeletedMessagesVault] API (not retention) + Contract + impl on top of MailRepository
[
https://issues.apache.org/jira/browse/MAILBOX-381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16776961#comment-16776961
]
Matthieu Baechler commented on MAILBOX-381:
---
{code}
Mono delete(MessageId messageId);
{code}
could return the DeletedMessage
Also, we should not use Mono/Flux but reactivestream Publisher instead
> [DeletedMessagesVault] API (not retention) + Contract + impl on top of
> MailRepository
> -
>
> Key: MAILBOX-381
> URL: https://issues.apache.org/jira/browse/MAILBOX-381
> Project: James Mailbox
> Issue Type: New Feature
>Reporter: Trần Tiến Đức
>Priority: Major
>
> DeletedMessagesVault is where you store mails after being deleted in `Trash`.
> It allows to:
> - Store a `DeletedMessage` of an user
> - Delete a `DeletedMessage` stored before by the `MessageId`
> - Search a list of `DeletedMessage` by a `Query`
> The proposal API:
> {code:java}
> interface DeletedMessagesVault {
> Mono append(User user, DeletedMessage deletedMessage);
> Mono delete(MessageId messageId);
> Flux search(Query query);
> }{code}
> API will be placed in a new maven module
> `mailbox/plugin/deleted-messages-vault`
> You will also need to define those POJOs
> - DeletedMessage: it wraps a MailboxMessage contents and deleted message
> metadata:
> - deletion date
> - delivery date
> - recipients
> - sender
> - has attachment
> - origin mailboxes
> - subject (contains, equals / ignore case)
> - Query: this POJO define various search criteria base on list of
> DeletedMessage metadata.
> About DeletedMessagesVault impl
> By leverage `MailRepository` component you will create your impl ontop of
> `MailRepository`. At the moment `MailRepository` only supports `store` and
> `remove`, so you have to:
> - Apply search feature in `MailRepository`
> - `DeletedMessagesVault` impl is intend to use `CassandraMailRepository`,
> `DeletedMessagesVault` is per-user, and each one points to a specify
> `MailRepositoryUrl` belong to a specific User.
> - Adapt DeletedMessagesVault impl with `MailRepository` APIs.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (MAILBOX-382) EventDeadLetter: rechedule event delivery
[
https://issues.apache.org/jira/browse/MAILBOX-382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16776951#comment-16776951
]
Matthieu Baechler commented on MAILBOX-382:
---
{code}
curl -POST /events/deadLetter/events?action=reDeliver
{code}
the second occurrence of events is probably a bad idea
{code}
curl -POST
/events/deadLetter/groups/ListeningQuotaUpdaterGroup/events?action=reDeliver
curl -POST
/events/deadLetter/groups/ListeningQuotaUpdaterGroup/events/UUID?action=reDeliver
{code}
Same thing for these APIs too
> EventDeadLetter: rechedule event delivery
> -
>
> Key: MAILBOX-382
> URL: https://issues.apache.org/jira/browse/MAILBOX-382
> Project: James Mailbox
> Issue Type: New Feature
>Reporter: Trần Tiến Đức
>Priority: Major
>
> base on: -MAILBOX-373-
> The event bus need a method for re-delivering an event to a group.
> {code:java}
> Mono reDeliver(Group group, Event event);{code}
> In webAdmin implement the following endpoints:
> {code:java}
> curl -POST /events/deadLetter/events?action=reDeliver
> curl -POST
> /events/deadLetter/groups/ListeningQuotaUpdaterGroup/events?action=reDeliver
> curl -POST
> /events/deadLetter/groups/ListeningQuotaUpdaterGroup/events/UUID?action=reDeliver{code}
> And the tasks that backs it up.
> Implement tests for EventBus method addition & for WebAdmin new routes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-2658) Generic mailet to call an external microservice, and add extra information to an email
[
https://issues.apache.org/jira/browse/JAMES-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16764735#comment-16764735
]
Matthieu Baechler commented on JAMES-2658:
--
Implementing RFC 5257 seems a good move, thank you for the suggestion and the
link.
> Also about the API format, getting this generic enough might be a real pain.
> I really wonder if implementing a specific component, matching a well-defined
> service API is not better in the end than pushing most of the email
> complexity to the client... > For the record, we chose the specific component
> + well-defined service API option when implementing *email classification
> prediction*. What did change?
I'm not sure to understand what you wrote. BTW, what did change since *email
classification prediction* is:
* we don't want to write a James component every time we have to link and
external service
* email classification prediction had a poor design that allowed to go forward
with an experiment, we never meant to keep the design as-is
And finally, I already wrote it, but transforming a MIME mail to a JSON format
removes less than 1% of the complexity, so the "pushing email complexity to the
client" doesn't convince me.
> Generic mailet to call an external microservice, and add extra information to
> an email
> --
>
> Key: JAMES-2658
> URL: https://issues.apache.org/jira/browse/JAMES-2658
> Project: James Server
> Issue Type: Wish
>Reporter: Michael Bailly
>Priority: Minor
>
> Hello team. This is a Request For Comments for a feature, to be able to add
> extra information to an email on delivery to a local mailbox.
> h2. Principle
> the mailet calls a remote webservice, with a pre-specified payload. It gets
> back, either an error, or another specific payload. This payload can instruct
> the James server to add informations to the email. The first case, that we
> handle here, is to add extra headers.
>
> h2. Implementation
> OK, I'll try to map the mailet syntax, but I'll make mistakes, it's to
> illustrate the principle.
> James configuration:
> {{ endpoint="https://server.com/api/infos"; />}}
> Seeing this, the mailer issues a POST on {{[https://server.com/api/infos]}}
> with the following payload structure:
> {
> {{ "messageId" : "messageId",}}
> {{ "from" : {}}
> {{ "address" : "f...@test.com",}}
> {{ "personal" : "first_name last_name"}}
> {{ },}}
> {{ "to" : [ {}}
> {{ "address" : "t...@test.com",}}
> {{ "personal" : "first_name last_name of to1"}}
> {{ } ],}}
> {{ "cc" : [ {}}
> {{ "address" : "c...@test.com",}}
> {{ "personal" : null}}
> {{ }, {}}
> {{ "address" : "c...@test.com",}}
> {{ "personal" : "first_name last_name of cc2"}}
> {{ }, {}}
> {{ "address" : "c...@test.com",}}
> {{ "personal" : "first_name last_name of cc3"}}
> {{ } ],}}
> {{ "bcc" : [ ],}}
> {{ "Received" : "Mon, 28 Jan 2019 07:56:43 +",}}
> {{ "Date" : "Mon, 28 Jan 2019 07:56:43 +",}}
> {{ "in-Reply-To" : "messageId_in_reply_to",}}
> {{ "subject" : "IMPORTANT: Testing The Priority Inbox",}}
> {{ "body" : "\nDear, \n\n this a test of the priority inbox\n
> regards,\nfirst_name last_name\nDirector Tester",}}
> {{ "attachments" : [{}}
> {{ "file_size" : "243534",}}
> {{ "content_name" : "presentation.pdf",}}
> {{ "content_type" : "APPLICATION/PDF"}}
> {{ }, {}}
> {{ "file_size": "243534",}}
> {{ "content_type" : "APPLICATION/PDF",}}
> {{ "content_name" : "performance.pdf"}}
> {{ }],}}
> {{ "emailFolder" : "INBOX",}}
> {{ "user" : "first_name last_name of to1",}}
> {{ "alternativeAddress" : [ "t...@test.com",
> "first_name.last_n...@test.com" ],}}
> {{ "X-Spam-Flag" : "NO"}}
> {{}}}
> Worth noting: all those attributes are JSON formatting of an email contents,
> EXCEPT:
> * emailFolder : the destination folder of the email
> * user & alternativeAddress : the user the email is delivered to
> This mailet expects a specific format for the response. Here is a proposal:
> 1/ "bypass" (do nothing)
> {{{}}}
> 2/ "add headers"
> {
> "addHeaders": [
> {name: "X-INFO1", value: "some header value"},
> \{name: "X-INFO1-SCORE", value: "0.4"}
> ]
> }
> h3. Handling failure
> The mailet may support a specific attribute to define the behaviour in case
> of failure.
> {{ endpoint="https://server.com/api/infos"; on-failure="ignore" />}}
> h3. Configuring retries
> The mailet may support a retry parameter, allowing to retry x times before
> "really" failing. The additional, optional retry delay parameter could set
> the time, in seconds, to wait between each retry.
> {{ endpoint="https://server.com/api/infos"; on-failure="ignore" retry="5"
> retry-delay="0.5" />}}
> h3. Set
[jira] [Commented] (JAMES-2658) Generic mailet to call an external microservice, and add extra information to an email
[
https://issues.apache.org/jira/browse/JAMES-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16762518#comment-16762518
]
Matthieu Baechler commented on JAMES-2658:
--
Speaking about use cases, and after reading Raphael answer: you probably want
to interact at a very different level.
Mailet is for mail delivery. Smart reply makes sense only when the mail is
already delivered. Important email detection could suffer some delay, too.
Raphael gave you a very interesting solution: using the jmap interface (being
in-browser or not doesn't make any difference in my opinion).
Another solution would be to register a mailbox listener, like we do for
SpamAssassin learning for example.
> Generic mailet to call an external microservice, and add extra information to
> an email
> --
>
> Key: JAMES-2658
> URL: https://issues.apache.org/jira/browse/JAMES-2658
> Project: James Server
> Issue Type: Wish
>Reporter: Michael Bailly
>Priority: Minor
>
> Hello team. This is a Request For Comments for a feature, to be able to add
> extra information to an email on delivery to a local mailbox.
> h2. Principle
> the mailet calls a remote webservice, with a pre-specified payload. It gets
> back, either an error, or another specific payload. This payload can instruct
> the James server to add informations to the email. The first case, that we
> handle here, is to add extra headers.
>
> h2. Implementation
> OK, I'll try to map the mailet syntax, but I'll make mistakes, it's to
> illustrate the principle.
> James configuration:
> {{ endpoint="https://server.com/api/infos"; />}}
> Seeing this, the mailer issues a POST on {{[https://server.com/api/infos]}}
> with the following payload structure:
> {
> {{ "messageId" : "messageId",}}
> {{ "from" : {}}
> {{ "address" : "f...@test.com",}}
> {{ "personal" : "first_name last_name"}}
> {{ },}}
> {{ "to" : [ {}}
> {{ "address" : "t...@test.com",}}
> {{ "personal" : "first_name last_name of to1"}}
> {{ } ],}}
> {{ "cc" : [ {}}
> {{ "address" : "c...@test.com",}}
> {{ "personal" : null}}
> {{ }, {}}
> {{ "address" : "c...@test.com",}}
> {{ "personal" : "first_name last_name of cc2"}}
> {{ }, {}}
> {{ "address" : "c...@test.com",}}
> {{ "personal" : "first_name last_name of cc3"}}
> {{ } ],}}
> {{ "bcc" : [ ],}}
> {{ "Received" : "Mon, 28 Jan 2019 07:56:43 +",}}
> {{ "Date" : "Mon, 28 Jan 2019 07:56:43 +",}}
> {{ "in-Reply-To" : "messageId_in_reply_to",}}
> {{ "subject" : "IMPORTANT: Testing The Priority Inbox",}}
> {{ "body" : "\nDear, \n\n this a test of the priority inbox\n
> regards,\nfirst_name last_name\nDirector Tester",}}
> {{ "attachments" : [{}}
> {{ "file_size" : "243534",}}
> {{ "content_name" : "presentation.pdf",}}
> {{ "content_type" : "APPLICATION/PDF"}}
> {{ }, {}}
> {{ "file_size": "243534",}}
> {{ "content_type" : "APPLICATION/PDF",}}
> {{ "content_name" : "performance.pdf"}}
> {{ }],}}
> {{ "emailFolder" : "INBOX",}}
> {{ "user" : "first_name last_name of to1",}}
> {{ "alternativeAddress" : [ "t...@test.com",
> "first_name.last_n...@test.com" ],}}
> {{ "X-Spam-Flag" : "NO"}}
> {{}}}
> Worth noting: all those attributes are JSON formatting of an email contents,
> EXCEPT:
> * emailFolder : the destination folder of the email
> * user & alternativeAddress : the user the email is delivered to
> This mailet expects a specific format for the response. Here is a proposal:
> 1/ "bypass" (do nothing)
> {{{}}}
> 2/ "add headers"
> {
> "addHeaders": [
> {name: "X-INFO1", value: "some header value"},
> \{name: "X-INFO1-SCORE", value: "0.4"}
> ]
> }
> h3. Handling failure
> The mailet may support a specific attribute to define the behaviour in case
> of failure.
> {{ endpoint="https://server.com/api/infos"; on-failure="ignore" />}}
> h3. Configuring retries
> The mailet may support a retry parameter, allowing to retry x times before
> "really" failing. The additional, optional retry delay parameter could set
> the time, in seconds, to wait between each retry.
> {{ endpoint="https://server.com/api/infos"; on-failure="ignore" retry="5"
> retry-delay="0.5" />}}
> h3. Setting blocking behaviour
> Some processing may not require an immediate response, and may allow further
> processing of the mailet chain. Here, either the "blocking" or the "async"
> attribute, I can't choose, may be used.
> {{ endpoint="https://server.com/api/infos"; on-failure="ignore" retry="5"
> retry-delay="0.5" blocking="false" />}}
> or, as a second proposal
> {{ endpoint="https://server.com/api/infos"; on-failure="ignore" retry="5"
> retry-delay="0.5" async="true" />}}
> h2. Things I don't know
> * Where to
[jira] [Created] (JAMES-2659) RabbitMQ EventBus test `RabbitMQEventBusTest` is unstable
Matthieu Baechler created JAMES-2659:
Summary: RabbitMQ EventBus test `RabbitMQEventBusTest` is unstable
Key: JAMES-2659
URL: https://issues.apache.org/jira/browse/JAMES-2659
Project: James Server
Issue Type: Bug
Components: rabbitmq
Reporter: Matthieu Baechler
Master build fails often with that error
{code:java}
[null] org.junit.ComparisonFailure: expected:<3[1]> but was:<3[2]>
[null] at
org.apache.james.mailbox.events.RabbitMQEventBusTest$LifeCycleTest$MultiEventBus.registrationsShouldNotHandleEventsAfterStop(RabbitMQEventBusTest.java:568)
{code}
We should first disable this test to have a green build back then fix the
instability.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-2658) Generic mailet to call an external microservice, and add extra information to an email
[
https://issues.apache.org/jira/browse/JAMES-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16762513#comment-16762513
]
Matthieu Baechler commented on JAMES-2658:
--
> async
We will tackle this in the future, async should definitely be the default. The
question is more "when" then "if".
> Email as Json
Well, I think that you missed 2 things here:
# Email complexity is not in the serialization format. BTW, there are a lot of
good MIME decoding libraries out there. Even if you can find a good JSON schema
to express an Email, you still have to understand the Email structure, and
that's the hard part.
# JMAP Json format is not a perfect solution. For example, it replaces
non-text payloads with a reference to a blob that you can query by HTTP. You
won't be able to scan attachments, extract semantic from them, etc.
My own opinion is that if you have a webservice that claims to take decision
based on an email content, parsing the raw email is probably the least of your
problems.
> LMTP
I understand very well that HTTP and Json is more widespread than LMTP but:
# I don't say we should use LMTP, I said we should try to understand how it
works, what people say about it, etc
# It's easy to provide a webservice that consumes a public API (here the
public API would be JSON schema) but it's harder to maintain this public API in
the long run because you will need to maintain API stability for some time.
Having a complete and definitive format (RFC 2822 MIME) has a lot of value in
that perspective that a crafted Json schema does not.
Let's take some time to study that part further and build our opinion on top of
actual knowledge of the domain.
> Generic mailet to call an external microservice, and add extra information to
> an email
> --
>
> Key: JAMES-2658
> URL: https://issues.apache.org/jira/browse/JAMES-2658
> Project: James Server
> Issue Type: Wish
>Reporter: Michael Bailly
>Priority: Minor
>
> Hello team. This is a Request For Comments for a feature, to be able to add
> extra information to an email on delivery to a local mailbox.
> h2. Principle
> the mailet calls a remote webservice, with a pre-specified payload. It gets
> back, either an error, or another specific payload. This payload can instruct
> the James server to add informations to the email. The first case, that we
> handle here, is to add extra headers.
>
> h2. Implementation
> OK, I'll try to map the mailet syntax, but I'll make mistakes, it's to
> illustrate the principle.
> James configuration:
> {{ endpoint="https://server.com/api/infos"; />}}
> Seeing this, the mailer issues a POST on {{[https://server.com/api/infos]}}
> with the following payload structure:
> {
> {{ "messageId" : "messageId",}}
> {{ "from" : {}}
> {{ "address" : "f...@test.com",}}
> {{ "personal" : "first_name last_name"}}
> {{ },}}
> {{ "to" : [ {}}
> {{ "address" : "t...@test.com",}}
> {{ "personal" : "first_name last_name of to1"}}
> {{ } ],}}
> {{ "cc" : [ {}}
> {{ "address" : "c...@test.com",}}
> {{ "personal" : null}}
> {{ }, {}}
> {{ "address" : "c...@test.com",}}
> {{ "personal" : "first_name last_name of cc2"}}
> {{ }, {}}
> {{ "address" : "c...@test.com",}}
> {{ "personal" : "first_name last_name of cc3"}}
> {{ } ],}}
> {{ "bcc" : [ ],}}
> {{ "Received" : "Mon, 28 Jan 2019 07:56:43 +",}}
> {{ "Date" : "Mon, 28 Jan 2019 07:56:43 +",}}
> {{ "in-Reply-To" : "messageId_in_reply_to",}}
> {{ "subject" : "IMPORTANT: Testing The Priority Inbox",}}
> {{ "body" : "\nDear, \n\n this a test of the priority inbox\n
> regards,\nfirst_name last_name\nDirector Tester",}}
> {{ "attachments" : [{}}
> {{ "file_size" : "243534",}}
> {{ "content_name" : "presentation.pdf",}}
> {{ "content_type" : "APPLICATION/PDF"}}
> {{ }, {}}
> {{ "file_size": "243534",}}
> {{ "content_type" : "APPLICATION/PDF",}}
> {{ "content_name" : "performance.pdf"}}
> {{ }],}}
> {{ "emailFolder" : "INBOX",}}
> {{ "user" : "first_name last_name of to1",}}
> {{ "alternativeAddress" : [ "t...@test.com",
> "first_name.last_n...@test.com" ],}}
> {{ "X-Spam-Flag" : "NO"}}
> {{}}}
> Worth noting: all those attributes are JSON formatting of an email contents,
> EXCEPT:
> * emailFolder : the destination folder of the email
> * user & alternativeAddress : the user the email is delivered to
> This mailet expects a specific format for the response. Here is a proposal:
> 1/ "bypass" (do nothing)
> {{{}}}
> 2/ "add headers"
> {
> "addHeaders": [
> {name: "X-INFO1", value: "some header value"},
> \{name: "X-INFO1-SCORE", value: "0.4"}
> ]
> }
> h3. Handling failure
> The mailet may support a specific attr
[jira] [Commented] (JAMES-2658) Generic mailet to call an external microservice, and add extra information to an email
[
https://issues.apache.org/jira/browse/JAMES-2658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16762459#comment-16762459
]
Matthieu Baechler commented on JAMES-2658:
--
Thank you for your proposal Michael.
I'll try to answer to some questions and add some comments.
> Where to send email on failure, if the "on-failure" attribute is not "ignore".
This is a easy one: it goes to specific mailrepository, waiting for
administrator action.
> retries
I would rather propose a exponential backoff strategy with the usual
parameters: initial delay and multiplier
> async
What does it mean to be async ? we can't go ahead with the mailet pipeline
anyway because it's supposed to be sequencial.
> about service return value
Are you sure we always want to _add_ headers ? I mean, a given Header can have
several values, if you only keep adding headers, you won't be able to _replace_
some value. WDYT ?
> emailFolder
There's a lot of chance you don't have the delivery folder for a given email.
This property is usually set very late in the pipeline. So either you ensure
you always call the service at this point (I mean, the pipeline probably took
most of the decisions at this point, limiting what this new mailet can do) or
you don't expect it. WDYT ?
> Email as JSON
For now, we tried to not formalize a Email as Json format because we don't
really want to be locked by this format and AFAIK, there's no standard for
that. Why do you think sending the mail as a not-standard-json is better than
passing the raw RFC 2822 Email ?
> How often it gets call
Do you want the microservice to be called for each email recipient or only once
for a given mail ?
> Performance
Implementation of this mailet could very well degrade the reception rate of
James because we have a synchronous 1 thread per mail model. So, a blocking
HTTP call is just wasted time when looking at performance consideration. Even
more if you have to start retrying.
> LMTP
All in all, it looks like you reinvented LMTP with Mailet+HTTP. It's not bad to
reinvent, it's probably useful but we could start by understanding LMTP before
going ahead with something new, learning for decades of experience in that
domain.
> Generic mailet to call an external microservice, and add extra information to
> an email
> --
>
> Key: JAMES-2658
> URL: https://issues.apache.org/jira/browse/JAMES-2658
> Project: James Server
> Issue Type: Wish
>Reporter: Michael Bailly
>Priority: Minor
>
> Hello team. This is a Request For Comments for a feature, to be able to add
> extra information to an email on delivery to a local mailbox.
> h2. Principle
> the mailet calls a remote webservice, with a pre-specified payload. It gets
> back, either an error, or another specific payload. This payload can instruct
> the James server to add informations to the email. The first case, that we
> handle here, is to add extra headers.
>
> h2. Implementation
> OK, I'll try to map the mailet syntax, but I'll make mistakes, it's to
> illustrate the principle.
> James configuration:
> {{ endpoint="https://server.com/api/infos"; />}}
> Seeing this, the mailer issues a POST on {{[https://server.com/api/infos]}}
> with the following payload structure:
> {
> {{ "messageId" : "messageId",}}
> {{ "from" : {}}
> {{ "address" : "f...@test.com",}}
> {{ "personal" : "first_name last_name"}}
> {{ },}}
> {{ "to" : [ {}}
> {{ "address" : "t...@test.com",}}
> {{ "personal" : "first_name last_name of to1"}}
> {{ } ],}}
> {{ "cc" : [ {}}
> {{ "address" : "c...@test.com",}}
> {{ "personal" : null}}
> {{ }, {}}
> {{ "address" : "c...@test.com",}}
> {{ "personal" : "first_name last_name of cc2"}}
> {{ }, {}}
> {{ "address" : "c...@test.com",}}
> {{ "personal" : "first_name last_name of cc3"}}
> {{ } ],}}
> {{ "bcc" : [ ],}}
> {{ "Received" : "Mon, 28 Jan 2019 07:56:43 +",}}
> {{ "Date" : "Mon, 28 Jan 2019 07:56:43 +",}}
> {{ "in-Reply-To" : "messageId_in_reply_to",}}
> {{ "subject" : "IMPORTANT: Testing The Priority Inbox",}}
> {{ "body" : "\nDear, \n\n this a test of the priority inbox\n
> regards,\nfirst_name last_name\nDirector Tester",}}
> {{ "attachments" : [{}}
> {{ "file_size" : "243534",}}
> {{ "content_name" : "presentation.pdf",}}
> {{ "content_type" : "APPLICATION/PDF"}}
> {{ }, {}}
> {{ "file_size": "243534",}}
> {{ "content_type" : "APPLICATION/PDF",}}
> {{ "content_name" : "performance.pdf"}}
> {{ }],}}
> {{ "emailFolder" : "INBOX",}}
> {{ "user" : "first_name last_name of to1",}}
> {{ "alternativeAddress" : [ "t...@test.com",
> "first_name.last_n...@test.com" ]
