[ https://issues.apache.org/jira/browse/JAMES-3306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17509567#comment-17509567 ]
Benoit Tellier commented on JAMES-3306: --------------------------------------- Hello Ha Anh! > I'm a GSOC student interested in the Apache James project. This sounds cool! Around here we have experience mentoring GSOC students and are willing to keep doing so! What kind of topics would you be interested at? Out of my head... - https://issues.apache.org/jira/browse/JAMES-1933 DMARC support - https://issues.apache.org/jira/browse/JAMES-1931 Web UI for webadmin (if you want to be doing JavaScript) - https://issues.apache.org/jira/browse/JAMES-3695 Work with Apache Pulsar messaging service - Suggestions of your own. > In the meantime, I'm looking for beginner-friendly issues to fix to better > understand the codebase. Very bood initiative! This is definitly something we would feel sensible to! > Since this issue seems short-term and not too big and also somewhat related > to the GSOC project, can I give it a shot to better understand the codebase? Sure. Sadly I believe this issue is no longer relevant... We changed the messaging model to group the initial event delivery to limit the messaging event overhead, which was massive. This means we can hardly control concurrency on a per-event listener basis. Reactive programming enables further more concurrency control on the component level. As such I believe this issue do not make sense and should likely be closed. Instead you could have a look at one of the many pulsar pull request: https://issues.apache.org/jira/browse/JAMES-3695?jql=project%20%3D%20JAMES%20AND%20resolution%20%3D%20Unresolved%20AND%20text%20~%20%22pulsar%22%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC On the easiest there: - https://issues.apache.org/jira/browse/JAMES-3703 Implement a BlobReferenceSource backing the Pulsar mail queue - https://issues.apache.org/jira/browse/JAMES-3700 Not crashing on non-handlable message is a good candidate too. I also would like to draw attention to the overall timeline: Ideally we should be able to validate and offer mentoring around ~4th of April which implies that we should be confident regarding your motivation, and that you chose a topic ;-) Regards, Benoit TELLIER > Event Bus: about back-pressure > ------------------------------ > > Key: JAMES-3306 > URL: https://issues.apache.org/jira/browse/JAMES-3306 > Project: James Server > Issue Type: New Feature > Components: eventbus, mailbox, rabbitmq > Affects Versions: master > Reporter: Benoit Tellier > Priority: Major > > == Why > On UPN we prove thatwe were processing events too fast compared to the > downstream ElasticSearch > In a perfect world, we should handle backpressure in order to adapt event > consumption to the downstream components. > In the short term an admin should be able to define the paralelism expected > for a given group, in order to reduce overhead. > == How > QOS is currently hard coded via the EventBus::EXECUTION_RATE variable. Allow > to configure it in listeners.xml on a per listener basis. > == DOD > Enable to configure QOS on a per listener basis. -- This message was sent by Atlassian Jira (v8.20.1#820001) --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org