Hi there. Chaos here it comes. Distributed :: APP is clearly slower than the other integration-test modules (17:25 vs roughly 2–7 minutes).
The most suspicious issue is the repeated ActiveMQ/JMS errors: - jakarta.jms.IllegalStateException: The Session is closed - repeated rollback() / deQueueOneItem() retries - InterruptedException inside ActiveMQ's VMTransport / LinkedBlockingQueue This suggests a problematic JMS/ActiveMQ session lifecycle, potentially causing retries, blocking, and unnecessary waiting. However, the log does *not* prove a deadlock or that this is responsible for all 17 minutes. The other warnings, such as compile avoidance and Lucene's vector module, look secondary and are unlikely to explain such a large delay. *What I'd try first:* 1. Investigate why JMSCacheableMailQueue continues retrying after its JMS session is closed. 2. Check ActiveMQ connection/session shutdown ordering in the distributed tests. 3. Compare the same Distributed :: APP execution with a normal/previous build to identify which tests became slower. 4. Check whether the ActiveMQ errors disappear when running the affected integration tests in isolation. If the JMS errors disappear and Distributed :: APP returns to its usual runtime, that would strongly confirm the root cause. пн, 28 сент. 2026 г. в 14:21, Benoit TELLIER via server-dev < [email protected]>: > As a reference: > > We get a develocity cache which allow us to skip parts of the build > unrelated to PR changes > > > https://ci-builds.apache.org/job/james/job/ApacheJames/view/change-requests/job/PR-3198/33/execution/node/88/log/ > is > an exemple of a build triggering some long tests > > 04:07:06,792 [INFO] Apache James :: MPT :: Imap Mailbox :: Cassandra ... > SUCCESS [04:09 min]04:07:06,792 [INFO] Apache James :: MPT :: Imap Mailbox > :: OpenSearch .. SUCCESS [02:42 min]04:07:06,798 [INFO] Apache James :: > Server :: Distributed :: APP ....... SUCCESS [17:25 min]04:07:06,798 [INFO] > Apache James :: Server :: Cli :: Integration tests . SUCCESS [03:26 > min]04:07:06,800 [INFO] Apache James :: Server :: Mailet :: Integration > Testing SUCCESS [02:36 min]04:07:06,800 [INFO] Apache James :: Server :: > Remote Delivery :: Integration Testing SUCCESS [03:09 min]04:07:06,800 > [INFO] Apache James :: Server :: JMAP RFC-8621 :: Distributed Integration > Testing SUCCESS [04:25 min]04:07:06,800 [INFO] Apache James :: Server :: > Web Admin server integration tests :: Distributed SUCCESS [06:36 > min]04:07:06,800 [INFO] Apache James :: Third Party :: SpamAssassin > ........ SUCCESS [03:12 min]04:07:06,801 [INFO] Apache James :: MPT :: Imap > Mailbox :: Postgres .... SUCCESS [04:07 min]04:07:06,801 [INFO] Apache > James :: Server :: Postgres - Application ... SUCCESS [03:16 > min]04:07:06,802 [INFO] Apache James :: Server :: Web Admin server > integration tests :: Postgres App SUCCESS [04:10 min]04:07:06,802 [INFO] > Apache James :: Third Party :: Crowdsec ............ SUCCESS [04:10 min] > Which is just a part of what is slow. > distributed-app seems scandalously slow, more than usual.-- > > > Best regards, > > Benoit TELLIER > > General manager of Linagora VIETNAM. > Product owner for Twake-Mail product. > Chairman of the Apache James project. > > Mail: [email protected] > Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal) > > > > Le sept. 28, 2026 9:03 AM, de Maksim Meliashchuk <[email protected]>Thanks > a lot for the reply! I’m genuinely interested in general technical > challenges - sometimes even more so than in functional ones. Improving > build times sounds very interesting to me, and it involves clear criteria. > I’ll start by examining the project's current state and try to come up with > some proposals. Thanks again! > > вс, 27 сент. 2026 г. в 23:46, Benoit TELLIER via server-dev < > [email protected]>: > > > Hello Maksim, > > > > Welcome back! > > > > Functionnally speaking none I specifically have in mind. > > > > So regarding important-often-overlooked work I can think of: > > - Build time improvments. Build is too long and contribution helping get > > it under control (without harming the test suite!) would indeed help a > lot! > > - New website review: james.staged.apache.org/ > > - RabbitMQ is a pain to scale. Applicative sharding may help but hits > > limits too. Pulsar based messaging could be nice (EventBus, Task > manager). > > issues.apache.org/jira/browse/JAMES-3699 > > issues.apache.org/jira/browse/JAMES-3701 > > (and related pulsar issue) > > > > But above all, which kind of contributions would you be wishing to do? > > > > Cheers, > > > > -- > > > > > > Best regards, > > > > Benoit TELLIER > > > > General manager of Linagora VIETNAM. > > Product owner for Twake-Mail product. > > Chairman of the Apache James project. > > > > Mail: [email protected] > > Tel: (0033) 6 77 26 04 58 (WhatsApp, Signal) > > > > > > > > Le sept. 26, 2026 3:23 PM, de Maksim Meliashchuk <[email protected]>Hi > > everyone, > > > > Although I haven't had much free time recently, I've been following the > > development of Apache James and remain very interested in the project. > > > > As you may have noticed, I've contributed to the project in the past: > > github.com/apache/james-project/commits?author=Maxxx873 > > > > Unfortunately, I currently have very limited free time, but I'd still > like > > to support the project whenever I can. > > > > Could you please let me know if there are any current issues or tasks > where > > an additional contributor could help? In particular, if there are any > > suitable JIRA issues that would be a good fit for a small contribution, > I'd > > be happy to take a look. > > > > I'll do my best to help whenever I have some time. > > > > Looking forward to contributing again! > > > > Best regards, > > Max > > >
