Simple Java Mail currently has one property-backed connection-pool / cluster configuration active for batch-module sending:
simplejavamail.defaults.connectionpool.clusterkey.uuid=...
simplejavamail.defaults.connectionpool.coresize=...
simplejavamail.defaults.connectionpool.maxsize=...
simplejavamail.defaults.connectionpool.claimtimeout.millis=...
simplejavamail.defaults.connectionpool.expireafter.millis=...
simplejavamail.defaults.connectionpool.loadbalancing.strategy=...
That works for a single default cluster, but it does not model applications that are configured entirely through properties and need multiple batch clusters with different pool behavior.
Concept to investigate:
- keep the existing properties as global/default fallback behavior
- add a collection-style property model keyed by cluster key or cluster alias
- allow cluster-specific core size, max size, claim timeout, expiry, and load-balancing settings
- keep the Java API and properties/defaults governance aligned
This is related to #565, but separate from the Java-side cluster configuration fix: the Java API can configure multiple clusters directly, while property-only applications need a richer ConfigLoader model.
Simple Java Mail currently has one property-backed connection-pool / cluster configuration active for batch-module sending:
That works for a single default cluster, but it does not model applications that are configured entirely through properties and need multiple batch clusters with different pool behavior.
Concept to investigate:
This is related to #565, but separate from the Java-side cluster configuration fix: the Java API can configure multiple clusters directly, while property-only applications need a richer ConfigLoader model.