JAMES-4200 ActiveMQ: add a configuration option for adjusting usage l…

[Arsnael]

…imits

If hardcoded to false, it can lead to test failing depending on local limits set by the user's system.

[Arsnael]

@ouvtam Hi can you have a look possibly please?

Following your contribution here: #2996 I can't run the tests using the embedded activemq anymore, it breaks for me locally. I get the following:

[INFO] Running com.linagora.tmail.james.app.EncryptedPostgresTmailServerTest
18:26:22.992 [ERROR] o.a.a.b.BrokerService - Store limit is 102400 mb (current store usage is 0 mb). The data directory: /tmp/junit644828954926870502/junit10265229264622891642/var/store/activemq/brokers/KahaDB only has 82111 mb of usable space.

Maybe docker locally doesnt allow me that much space. I think this should be an option. I put it to true by default, for not breaking existing running envs. So you have to set it up to false to not auto adjust usage limits.

Is it ok for you? Up to discussion :)

[quantranhong1999]

org.apache.james.app.spring.JamesAppSpringMainTest.testServer

Error Message
Error creating bean with name 'mailqueuefactory' defined in class path resource [META-INF/spring/activemq-queue-context.xml]: Cannot resolve reference to bean 'embeddedActiveMQ' while setting constructor argument

seems related.

[quantranhong1999]

I put it to true by default, for not breaking existing running envs.

+1 to revert it back to the existing behavior. It seems using adjustUsageLimits=false couples the memory fix to disk-limit startup semantics

So you have to set it up to false to not auto adjust usage limits.

It seems the best way to resolve prevent the embedded broker to claim up to 70% of JVM memory that might cause memory drain of James (from PR #2996) should have been to configure ActiveMQ's memory usage instead:

brokerService.getSystemUsage().getMemoryUsage().setLimit(...);

// and optionally
brokerService.getSystemUsage().getStoreUsage().setLimit(...);
brokerService.getSystemUsage().getTempUsage().setLimit(...);

[ouvtam]

I reproduced the bug in the tests which use the BrokerExtension and could fix it by setting a low fixed amount of resources.

broker.setAdjustUsageLimits(false);
broker.getSystemUsage().getMemoryUsage().setLimit(1024L * 1024 * 128); // 128 MB
broker.getSystemUsage().getTempUsage().setLimit(1024L * 1024 * 128); // 128 MB
broker.getSystemUsage().getStoreUsage().setLimit(1024L * 1024 * 128); // 128 MB
broker.getSystemUsage().getJobSchedulerUsage().setLimit(1024L * 1024 * 128); // 128 MB

The defaults are quite high, though:

systemUsage.getMemoryUsage().setLimit(1024L * 1024 * 1024 * 1); // 1 GB
systemUsage.getTempUsage().setLimit(1024L * 1024 * 1024 * 50); // 50 GB
systemUsage.getStoreUsage().setLimit(1024L * 1024 * 1024 * 100); // 100 GB
systemUsage.getJobSchedulerUsage().setLimit(1024L * 1024 * 1024 * 50); // 50 GB

In your case you hit the 100GB mark. What are sane defaults?