Continuum
  1. Continuum
  2. CONTINUUM-1954

Data truncation: Data too long for column 'NAME' at row 1

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 1.3.1 (Alpha)
    • Fix Version/s: None
    • Component/s: Database
    • Environment:
      continuum-1.3-SNAPSHOT, rev. 708424, Linux, MySQL, LDAP

      Description

      This is what I see in continuum.log:

      2008-10-31 00:00:47,613 [pool-1-thread-1] INFO buildController - Performing action update-project-from-working-directory
      2008-10-31 00:00:47,632 [pool-1-thread-1] INFO action#update-project-from-working-directory - Updating project 'Continuum :: Model' from checkout.
      2008-10-31 00:00:48,602 [pool-1-thread-1] INFO buildController - Performing action execute-builder
      2008-10-31 00:00:48,890 [Thread-18] ERROR taskQueueExecutor#build-project - Error executing task
      edu.emory.mathcs.backport.java.util.concurrent.ExecutionException: javax.jdo.JDODataStoreException: Insert request failed: INSERT INTO `CHANGEFILE` (`CHANGEFILE_ID`,`STATUS`,`NAME`,`REVISION`,`MODEL_ENCODING`,`FILES_CHANGESET_ID_OID`,`FILES_INTEGER_IDX`) VALUES (?,?,?,?,?,?,?)
      NestedThrowables:
      com.mysql.jdbc.MysqlDataTruncation: Data truncation: Data too long for column 'NAME' at row 1
      at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.getResult(FutureTask.java:301)
      at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.get(FutureTask.java:120)
      at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.waitForTask(ThreadedTaskQueueExecutor.java:159)
      at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:127)
      Caused by: javax.jdo.JDODataStoreException: Insert request failed: INSERT INTO `CHANGEFILE` (`CHANGEFILE_ID`,`STATUS`,`NAME`,`REVISION`,`MODEL_ENCODING`,`FILES_CHANGESET_ID_OID`,`FILES_INTEGER_IDX`) VALUES (?,?,?,?,?,?,?)
      NestedThrowables:
      com.mysql.jdbc.MysqlDataTruncation: Data truncation: Data too long for column 'NAME' at row 1
      at org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:455)
      at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2519)
      at org.jpox.store.StoreManager.insert(StoreManager.java:938)
      at org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3667)
      at org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:3646)
      at org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1206)
      at org.jpox.AbstractPersistenceManager.makePersistentInternal(AbstractPersistenceManager.java:1259)
      at org.jpox.store.rdbms.scostore.FKListStore.validateElementForWriting(FKListStore.java:1231)
      at org.jpox.store.rdbms.scostore.FKListStore.internalAdd(FKListStore.java:772)
      at org.jpox.store.rdbms.scostore.AbstractListStore.addAll(AbstractListStore.java:387)
      at org.jpox.store.mapping.CollectionMapping.postInsert(CollectionMapping.java:209)
      at org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:464)
      at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2519)
      at org.jpox.store.StoreManager.insert(StoreManager.java:938)
      at org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3667)
      at org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:3646)
      at org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1206)
      at org.jpox.AbstractPersistenceManager.makePersistentInternal(AbstractPersistenceManager.java:1259)
      at org.jpox.store.rdbms.scostore.FKListStore.validateElementForWriting(FKListStore.java:1231)
      at org.jpox.store.rdbms.scostore.FKListStore.internalAdd(FKListStore.java:772)
      at org.jpox.store.rdbms.scostore.AbstractListStore.addAll(AbstractListStore.java:387)
      at org.jpox.store.mapping.CollectionMapping.postInsert(CollectionMapping.java:209)
      at org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:464)
      at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2519)
      at org.jpox.store.StoreManager.insert(StoreManager.java:938)
      at org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3667)
      at org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:3646)
      at org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1206)
      at org.jpox.AbstractPersistenceManager.makePersistentInternal(AbstractPersistenceManager.java:1259)
      at org.jpox.store.mapping.PersistenceCapableMapping.setObject(PersistenceCapableMapping.java:450)
      at org.jpox.store.rdbms.fieldmanager.ParameterSetter.storeObjectField(ParameterSetter.java:144)
      at org.jpox.state.StateManagerImpl.providedObjectField(StateManagerImpl.java:2771)
      at org.apache.maven.continuum.model.project.BuildResult.jdoProvideField(BuildResult.java)
      at org.apache.maven.continuum.model.project.BuildResult.jdoProvideFields(BuildResult.java)
      at org.jpox.state.StateManagerImpl.provideFields(StateManagerImpl.java:3115)
      at org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:252)
      at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2519)
      at org.jpox.store.StoreManager.insert(StoreManager.java:938)
      at org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3667)
      at org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:3646)
      at org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1206)
      at org.jpox.AbstractPersistenceManager.makePersistent(AbstractPersistenceManager.java:1277)
      at org.codehaus.plexus.jdo.PlexusJdoUtils.makePersistent(PlexusJdoUtils.java:175)
      at org.apache.continuum.dao.AbstractDao.makePersistent(AbstractDao.java:191)
      at org.apache.continuum.dao.BuildResultDaoImpl.addBuildResult(BuildResultDaoImpl.java:99)
      at org.apache.maven.continuum.buildcontroller.DefaultBuildController.makeAndStoreBuildResult(DefaultBuildController.java:773)
      at org.apache.maven.continuum.buildcontroller.DefaultBuildController.updateBuildResult(DefaultBuildController.java:255)
      at org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:469)
      at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:170)
      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:178)
      at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1061)
      at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:575)
      at java.lang.Thread.run(Thread.java:675)
      Caused by: com.mysql.jdbc.MysqlDataTruncation: Data truncation: Data too long for column 'NAME' at row 1
      at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3489)
      at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3423)
      at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1936)
      at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2060)
      at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2542)
      at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:1734)
      at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:2019)
      at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1937)
      at com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1922)
      at org.jpox.store.rdbms.RDBMSManager.executeStatementUpdate(RDBMSManager.java:575)
      at org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:328)
      ... 55 more

        Activity

        Mark Thomas made changes -
        Workflow jira [ 12947788 ] Default workflow, editable Closed status [ 12983210 ]
        Mark Thomas made changes -
        Project Import Sun Apr 05 21:12:18 UTC 2015 [ 1428268338676 ]
        Mark Thomas made changes -
        Workflow jira [ 12710607 ] Default workflow, editable Closed status [ 12740317 ]
        Mark Thomas made changes -
        Project Import Sun Apr 05 08:36:01 UTC 2015 [ 1428222961749 ]
        Brett Porter made changes -
        Labels backlog-to-cleanup
        Fix Version/s Backlog [ 15656 ]
        Wendy Smoak made changes -
        Fix Version/s Backlog [ 15656 ]
        Fix Version/s 1.x [ 14167 ]
        Hide
        Peter Janes added a comment -

        I haven't seen the exception (or the missed status updates) in the week since setting the longer name field. Previously I was seeing issues every day or two.

        Show
        Peter Janes added a comment - I haven't seen the exception (or the missed status updates) in the week since setting the longer name field. Previously I was seeing issues every day or two.
        Wendy Smoak made changes -
        Fix Version/s 1.x [ 14167 ]
        Hide
        Peter Janes added a comment -

        Presumably the error is because the length of one or more of the changed filenames is longer than the schema allows (currently 255 characters). I'm going to try running with a 512-character limit, i.e. "ALTER TABLE CHANGEFILE MODIFY NAME VARCHAR(512);", to see if the problem persists.

        One curiosity I've noticed in the database is that the NAME occasionally includes more text than the filename, e.g. "/trunk/foo/bar/File.java (from /trunk/foo/bar/File.java:1234)". Perhaps there's a bug in the SVN changeset parser that's artificially extending the length of the filenames? (About .3% of the filenames in my CHANGEFILE table contain "(from".)

        Also, it's worth noting that when this happens, it also appears that Continuum doesn't update the build status of the project, i.e. it remains in "building" instead of going to "error". The build can't be cancelled or restarted manually, and won't be executed by the scheduler; the only fix I've found is to restart the server.

        Show
        Peter Janes added a comment - Presumably the error is because the length of one or more of the changed filenames is longer than the schema allows (currently 255 characters). I'm going to try running with a 512-character limit, i.e. "ALTER TABLE CHANGEFILE MODIFY NAME VARCHAR(512);", to see if the problem persists. One curiosity I've noticed in the database is that the NAME occasionally includes more text than the filename, e.g. "/trunk/foo/bar/File.java (from /trunk/foo/bar/File.java:1234)". Perhaps there's a bug in the SVN changeset parser that's artificially extending the length of the filenames? (About .3% of the filenames in my CHANGEFILE table contain "(from".) Also, it's worth noting that when this happens, it also appears that Continuum doesn't update the build status of the project, i.e. it remains in "building" instead of going to "error". The build can't be cancelled or restarted manually, and won't be executed by the scheduler; the only fix I've found is to restart the server.
        Brett Porter made changes -
        Field Original Value New Value
        Affects Version/s 1.3.1 [ 14741 ]
        Affects Version/s 1.3.x [ 14168 ]
        Hide
        dlecan added a comment -

        I have the same problem. It happens sometimes, always on svn updates.

        It is impossible to reproduce the problem, because when it happens, sources are updated and next build runs on updated sources (so without updated files, so not problem).

        Show
        dlecan added a comment - I have the same problem. It happens sometimes, always on svn updates. It is impossible to reproduce the problem, because when it happens, sources are updated and next build runs on updated sources (so without updated files, so not problem).
        Hide
        Jimmy Conway added a comment -

        Yes, I use Continuum to build Continuum itself. I don't know how to reproduce it. I just show you the messages from continuum.log file. Maybe they are helpful.

        If not, it's OK for me, it doesn't make me any difficulties.

        Show
        Jimmy Conway added a comment - Yes, I use Continuum to build Continuum itself. I don't know how to reproduce it. I just show you the messages from continuum.log file. Maybe they are helpful. If not, it's OK for me, it doesn't make me any difficulties.
        Hide
        Wendy Smoak added a comment -

        What are the steps to reproduce it? From the log message, it looks like you might be using Continuum to build Continuum itself?

        Show
        Wendy Smoak added a comment - What are the steps to reproduce it? From the log message, it looks like you might be using Continuum to build Continuum itself?
        Jimmy Conway created issue -

          People

          • Assignee:
            Unassigned
            Reporter:
            Jimmy Conway
          • Votes:
            2 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Development