Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MultiResourceItemReader fails on Restart if read() method was not called. [BATCH-1798] #1791

Closed
spring-issuemaster opened this issue Oct 7, 2011 · 2 comments

Comments

@spring-issuemaster
Copy link
Collaborator

@spring-issuemaster spring-issuemaster commented Oct 7, 2011

sonwar opened BATCH-1798 and commented

The MultiResourceItemReader starts with -1 as currentResource. If the ItemProcessor fails on first commit (I tested with a "throw new RuntimeException()"), this index remains -1 on ExecutionContext. Then, on restart, we get:

java.lang.ArrayIndexOutOfBoundsException: -1
at org.springframework.batch.item.file.MultiResourceItemReader.open(MultiResourceItemReader.java:171)

The fix is something like:

if (executionContext.containsKey(executionContextUserSupport.getKey(RESOURCE_KEY))) {
currentResource = executionContext.getInt(executionContextUserSupport.getKey(RESOURCE_KEY));

// begin fix block
if (currentResource == -1) {
	currentResource = 0;
}
    // end fix block

    delegate.setResource(resources[currentResource]);
delegate.open(executionContext);

}


Affects: 2.1.8

Referenced from: commits 6832201

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Oct 7, 2011

sonwar commented

I forgotten to say... The fix is on ItemStream's open() method. No need for checking "resources.length != 0", since that check is made before.

So, the currentResource=0 code solves the bug.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Oct 9, 2011

Robert Kasanicky commented

Fixed as suggested. Note the bug is not triggered by crashing on the 1st commit, rather by crashing without calling read() on the reader. I guess you must be calling the reader from an ItemProcessor or so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
1 participant
You can’t perform that action at this time.