Announcement Announcement Module
Collapse
No announcement yet.
Problem after upgrading from 2.1.0 to 2.1.1 Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Problem after upgrading from 2.1.0 to 2.1.1

    Hi,

    I upgraded my project to use the latest verion of spring batch 2.1.1 (previously 2.1.0)

    After upgrading, our batch jobs hangs.

    I tried to debug and found that the job hangs in
    org.springFramework.batch.repeat.support.RepeatTem plate class.

    There were no changes in the project except upgrading.

    Thanks,
    umab.
    Last edited by umab; May 4th, 2010, 04:59 PM. Reason: subject is wrong

  • #2
    Maybe you could provide a test case or some sample code?

    Comment


    • #3
      We are looking on how to reproduce as a small test case.

      In the mean time below is the stack trace from the debugger of where it hangs: LockSupport.park method.

      We have also found that increasing the commit interval greater than the no. of rows it reads prevents the hang.
      For Example: One of our test cases has 4 reader rows. Setting commit interval to 5 or above works and 4 or below hangs.

      The writer has no effect - if its in the config or removed from the config, there is no change.

      If we revert back to 2.1.0, it works.

      Code:
      Thread [main] (Suspended)	
      	LockSupport.park(Object) line: 158	
      	Semaphore$NonfairSync(AbstractQueuedSynchronizer).parkAndCheckInterrupt() line: 747	
      	Semaphore$NonfairSync(AbstractQueuedSynchronizer).doAcquireSharedInterruptibly(int) line: 905	
      	Semaphore$NonfairSync(AbstractQueuedSynchronizer).acquireSharedInterruptibly(int) line: 1217	
      	Semaphore.acquire() line: 286	
      	TaskletStep$ChunkTransactionCallback.doInTransaction(TransactionStatus) line: 372	
      	TransactionTemplate.execute(TransactionCallback<T>) line: 130	
      	TaskletStep$2.doInChunkContext(RepeatContext, ChunkContext) line: 261	
      	TaskletStep$2(StepContextRepeatCallback).doInIteration(RepeatContext) line: 76	
      	RepeatTemplate.getNextResult(RepeatContext, RepeatCallback, RepeatInternalState) line: 367	
      	RepeatTemplate.executeInternal(RepeatCallback) line: 214	
      	RepeatTemplate.iterate(RepeatCallback) line: 143	
      	TaskletStep.doExecute(StepExecution) line: 247	
      	TaskletStep(AbstractStep).execute(StepExecution) line: 196	
      	SimpleStepHandler.handleStep(Step, JobExecution) line: 135	
      	JobFlowExecutor.executeStep(Step) line: 61	
      	StepState.handle(FlowExecutor) line: 60	
      	SimpleFlow.resume(String, FlowExecutor) line: 144	
      	SimpleFlow.start(FlowExecutor) line: 124	
      	FlowJob.doExecute(JobExecution) line: 135	
      	FlowJob(AbstractJob).execute(JobExecution) line: 281	
      	SimpleJobLauncher$1.run() line: 120	
      	SyncTaskExecutor.execute(Runnable) line: 48	
      	SimpleJobLauncher.run(Job, JobParameters) line: 114	
      	JobLauncherTestUtils.launchJob(JobParameters) line: 151	
      	MdsResidentsJobTest(BatchItTestBase).runBatchJob(VerifyTableDefinition[], String[], String[], int, BatchStatus, Map<String,JobParameter>, String) line: 257	
      	MdsResidentsJobTest(BatchItTestBase).runBatchJob(VerifyTableDefinition[], String[], String[], Map<String,JobParameter>) line: 213	
      	MdsResidentsJobTest.testUpdatePerformedForMatchingCmrResident() line: 65	
      	NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method]	
      	NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39	
      	DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25	
      	Method.invoke(Object, Object...) line: 597	
      	FrameworkMethod$1.runReflectiveCall() line: 44	
      	FrameworkMethod$1(ReflectiveCallable).run() line: 15	
      	FrameworkMethod.invokeExplosively(Object, Object...) line: 41	
      	InvokeMethod.evaluate() line: 20	
      	TestWatchman$1.evaluate() line: 48	
      	RunBefores.evaluate() line: 28	
      	RunBeforeTestMethodCallbacks.evaluate() line: 74	
      	RunAfters.evaluate() line: 31	
      	RunAfterTestMethodCallbacks.evaluate() line: 82	
      	SpringRepeat.evaluate() line: 72	
      	SpringJUnit4ClassRunner.runChild(FrameworkMethod, RunNotifier) line: 240	
      	SpringJUnit4ClassRunner(BlockJUnit4ClassRunner).runChild(Object, RunNotifier) line: 50	
      	ParentRunner$3.run() line: 193	
      	ParentRunner$1.schedule(Runnable) line: 52	
      	SpringJUnit4ClassRunner(ParentRunner<T>).runChildren(RunNotifier) line: 191	
      	ParentRunner<T>.access$000(ParentRunner, RunNotifier) line: 42	
      	ParentRunner$2.evaluate() line: 184	
      	RunBeforeTestClassCallbacks.evaluate() line: 61	
      	RunAfterTestClassCallbacks.evaluate() line: 70	
      	SpringJUnit4ClassRunner(ParentRunner<T>).run(RunNotifier) line: 236	
      	SpringJUnit4ClassRunner.run(RunNotifier) line: 180	
      	JUnit4TestMethodReference(JUnit4TestReference).run(TestExecution) line: 46	
      	TestExecution.run(ITestReference[]) line: 38	
      	RemoteTestRunner.runTests(String[], String, TestExecution) line: 467	
      	RemoteTestRunner.runTests(TestExecution) line: 683	
      	RemoteTestRunner.run() line: 390	
      	RemoteTestRunner.main(String[]) line: 197

      Comment


      • #4
        Does the step complete normally when you change the commit interval? I can see how maybe you could get a deadlock in 2.1.1 but not 2.1.0 if there was an exception during an unusual transaction error, but not if the step completes normally. Another possibility is that you are using a non-standard PlatformTransactionManager. Is that the case? Some sample code would help.

        Comment


        • #5
          Hi,

          I hope that it is ok to reply to this thread.

          I'm having the same problems that a program that ran fine with Spring Batch 2.1.0 but hangs with 2.1.1. It happens when the number of input records exceeds the commit-interval.

          I managed to strip down the original application a bit to provide a testcase that shows the problem. When the Spring Batch version in the pom.xml is set to 2.1.0, then the test works fine.

          What I'm not sure about is whether it is my fault and the program has errors that only surface with Spring Batch 2.1.1. If you have any suggestions how I could improve the program, I'd be glad to hear them.

          Thanks in advance!
          Stephan

          Wh

          Comment


          • #6
            There was a JIRA on this topic and it was resolved as Invalid because it turned out the user was running a Job from a @Transactional method (in a test case). Please look at your transaction boundaries and make sure the Job is executed outside a transaction.

            Comment


            • #7
              Thanks for your answer! After removing the @Transactional from my test method, it works fine. Now I have to make sure that the actual program launches its batch jobs outside of a transaction, too.

              The fact that the job should not be launched inside a transaction should probably added to the documentation. In section 10.2 (End-To-End Testing of Batch Jobs) the sample code has a @Transactional annotation:
              Code:
              @Transactional
              @Test
              public void testJob() throws Exception
              Cheers,
              Stephan

              Comment


              • #8
                Yes, that doc example is very misleading. That's exactly our cause too - @Transactional test.

                Comment


                • #9
                  Thanks....
                  Cause i encountered the same problem with this.

                  Searching for Condo's visit at chicago real estate for more info.
                  Last edited by after; Jun 2nd, 2010, 09:24 AM.

                  Comment

                  Working...
                  X