Continuum

Project is stuck in the "Build in Progress" state if the associated exception has more than 8192 chars

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.1-alpha-1
  • Fix Version/s: 1.1-beta-1
  • Component/s: Core system
  • Labels:
    None
  • Complexity:
    Intermediate
  • Number of attachments :
    1

Description

We have added unit tests to one of our project and some of them are crashing from time to time due to a race condition with the database connections.

Since then, the project is always in the "Build In progress" state even if the build is actually terminated in the log (Build failure because one test failed). The project never leaves this state, if we consult the builds summary we have a couple of builds in the Build In progress state (?!)

See screenshot.

Issue Links

is duplicated by

Bug - A problem which impairs or prevents the functions of the product. CONTINUUM-1317 Builds hand when JUNIT assertion failure text > 8192 characters

  • Critical - Crashes, loss of data, severe memory leak.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Stéphane Nicoll added a comment -

Ok. The problem is that the exception related to the test failure is very long and is not truncated by Continuum. So when the build status is updated, we got a failure like this:

22646112 [Thread-6] ERROR org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor:build-project  - Error executing task
edu.emory.mathcs.backport.java.util.concurrent.ExecutionException: javax.jdo.JDOFatalUserException: Attempt to store value "org.codehaus.plexus.taskqueue.execution.TaskExecutionException: Error executing action 'execute-builder'
        at org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:432)
        at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:145)
        at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50)
        at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116)
        at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)
        at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:987)
        at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:528)
        at java.lang.Thread.run(Thread.java:595)
Caused by: javax.jdo.JDOFatalUserException: Attempt to store value 

[BLA BLA BLA VERY LONG]
" in column "`EXCEPTIONSTRING`" that has maximum length of 8192. Please correct your data!
        at org.jpox.store.rdbms.mapping.CharRDBMSMapping.setString(CharRDBMSMapping.java:214)
        at org.jpox.store.mapping.SingleFieldMapping.setString(SingleFieldMapping.java:203)
        at org.jpox.store.rdbms.fieldmanager.ParameterSetter.storeStringField(ParameterSetter.java:122)
        at org.jpox.state.StateManagerImpl.providedStringField(StateManagerImpl.java:2737)
        at org.apache.maven.continuum.model.scm.TestCaseFailure.jdoProvideField(TestCaseFailure.java)
        at org.apache.maven.continuum.model.scm.TestCaseFailure.jdoProvideFields(TestCaseFailure.java)
        [...]
Show
Stéphane Nicoll added a comment - Ok. The problem is that the exception related to the test failure is very long and is not truncated by Continuum. So when the build status is updated, we got a failure like this: 22646112 [Thread-6] ERROR org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor:build-project - Error executing task edu.emory.mathcs.backport.java.util.concurrent.ExecutionException: javax.jdo.JDOFatalUserException: Attempt to store value "org.codehaus.plexus.taskqueue.execution.TaskExecutionException: Error executing action 'execute-builder' at org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:432) at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:145) at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116) at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:987) at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:528) at java.lang.Thread.run(Thread.java:595) Caused by: javax.jdo.JDOFatalUserException: Attempt to store value [BLA BLA BLA VERY LONG] " in column "`EXCEPTIONSTRING`" that has maximum length of 8192. Please correct your data! at org.jpox.store.rdbms.mapping.CharRDBMSMapping.setString(CharRDBMSMapping.java:214) at org.jpox.store.mapping.SingleFieldMapping.setString(SingleFieldMapping.java:203) at org.jpox.store.rdbms.fieldmanager.ParameterSetter.storeStringField(ParameterSetter.java:122) at org.jpox.state.StateManagerImpl.providedStringField(StateManagerImpl.java:2737) at org.apache.maven.continuum.model.scm.TestCaseFailure.jdoProvideField(TestCaseFailure.java) at org.apache.maven.continuum.model.scm.TestCaseFailure.jdoProvideFields(TestCaseFailure.java) [...]
Hide
Permalink
Stéphane Nicoll added a comment -

The maximum length is actually documented properly but the model generated by modello does not reflect that. We can either update this or check every time the setException method is called. The second option sounds a bit error prone to me but truncating should be an option (or modello should provide some sort of hook).

Thoughts?

Show
Stéphane Nicoll added a comment - The maximum length is actually documented properly but the model generated by modello does not reflect that. We can either update this or check every time the setException method is called. The second option sounds a bit error prone to me but truncating should be an option (or modello should provide some sort of hook). Thoughts?
Hide
Permalink
Emmanuel Venisse added a comment -

Fixed by truncating the exception string

Show
Emmanuel Venisse added a comment - Fixed by truncating the exception string

People

  • Assignee:
    Emmanuel Venisse
    Reporter:
    Stéphane Nicoll
Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: