Spring Batch XML配置下NEVER重试策略完全失效问题求助

Hey there, sorry to hear your Spring Batch retry mechanism's gone kaput—let's break this down step by step to get it working again, especially since you've already tried upgrading to the latest version. Here's a structured troubleshooting plan tailored to your XML-configured, Gradle-built legacy app:

First, let's rule out the most straightforward issues with your XML setup, since upgrading can break old config patterns:

• Verify namespaces: Spring Batch's retry relies on Spring Retry, and newer versions require explicit namespace declarations. Make sure your XML header includes:

  xmlns:retry="http://www.springframework.org/schema/retry"
  xsi:schemaLocation="http://www.springframework.org/schema/retry http://www.springframework.org/schema/retry/spring-retry.xsd"
  

• Validate chunk-level retry settings: Ensure your step's chunk explicitly lists your custom runtime exception and sets a valid retry limit. For example:

  <batch:step id="yourBusinessStep">
    <batch:tasklet>
      <batch:chunk reader="customItemReader" writer="customItemWriter" commit-interval="10">
        <batch:retry-limit value="3"/>
        <batch:retryable-exception-classes>
          <batch:include class="com.yourteam.YourCustomRuntimeException"/>
        </batch:retryable-exception-classes>
      </batch:chunk>
    </batch:tasklet>
  </batch:step>
  

• Check for deprecated attributes: If you're using a custom RetryPolicy bean, confirm the retry-policy attribute on your chunk still points to the correct bean ID—some older XML attributes might have been renamed in newer Spring Batch versions.

Retry only triggers if Spring Batch actually sees your custom exception. Let's make sure it's not getting swallowed or wrapped:

• Check for hidden try/catch blocks: Dig into your ItemReader, ItemProcessor, or ItemWriter code—if your custom exception is caught and not rethrown (or converted to a non-retryable exception), the retry logic will never fire. Add log statements at the point of exception to confirm it's escaping to the batch framework.
• Validate exception inheritance & wrapping: Ensure your custom exception extends RuntimeException (or is explicitly listed if it's a checked exception). If your exception is wrapped in another type (like InvocationTargetException or a Spring data access exception), you'll need to either include the wrapper class in your retry config or use an exception matcher to target nested exceptions.
• Debug exception flow: Add a breakpoint where your custom exception is thrown, then step through to see if it reaches Spring Batch's RetryOperationsInterceptor or ChunkOrientedTasklet classes.

Upgrading Spring Batch alone isn't enough—you need to ensure its dependency on Spring Retry is aligned:

• Check your Gradle dependencies: Use ./gradlew dependencies to inspect your dependency tree. Spring Batch 5.x requires Spring Retry 2.x, so if an older version of Spring Retry is being pulled in by another dependency, exclude it explicitly. For example:

  implementation('org.springframework.batch:spring-batch-core') {
    exclude group: 'org.springframework.retry', module: 'spring-retry'
  }
  implementation 'org.springframework.retry:spring-retry:2.0.3' // Match Spring Batch's compatible version
  

• Avoid manual version mismatches: Let Spring Batch manage the Spring Retry version by omitting the explicit spring-retry dependency—Gradle will pull in the compatible version automatically.

If you're using a custom RetryPolicy bean instead of inline XML config:

• Confirm bean creation: Check that your policy bean is being initialized correctly. For a SimpleRetryPolicy, your config should look like this:

  <bean id="customRetryPolicy" class="org.springframework.retry.policy.SimpleRetryPolicy">
    <property name="maxAttempts" value="3"/>
    <property name="retryableExceptions">
      <map>
        <entry key="com.yourteam.YourCustomRuntimeException" value="true"/>
      </map>
    </property>
  </bean>
  

• Check bean scope: Ensure your retry policy is a singleton (the default)—prototype scope would create a new policy instance for each chunk, losing retry state between attempts.
• Verify chunk reference: Make sure your chunk's retry-policy attribute points to the correct bean ID (no typos!).

Turn on debug logs to see exactly what's happening with the retry mechanism:

• Add these logger configurations to your logging setup (Logback/Log4j2):

  <logger name="org.springframework.retry" level="DEBUG"/>
  <logger name="org.springframework.batch.core.step.item" level="DEBUG"/>
  

• Look for logs like Retrying after exception or Retry failed—if you don't see these, the retry interceptor isn't being applied to your step. If you see logs about skipping instead of retrying, your exception might be marked as skip-only instead of retryable.

Sometimes, Java config or auto-configuration can override your XML settings:

• Look for conflicting Java config: Check if any @Configuration class defines a step with the same ID as your XML-configured step—this would override the XML settings.
• Confirm XML config loading: Ensure your XML file is being loaded by the Spring context (via @ImportResource or application context config). If it's not, your retry settings are never being applied.

If you're still stuck after working through these steps, sharing your retry XML snippet, exception stack trace, and Gradle dependency tree would help narrow things down further.

内容的提问来源于stack exchange，提问作者Vimal