You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ivy-commits@incubator.apache.org by "John Williams (JIRA)" <ji...@apache.org> on 2007/01/30 16:39:33 UTC

[jira] Created: (IVY-402) Update of file system repositories is non-atomic.

Update of file system repositories is non-atomic.
-------------------------------------------------

                 Key: IVY-402
                 URL: https://issues.apache.org/jira/browse/IVY-402
             Project: Ivy
          Issue Type: Improvement
          Components: Core
    Affects Versions: 1.4.1
         Environment: Linux, JDK 1.5
            Reporter: John Williams
            Priority: Minor


I occasionally have a problem that seems to be caused by using a jar file in an Ivy repository while that file is in the process of being copied, causing the JVM to throw crazy exceptions (see below).  If that's really what the problem is, I think a good fix would be to copy the jar file to a temp file in the same directory as the final location and then rename when temp file when the copy is complete.

    java.lang.InternalError: jzentry == 0,
 jzfile = 1813396632,
 total = 2398,
 name = /main/public/local/devh/ivy/snapshots/lcc/litenejava/1.3.2-snapshot/jars/litenejava.jar,
 i = 166,
 message = invalid LOC header (bad signature)
        at java.util.zip.ZipFile$3.nextElement(ZipFile.java:429)
        at java.util.zip.ZipFile$3.nextElement(ZipFile.java:415)
        at java.util.jar.JarFile$1.nextElement(JarFile.java:221)
        at java.util.jar.JarFile$1.nextElement(JarFile.java:220)
        at sun.misc.URLClassPath$JarLoader.validIndex(URLClassPath.java:648)
        at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:767)
        at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:682)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (IVY-402) Update of file system repositories is non-atomic.

Posted by "John Williams (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/IVY-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491337 ] 

John Williams commented on IVY-402:
-----------------------------------

I think the problem is with publication, not with downloading. With the way I have Ivy set up, the only time a jar file is copied is when a module is published, and I occasionally see this problem when a module with a particularly large jar file (> 100MB) is being published.

> Update of file system repositories is non-atomic.
> -------------------------------------------------
>
>                 Key: IVY-402
>                 URL: https://issues.apache.org/jira/browse/IVY-402
>             Project: Ivy
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.4.1
>         Environment: Linux, JDK 1.5
>            Reporter: John Williams
>            Priority: Minor
>
> I occasionally have a problem that seems to be caused by using a jar file in an Ivy repository while that file is in the process of being copied, causing the JVM to throw crazy exceptions (see below).  If that's really what the problem is, I think a good fix would be to copy the jar file to a temp file in the same directory as the final location and then rename when temp file when the copy is complete.
>     java.lang.InternalError: jzentry == 0,
>  jzfile = 1813396632,
>  total = 2398,
>  name = /main/public/local/devh/ivy/snapshots/lcc/litenejava/1.3.2-snapshot/jars/litenejava.jar,
>  i = 166,
>  message = invalid LOC header (bad signature)
>         at java.util.zip.ZipFile$3.nextElement(ZipFile.java:429)
>         at java.util.zip.ZipFile$3.nextElement(ZipFile.java:415)
>         at java.util.jar.JarFile$1.nextElement(JarFile.java:221)
>         at java.util.jar.JarFile$1.nextElement(JarFile.java:220)
>         at sun.misc.URLClassPath$JarLoader.validIndex(URLClassPath.java:648)
>         at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:767)
>         at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:682)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (IVY-402) Update of file system repositories is non-atomic.

Posted by "Xavier Hanin (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/IVY-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12491351 ] 

Xavier Hanin commented on IVY-402:
----------------------------------

It makes sense indeed, because during publish I think we do not use the upload-then-rename mechanism.

> Update of file system repositories is non-atomic.
> -------------------------------------------------
>
>                 Key: IVY-402
>                 URL: https://issues.apache.org/jira/browse/IVY-402
>             Project: Ivy
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.4.1
>         Environment: Linux, JDK 1.5
>            Reporter: John Williams
>            Priority: Minor
>
> I occasionally have a problem that seems to be caused by using a jar file in an Ivy repository while that file is in the process of being copied, causing the JVM to throw crazy exceptions (see below).  If that's really what the problem is, I think a good fix would be to copy the jar file to a temp file in the same directory as the final location and then rename when temp file when the copy is complete.
>     java.lang.InternalError: jzentry == 0,
>  jzfile = 1813396632,
>  total = 2398,
>  name = /main/public/local/devh/ivy/snapshots/lcc/litenejava/1.3.2-snapshot/jars/litenejava.jar,
>  i = 166,
>  message = invalid LOC header (bad signature)
>         at java.util.zip.ZipFile$3.nextElement(ZipFile.java:429)
>         at java.util.zip.ZipFile$3.nextElement(ZipFile.java:415)
>         at java.util.jar.JarFile$1.nextElement(JarFile.java:221)
>         at java.util.jar.JarFile$1.nextElement(JarFile.java:220)
>         at sun.misc.URLClassPath$JarLoader.validIndex(URLClassPath.java:648)
>         at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:767)
>         at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:682)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (IVY-402) Update of file system repositories is non-atomic.

Posted by "Xavier Hanin (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/IVY-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12468712 ] 

Xavier Hanin commented on IVY-402:
----------------------------------

I should check again but I think that something like that is already done: download to a .part file, then rename the file at the end. Note that checksum could also help to ensure the file is copied correctly. This require some investigation.

> Update of file system repositories is non-atomic.
> -------------------------------------------------
>
>                 Key: IVY-402
>                 URL: https://issues.apache.org/jira/browse/IVY-402
>             Project: Ivy
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.4.1
>         Environment: Linux, JDK 1.5
>            Reporter: John Williams
>            Priority: Minor
>
> I occasionally have a problem that seems to be caused by using a jar file in an Ivy repository while that file is in the process of being copied, causing the JVM to throw crazy exceptions (see below).  If that's really what the problem is, I think a good fix would be to copy the jar file to a temp file in the same directory as the final location and then rename when temp file when the copy is complete.
>     java.lang.InternalError: jzentry == 0,
>  jzfile = 1813396632,
>  total = 2398,
>  name = /main/public/local/devh/ivy/snapshots/lcc/litenejava/1.3.2-snapshot/jars/litenejava.jar,
>  i = 166,
>  message = invalid LOC header (bad signature)
>         at java.util.zip.ZipFile$3.nextElement(ZipFile.java:429)
>         at java.util.zip.ZipFile$3.nextElement(ZipFile.java:415)
>         at java.util.jar.JarFile$1.nextElement(JarFile.java:221)
>         at java.util.jar.JarFile$1.nextElement(JarFile.java:220)
>         at sun.misc.URLClassPath$JarLoader.validIndex(URLClassPath.java:648)
>         at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:767)
>         at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:682)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.