Extracting Tomcat Zip SOMETIMES fail with IOException: Negative seek offset

java tomcat hudson zip maven-cargo
10,096

Solution 1

Usually it's due to a bad download (the odd corrupted packet etc). Try using an MD5 / SHA-1 checksum to validate the archive before using it.

Also be careful that the offset variable is large enough to hold the require value of your seek.

Solution 2

The Problem was gone after changing the download url to an mirror.

Share:
10,096
Ralph
Author by

Ralph

Updated on June 07, 2022

Comments

  • Ralph
    Ralph almost 2 years

    I am using maven cargo with its zip url installer feature to download a tomcat for my integration tests. This works fine on my computer, but when its run in husdon it fails sometimes (round about 10-20%).

    The failure is:

    Error while expanding /home/hudson/workspace/My Test Media-Archive/cfma/target/cargo/install/apache-tomcat-6.0.32.zip
java.io.IOException: Negative seek offset
    at org.apache.tools.ant.taskdefs.Expand.expandFile(Expand.java:148)
    at org.apache.tools.ant.taskdefs.Expand.execute(Expand.java:107)
    at org.codehaus.cargo.container.installer.ZipURLInstaller.unpack(ZipURLInstaller.java:252)
    at org.codehaus.cargo.container.installer.ZipURLInstaller.install(ZipURLInstaller.java:149)
    at org.codehaus.cargo.maven2.configuration.Container.setupHome(Container.java:357)
    at org.codehaus.cargo.maven2.configuration.Container.createContainer(Container.java:241)
    at org.codehaus.cargo.maven2.AbstractCargoMojo.createNewContainer(AbstractCargoMojo.java:470)
    at org.codehaus.cargo.maven2.AbstractCargoMojo.createContainer(AbstractCargoMojo.java:410)
    at org.codehaus.cargo.maven2.ContainerStartMojo.doExecute(ContainerStartMojo.java:53)
    at org.codehaus.cargo.maven2.AbstractCargoMojo.execute(AbstractCargoMojo.java:268)
    at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
    at hudson.maven.agent.PluginManagerInterceptor.executeMojo(PluginManagerInterceptor.java:182)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
    at org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
    at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
    at hudson.maven.agent.Main.launch(Main.java:173)
    at hudson.maven.MavenBuilder.call(MavenBuilder.java:164)
    at hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:861)
    at hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:792)
    at hudson.remoting.UserRequest.perform(UserRequest.java:114)
    at hudson.remoting.UserRequest.perform(UserRequest.java:48)
    at hudson.remoting.Request$2.run(Request.java:270)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
    at java.util.concurrent.FutureTask.run(FutureTask.java:138)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:662)
Caused by: java.io.IOException: Negative seek offset
    at java.io.RandomAccessFile.seek(Native Method)
    at org.apache.tools.zip.ZipFile.positionAtCentralDirectory(ZipFile.java:403)
    at org.apache.tools.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:271)
    at org.apache.tools.zip.ZipFile.<init>(ZipFile.java:152)
    at org.apache.tools.ant.taskdefs.Expand.expandFile(Expand.java:137)
    ... 40 more
--- Nested Exception ---
java.io.IOException: Negative seek offset
    at java.io.RandomAccessFile.seek(Native Method)
    at org.apache.tools.zip.ZipFile.positionAtCentralDirectory(ZipFile.java:403)
    at org.apache.tools.zip.ZipFile.populateFromCentralDirectory(ZipFile.java:271)
    at org.apache.tools.zip.ZipFile.<init>(ZipFile.java:152)
    at org.apache.tools.ant.taskdefs.Expand.expandFile(Expand.java:137)
    at org.apache.tools.ant.taskdefs.Expand.execute(Expand.java:107)
    at org.codehaus.cargo.container.installer.ZipURLInstaller.unpack(ZipURLInstaller.java:252)
    at org.codehaus.cargo.container.installer.ZipURLInstaller.install(ZipURLInstaller.java:149)
    at org.codehaus.cargo.maven2.configuration.Container.setupHome(Container.java:357)
    at org.codehaus.cargo.maven2.configuration.Container.createContainer(Container.java:241)
    at org.codehaus.cargo.maven2.AbstractCargoMojo.createNewContainer(AbstractCargoMojo.java:470)
    at org.codehaus.cargo.maven2.AbstractCargoMojo.createContainer(AbstractCargoMojo.java:410)
    at org.codehaus.cargo.maven2.ContainerStartMojo.doExecute(ContainerStartMojo.java:53)
    at org.codehaus.cargo.maven2.AbstractCargoMojo.execute(AbstractCargoMojo.java:268)
    at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
    at hudson.maven.agent.PluginManagerInterceptor.executeMojo(PluginManagerInterceptor.java:182)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
    at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
    at org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65)
    at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
    at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
    at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    at java.lang.reflect.Method.invoke(Method.java:597)
    at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
    at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
    at hudson.maven.agent.Main.launch(Main.java:173)
    at hudson.maven.MavenBuilder.call(MavenBuilder.java:164)
    at hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:861)
    at hudson.maven.MavenModuleSetBuild$Builder.call(MavenModuleSetBuild.java:792)
    at hudson.remoting.UserRequest.perform(UserRequest.java:114)
    at hudson.remoting.UserRequest.perform(UserRequest.java:48)
    at hudson.remoting.Request$2.run(Request.java:270)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
    at java.util.concurrent.FutureTask.run(FutureTask.java:138)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:662)

    And this is the relevant part of my pom.

    <plugin>
  <groupId>org.codehaus.cargo</groupId>
  <artifactId>cargo-maven2-plugin</artifactId>
  <version>1.0.5</version>
  <configuration>
     <container>
         <zipUrlInstaller>
    <url>http://archive.apache.org/dist/tomcat/tomcat-6/v6.0.32/bin/apache-tomcat-6.0.32.zip</url>
          <zipUrlInstaller>
          .... 
     </container>
     ...
   <configuration>
</plugin>

    Does anybody know what I am doing wrong?

  • Peter
    Peter almost 13 years
    TCP should be resilient against dropped packets, surely? Only corrupted packets where the checksum verification gives a false positive should get through to the application performing the download. You could try writing a loop to wget the file and check its checksum
  • Michael
    Michael almost 13 years
    TCP should be resilient using ACK, so yes, it is more likely that corrupted packets would be the issue.
  • Ralph
    Ralph almost 13 years
    @Mikaveli: because I undersand your answer in the way that it is an transport problem, and second it does not contain a solution, you say only I should check the file (but I know that it is corrupt). -- But on the other hand I can accept your answer, because mine is not a real answer to the problem too.
  • Michael
    Michael almost 13 years
    The point was, if you validated the file, you would have known whether the file was corrupt at source - or afterwards (whilst downloading / on disk etc). The final solution is determined by the result of that test. Switching the source has fixed it for you, but it's better to determine exactly where things went wrong, to protect yourself in the future. :)
  • Matt Ryall
    Matt Ryall almost 11 years
    More likely an aborted download or a broken Maven proxy or web server that served the Tomcat download. The chance of data being corrupted when sent over TCP is very small.

Recents

Why Is PNG file with Drop Shadow in Flutter Web App Grainy?
How to troubleshoot crashes detected by Google Play Store for Flutter app
Cupertino DateTime picker interfering with scroll behaviour
Why does awk -F work for most letters, but not for the letter "t"?
Flutter change focus color and icon color but not works
How to print and connect to printer using flutter desktop via usb?
Critical issues have been reported with the following SDK versions: com.google.android.gms:play-services-safetynet:17.0.0
Flutter Dart - get localized country name from country code
navigatorState is null when using pushNamed Navigation onGenerateRoutes of GetMaterialPage
Android Sdk manager not found- Flutter doctor error
Flutter Laravel Push Notification without using any third party like(firebase,onesignal..etc)
How to change the color of ElevatedButton when entering text in TextField

Related

We can't access to jenkins from anywhere
How to set MediaType to UTF-8 in restTemplate with json format
How to register an object in jersey 2(ResourceConfig)
Getting issue while deploying spring boot war on tomcat 7
Reading a huge Zip file in java - Out of Memory Error
Creating a zip on the fly with csv files inside
Difference between WebApplicationException and WebServiceException in the context of Jax-RS (Jersey)
No resource found for class in CXF rest services
How do I register a Tomcat 7.0.41 server on NetBeans 7.3?
Why is my Tomcat 6 executor thread pool not being used by the connector?