[jira] [Created] (JAMES-4004) Allow retries for S3 saves
René Cordier created JAMES-4004: --- Summary: Allow retries for S3 saves Key: JAMES-4004 URL: https://issues.apache.org/jira/browse/JAMES-4004 Project: James Server Issue Type: Improvement Affects Versions: 3.8.0, 3.8.1 Reporter: René Cordier Fix For: 3.9.0 Adding retries for S3 blob store saving can help in case network is not reliable -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-4003) Avoid forwarding bounces as it might create infinite loops
René Cordier created JAMES-4003: --- Summary: Avoid forwarding bounces as it might create infinite loops Key: JAMES-4003 URL: https://issues.apache.org/jira/browse/JAMES-4003 Project: James Server Issue Type: Bug Reporter: René Cordier Destination service might consider Header from do not match sender envelop and reject with a bounce. This creates an infinite loop. Real fix: do like outlook... For local domains: like today. For remote domains: Wrap the forwarded message in a nested mime part, set subject to the value of the mail. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Resolved] (JAMES-4001) File buffering for message storage
[ https://issues.apache.org/jira/browse/JAMES-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] René Cordier resolved JAMES-4001. - Resolution: Fixed https://github.com/apache/james-project/pull/2019 was merged > File buffering for message storage > -- > > Key: JAMES-4001 > URL: https://issues.apache.org/jira/browse/JAMES-4001 > Project: James Server > Issue Type: Improvement >Affects Versions: 3.8.0, 3.8.1 >Reporter: René Cordier >Priority: Major > Fix For: 3.9.0 > > > Implementing a File buffering for message storage might allow to reduce > memory pressure on IMAP APPEND command -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Updated] (JAMES-4001) File buffering for message storage
[ https://issues.apache.org/jira/browse/JAMES-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] René Cordier updated JAMES-4001: Summary: File buffering for message storage (was: File buffering for message storer) > File buffering for message storage > -- > > Key: JAMES-4001 > URL: https://issues.apache.org/jira/browse/JAMES-4001 > Project: James Server > Issue Type: Improvement >Affects Versions: 3.8.0, 3.8.1 >Reporter: René Cordier >Priority: Major > Fix For: 3.9.0 > > > Implementing a File buffering for message storage might allow to reduce > memory pressure on IMAP APPEND command -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-4001) File buffering for message storer
René Cordier created JAMES-4001: --- Summary: File buffering for message storer Key: JAMES-4001 URL: https://issues.apache.org/jira/browse/JAMES-4001 Project: James Server Issue Type: Improvement Affects Versions: 3.8.0, 3.8.1 Reporter: René Cordier Fix For: 3.9.0 Implementing a File buffering for message storage might allow to reduce memory pressure on IMAP APPEND command -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-3995) Optimize Email/get method
[ https://issues.apache.org/jira/browse/JAMES-3995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17818340#comment-17818340 ] René Cordier commented on JAMES-3995: - https://github.com/apache/james-project/pull/2024 ([FIX] Add a max number of items for EmailGet full reads) helps optimizing Email/get JMAP method as well > Optimize Email/get method > - > > Key: JAMES-3995 > URL: https://issues.apache.org/jira/browse/JAMES-3995 > Project: James Server > Issue Type: Improvement >Affects Versions: 3.8.1 >Reporter: René Cordier >Priority: Major > Fix For: 3.9.0 > > > For Email/get, we seem to buffer body binary parts using Mime4J to be able to > recalculate the size of the part. > This causes James to consume a very high amount of memory, which can cause > performance issues if there is too many of those. > We should try to find a way to avoid buffering the binary parts in order to > save memory, and boost performance for Email/get JMAP method. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-4000) JMAP should guess charset of text parts when missing
René Cordier created JAMES-4000:
---
Summary: JMAP should guess charset of text parts when missing
Key: JAMES-4000
URL: https://issues.apache.org/jira/browse/JAMES-4000
Project: James Server
Issue Type: Improvement
Affects Versions: 3.8.0, 3.8.1
Reporter: René Cordier
Fix For: 3.9.0
Attachments: jmap-charset-missing.png
Given an email with a text part without charset
{code:java}
=_1706602778-31669-7
Content-Type: text/plain; name="avertissement.txt"
Content-Disposition: inline; filename="avertissement.txt"
Content-Transfer-Encoding: base64
Q2UgbWVzc2FnZSDpbGVjdHJvbmlxdWUgZXQgdG91cyBsZXMgZmljaGllcnMgYXR0YWNo6XMgcXUn
aWwgY29udGllbnQgc29udCBjb25maWRlbnRpZWxzIGV0IGRlc3RpbulzIGV4Y2x1c2l2ZW1lbnQg
{code}
Today James fails at rendering this properly (cf attachment)
This is because we uses `US_ASCII` as a default when no charset is specified.
Suggestion: we should rather "guess" the charset when that's the case:
[https://github.com/albfernandez/juniversalchardet]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-3999) Listener: define priority and apply priority
René Cordier created JAMES-3999: --- Summary: Listener: define priority and apply priority Key: JAMES-3999 URL: https://issues.apache.org/jira/browse/JAMES-3999 Project: James Server Issue Type: Improvement Affects Versions: 3.8.0, 3.8.1 Reporter: René Cordier Fix For: 3.9.0 Some listener should be executed quicklier than others. This is paramount to ensure best effort upon resynchronisation. The idea would be to prioritize in the execution order listeners that have a higher priority to avoid causing delays. JMAP listener especially (EmailQueryView, MailboxChange) should be executed with the highest priority possible. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-3998) Empty password for IMAP login should not lead to worrying error log
René Cordier created JAMES-3998: --- Summary: Empty password for IMAP login should not lead to worrying error log Key: JAMES-3998 URL: https://issues.apache.org/jira/browse/JAMES-3998 Project: James Server Issue Type: Improvement Affects Versions: 3.8.0, 3.8.1 Reporter: René Cordier Fix For: 3.9.0 We have spotted that in James logs, if the user is putting an empty password when trying to login via IMAP, it fails with an error. It is not a system error, but on an issue on the user input, like for a wrong password. It should be an info or warn log, not an error one. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-3997) Netty backpressure for IMAP Fetch
René Cordier created JAMES-3997:
---
Summary: Netty backpressure for IMAP Fetch
Key: JAMES-3997
URL: https://issues.apache.org/jira/browse/JAMES-3997
Project: James Server
Issue Type: Improvement
Affects Versions: 3.8.0, 3.8.1
Reporter: René Cordier
Fix For: 3.9.0
Some OOM IMAP issues on a production environment using James have been
detected, regarding the method IMAP FETCH.
We seem to do to write out:
{code:java}
channel.writeAndFlush()Unpooled.wrappedBuffer(buffer));
{code}
without any checks. Making the method using intermediate buffers in a slow
network, potentially exploding the memory.
Need to investigate this issue and enhance this processus, maybe by using Netty
backpressure instead?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-3996) POC: Move RabbitMQ Event bus notifications to Redis?
René Cordier created JAMES-3996:
---
Summary: POC: Move RabbitMQ Event bus notifications to Redis?
Key: JAMES-3996
URL: https://issues.apache.org/jira/browse/JAMES-3996
Project: James Server
Issue Type: Improvement
Reporter: René Cordier
In a setup with a RabbitMQ cluster, and quorum queues, we observed that if
Cassandra was unavailable for some reason, heavy nacks causing very high absurd
traffic with heavy memory usage, creating overall issues with the event bus in
general.
Here the goal would be to investigate if it's possible to use Redis instead of
RabbitMQ for delegating the user notifications. Might use Redis pub-sub or
streams to achieve this, by registering the event listeners on Redis instead of
RabbitMQ.
Concerned code on RabbitMQ event bus:
{code:java}
default Publisher register(EventListener listener,
RegistrationKey key) \{
return register(EventListener.wrapReactive(listener), key);
}
Publisher register(EventListener.ReactiveEventListener
listener, RegistrationKey key);
default Publisher
register(EventListener.ReactiveEventListener listener,
Collection keys) \{
return Flux.fromIterable(keys)
.concatMap(key -> register(listener, key))
.reduce((reg1, reg2) -> () -> Flux.merge(reg1.unregister(),
reg2.unregister()))
.map(unRegistrationWithMergedFlux -> () ->
Mono.from(Flux.from(unRegistrationWithMergedFlux.unregister())
.then()));
}
{code}
It's just a POC to see first if it's achievable or not, with performance tests.
If results are positive, we might envisage to integrate it in a cleaner way.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Updated] (JAMES-3996) POC: Move RabbitMQ Event bus user notifications to Redis?
[
https://issues.apache.org/jira/browse/JAMES-3996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
René Cordier updated JAMES-3996:
Summary: POC: Move RabbitMQ Event bus user notifications to Redis? (was:
POC: Move RabbitMQ Event bus notifications to Redis?)
> POC: Move RabbitMQ Event bus user notifications to Redis?
> -
>
> Key: JAMES-3996
> URL: https://issues.apache.org/jira/browse/JAMES-3996
> Project: James Server
> Issue Type: Improvement
>Reporter: René Cordier
>Priority: Major
>
> In a setup with a RabbitMQ cluster, and quorum queues, we observed that if
> Cassandra was unavailable for some reason, heavy nacks causing very high
> absurd traffic with heavy memory usage, creating overall issues with the
> event bus in general.
> Here the goal would be to investigate if it's possible to use Redis instead
> of RabbitMQ for delegating the user notifications. Might use Redis pub-sub or
> streams to achieve this, by registering the event listeners on Redis instead
> of RabbitMQ.
> Concerned code on RabbitMQ event bus:
> {code:java}
> default Publisher register(EventListener listener,
> RegistrationKey key) \{
> return register(EventListener.wrapReactive(listener), key);
> }
> Publisher register(EventListener.ReactiveEventListener
> listener, RegistrationKey key);
> default Publisher
> register(EventListener.ReactiveEventListener listener,
> Collection keys) \{
> return Flux.fromIterable(keys)
> .concatMap(key -> register(listener, key))
> .reduce((reg1, reg2) -> () -> Flux.merge(reg1.unregister(),
> reg2.unregister()))
> .map(unRegistrationWithMergedFlux -> () ->
> Mono.from(Flux.from(unRegistrationWithMergedFlux.unregister())
> .then()));
> }
> {code}
> It's just a POC to see first if it's achievable or not, with performance
> tests. If results are positive, we might envisage to integrate it in a
> cleaner way.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Commented] (JAMES-3995) Optimize Email/get method
[ https://issues.apache.org/jira/browse/JAMES-3995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17818332#comment-17818332 ] René Cordier commented on JAMES-3995: - Started working on it here: https://github.com/apache/james-project/pull/2005 > Optimize Email/get method > - > > Key: JAMES-3995 > URL: https://issues.apache.org/jira/browse/JAMES-3995 > Project: James Server > Issue Type: Improvement >Affects Versions: 3.8.1 >Reporter: René Cordier >Priority: Major > Fix For: 3.9.0 > > > For Email/get, we seem to buffer body binary parts using Mime4J to be able to > recalculate the size of the part. > This causes James to consume a very high amount of memory, which can cause > performance issues if there is too many of those. > We should try to find a way to avoid buffering the binary parts in order to > save memory, and boost performance for Email/get JMAP method. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[jira] [Created] (JAMES-3995) Optimize Email/get method
René Cordier created JAMES-3995: --- Summary: Optimize Email/get method Key: JAMES-3995 URL: https://issues.apache.org/jira/browse/JAMES-3995 Project: James Server Issue Type: Improvement Affects Versions: 3.8.1 Reporter: René Cordier Fix For: 3.9.0 For Email/get, we seem to buffer body binary parts using Mime4J to be able to recalculate the size of the part. This causes James to consume a very high amount of memory, which can cause performance issues if there is too many of those. We should try to find a way to avoid buffering the binary parts in order to save memory, and boost performance for Email/get JMAP method. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
[BUILD-FAILURE]: Job 'james/ApacheJames/master [master] [1261]'
BUILD-FAILURE: Job 'james/ApacheJames/master [master] [1261]': Check console output at "https://ci-builds.apache.org/job/james/job/ApacheJames/job/master/1261/";>james/ApacheJames/master [master] [1261]" - To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
