Re: Result of Proof Of Concept for Redis Event bus user notifications

2024-02-29 Thread Maksim Meliashchuk 
Hello! I'm interested in this topic. I prefer to consider the subtleties
that experts talk about. If there is an opinion that it is not desirable to
expand the use of Redis, then
https://issues.apache.org/jira/browse/JAMES-3956 can be closed. But if
anyone can provide assistance in defining the task and decomposing it, then
I may continue to do something extra for notifications/registration.

ср, 28 февр. 2024 г. в 20:59, Benoit TELLIER :

> Hello Quan,
>
> Thanks a lot for this work. It is very encouraging.
>
> Having the whole eventbus based on Redis is IMO however not a good idea.
>
> For notifications / registration being best effort will be OK however
> RabbitMQ quorum queues address reliability issues. Going fully away of
> RabbitMQ for work queue patterns in favor of Redis is IMO not desirable.
>
> Best regards,
>
> Benoit TELLIER
>
> On 28/02/2024 10:08, Quan tran hong wrote:
> > Hi folks,
> >
> > Following the context of the Jira ticket JAMES-3996 POC: Move RabbitMQ
> > Event bus user notifications to Redis
> > <
> https://issues.apache.org/jira/projects/JAMES/issues/JAMES-3996?filter=allopenissues
> >
> > (TLDR:
> > we observed some annoying issues with RabbitMQ in a deployment and we
> think
> > it could be better to move at least the user notifications part of Event
> > Bus to Redis), I did a Proof Of Concept about that in the PR JAMES 3996
> > Redis event bus POC .
> >
> > The POC is considered done to me, and I want to share the POC result to
> > James devs:
> > - It is *possible *(the POC worked!) to replace the Event bus user
> > notifications (key registration) using Redis Pub/Sub. And likely the
> whole
> > EventBus (the group registration part as well) can rely on Redis (I did
> not
> > do that part).
> > - I did several performance tests for the POC, and the results were
> *good*.
> > Regarding the metrics of Event Bus user notifications, Redis seems to
> > outperform and show more stability in response time than RabbitMQ. (For
> > more details, I shared on the PR)
> >
> > Despite the POC has been worked and shown some prospects, I think we
> should
> > monitor it more carefully before applying it to James. Therefore, we
> > (Linagora) would adopt the Redis Event bus user notifications first in
> our
> > TMail project (based on James). We would keep an eye on its stability
> > before contributing the fine-tuned work toward James.
> >
> > By the way, it seems someone from the community is interested in building
> > the whole EventBus using Redis cf
> > https://issues.apache.org/jira/browse/JAMES-3956. This POC could be a
> start
> > for that Redis EventBus.
> >
> > What do you think about using Redis for EventBus? Would that sound
> > interesting to you?
> >
> > Regards,
> >
> > Quan
> >
>
> -
> To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org
> For additional commands, e-mail: server-dev-h...@james.apache.org
>
>

[jira] [Created] (JAMES-4015) VacationMailet fails on some reply-to

2024-02-29 Thread Benoit Tellier (Jira) 
Benoit Tellier created JAMES-4015:
-

 Summary: VacationMailet fails on some reply-to
 Key: JAMES-4015
 URL: https://issues.apache.org/jira/browse/JAMES-4015
 Project: James Server
  Issue Type: Bug
  Components: JMAP, Mailet Contributions
Reporter: Benoit Tellier
Assignee: Antoine Duprat


{code:java}
javax.mail.internet.AddressException: Extra route-addr
at javax.mail.internet.InternetAddress.parse(InternetAddress.java:858)
at 
javax.mail.internet.InternetAddress.parseHeader(InternetAddress.java:777)
at 
javax.mail.internet.MimeMessage.getAddressHeader(MimeMessage.java:756)
at javax.mail.internet.MimeMessage.getReplyTo(MimeMessage.java:730)
at 
org.apache.james.transport.mailets.VacationMailet.service(VacationMailet.java:72)
{code}

We can likely attempt to use mime4J to a have a more lenient parsing?




--
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-4014) Cannot Email/set destroy with twice the same id

2024-02-29 Thread Benoit Tellier (Jira) 
Benoit Tellier created JAMES-4014:
-

 Summary: Cannot Email/set destroy with twice the same id
 Key: JAMES-4014
 URL: https://issues.apache.org/jira/browse/JAMES-4014
 Project: James Server
  Issue Type: Bug
  Components: cassandra, JMAP
Affects Versions: master, 3.8.0
Reporter: Benoit Tellier
Assignee: Antoine Duprat
 Fix For: 3.9.0


When using the Cassandra backend


{code:java}
java.lang.IllegalArgumentException: Multiple entries with same key: 
org.apache.james.mailbox.MetadataWithMailboxId@25f2478=org.apache.james.mailbox.model.MessageMetaData@2bf16090
 and 
org.apache.james.mailbox.MetadataWithMailboxId@25f2478=org.apache.james.mailbox.model.MessageMetaData@c4079465
at 
com.google.common.collect.ImmutableMap.conflictException(ImmutableMap.java:378)
at com.google.common.collect.ImmutableMap.checkNoConflict(ImmutableMap.java:372)
at 
com.google.common.collect.RegularImmutableMap.checkNoConflictInKeyBucket(RegularImmutableMap.java:246)
at 
com.google.common.collect.RegularImmutableMap.fromEntryArrayCheckingBucketOverflow(RegularImmutableMap.java:133)
at 
com.google.common.collect.RegularImmutableMap.fromEntryArray(RegularImmutableMap.java:95)
at com.google.common.collect.ImmutableMap$Builder.build(ImmutableMap.java:572)
at 
com.google.common.collect.ImmutableMap$Builder.buildOrThrow(ImmutableMap.java:600)
at com.google.common.collect.ImmutableMap$Builder.build(ImmutableMap.java:587)
at java.base/java.util.stream.ReferencePipeline.collect(Unknown Source)
at 
org.apache.james.mailbox.store.StoreMessageIdManager.deleteWithPreHooks(StoreMessageIdManager.java:281)
at 
org.apache.james.mailbox.store.StoreMessageIdManager.deleteInAllowedMailboxes(StoreMessageIdManager.java:272)
at 
org.apache.james.mailbox.store.StoreMessageIdManager.lambda$delete$12(StoreMessageIdManager.java:259)
at reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:132)
at 
reactor.core.publisher.Operators$BaseFluxToMonoOperator.completePossiblyEmpty(Operators.java:2097)\n\tat
 
reactor.core.publisher.MonoStreamCollector$StreamCollectorSubscriber.onComplete(MonoStreamCollector.java:159)\n\tat
 
reactor.core.publisher.FluxFilterWhen$FluxFilterWhenSubscriber.drain(FluxFilterWhen.java:236)\n\tat
 
reactor.core.publisher.FluxFilterWhen$FluxFilterWhenSubscriber.innerResult(FluxFilterWhen.java:369)\n\tat
 
reactor.core.publisher.FluxFilterWhen$FilterWhenInner.onNext(FluxFilterWhen.java:450)\n\tat
 
reactor.core.publisher.FluxFilterWhen$FilterWhenInner.onNext(FluxFilterWhen.java:414)\n\tat
 
reactor.core.publisher.FluxOnErrorResume$ResumeSubscriber.onNext(FluxOnErrorResume.java:79)\n\tat
 reactor.core.publisher.FluxMap$MapSubscriber.onNext(FluxMap.java:122)\n\tat 
reactor.core.publisher.FluxMap$MapSubscriber.onNext(FluxMap.java:122)\n\tat 
reactor.core.publisher.FluxSwitchIfEmpty$SwitchIfEmptySubscriber.onNext(FluxSwitchIfEmpty.java:74)\n\tat
 reactor.core.publisher.MonoZip$ZipCoordinator.signal(MonoZip.java:297)\n\tat 
reactor.core.publisher.MonoZip$ZipInner.onNext(MonoZip.java:478)\n\tat 
reactor.core.publisher.MonoFlatMap$FlatMapMain.secondComplete(MonoFlatMap.java:245)\n\tat
 
reactor.core.publisher.MonoFlatMap$FlatMapInner.onNext(MonoFlatMap.java:305)\n\tat
 
reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onNext(FluxMapFuseable.java:129)\n\tat
 
reactor.core.publisher.Operators$ScalarSubscription.request(Operators.java:2571)\n\tat
 
reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.request(FluxMapFuseable.java:171)\n\tat
 
reactor.core.publisher.MonoFlatMap$FlatMapInner.onSubscribe(MonoFlatMap.java:291)\n\tat
 
reactor.core.publisher.FluxMapFuseable$MapFuseableSubscriber.onSubscribe(FluxMapFuseable.java:96)\n\tat
 reactor.core.publisher.MonoJust.subscribe(MonoJust.java:55)\n\tat 
reactor.core.publisher.InternalMonoOperator.subscribe(InternalMonoOperator.java:76)\n\tat
 
reactor.core.publisher.MonoFlatMap$FlatMapMain.onNext(MonoFlatMap.java:165)\n\tat
 
reactor.core.publisher.FluxOnErrorResume$ResumeSubscriber.onNext(FluxOnErrorResume.java:79)\n\tat
 reactor.core.publisher.MonoNext$NextSubscriber.onNext(MonoNext.java:82)\n\tat 
com.datastax.dse.driver.internal.core.cql.reactive.ReactiveResultSetSubscription.doOnNext(ReactiveResultSetSubscription.java:364)\n\tat
 
com.datastax.dse.driver.internal.core.cql.reactive.ReactiveResultSetSubscription.drain(ReactiveResultSetSubscription.java:236)\n\tat
 
com.datastax.dse.driver.internal.core.cql.reactive.ReactiveResultSetSubscription.lambda$fetchNextPageAndEnqueue$2(ReactiveResultSetSubscription.java:358)\n\tat
 java.base/java.util.concurrent.CompletableFuture$UniAccept.tryFire(Unknown 
Source)\n\tat 
java.base/java.util.concurrent.CompletableFuture.postComplete(Unknown 
Source)\n\tat java.base/java.util.concurrent.CompletableFuture.complete(Unknown 
Source)\n\tat 
com.datastax.oss.driver.internal.core.cql.CqlR