Push Publish HTTP client has no explicit timeouts

Problem Statement

Push Publish outbound HTTP uses a Jersey client without explicit connect/read timeouts, so requests can hang too long under network degradation. This impacts operators and editors waiting for publish completion, especially in multi-endpoint environments. Severity is high because it can stall critical content delivery workflows.

Steps to Reproduce

Configure a Push Publish endpoint that accepts TCP connection but responds very slowly or intermittently.
Trigger push publish for a bundle to that endpoint.
Observe delayed/stuck behavior and lack of deterministic timeout boundary in push execution.

Acceptance Criteria

Connect and read timeouts are explicitly configured for Push Publish HTTP calls.
Timeout values are configurable through dotCMS config properties with safe defaults.
Audit/log output clearly shows timeout failures vs generic send failures.

dotCMS Version

26.03+

Severity

Medium - Some functionality impacted

Links

NA

Start by locating the Push Publish Jersey client and the configuration properties used by its outbound HTTP calls. Trace the existing audit or send-failure logging, then verify that connect and read timeouts are configurable with safe defaults and that timeout failures are distinguishable from generic send failures.