resetConnectionPoolClaimTimeoutMillis resets connection expiry

[bbottema]

Problem

MailerGenericBuilder.resetConnectionPoolClaimTimeoutMillis() delegates to withConnectionPoolExpireAfterMillis(DEFAULT_CONNECTIONPOOL_CLAIMTIMEOUT_MILLIS) instead of resetting the connection-claim timeout.

The defect was introduced with the claim-timeout API in commit 9701d779 in 2019. It leaves a custom claim timeout unchanged and unexpectedly changes connection expiry to Integer.MAX_VALUE milliseconds.

The related documentation also describes Integer.MAX_VALUE milliseconds as an indefinite or forever wait. The downstream pool treats it as an ordinary finite timeout of approximately 24.9 days.

Expected behavior

The reset method restores only the claim timeout to DEFAULT_CONNECTIONPOOL_CLAIMTIMEOUT_MILLIS, leaving connection expiry untouched. Documentation should state the actual finite default.

Compatibility

The dedicated resetConnectionPoolExpireAfterMillis() API already restores the normal five-second expiry default. Applications intentionally relying on the old accidental long expiry can express that directly with withConnectionPoolExpireAfterMillis(Integer.MAX_VALUE).

[bbottema]

Fixed for v9.1.8. resetConnectionPoolClaimTimeoutMillis() now restores only the claim timeout and leaves connection expiry unchanged.

The existing expiry APIs cover both compatibility paths: resetConnectionPoolExpireAfterMillis() restores the five-second default, while withConnectionPoolExpireAfterMillis(Integer.MAX_VALUE) preserves the old accidental long-expiry behavior when deliberately required. Documentation now describes the default claim timeout accurately as approximately 24.9 days.

[bbottema]

Available in Simple Java Mail 9.1.8. resetConnectionPoolClaimTimeoutMillis() now restores only the claim timeout. The explicit expiry APIs remain available for either the five-second default or a deliberately long expiry.