Petals ESB Container

Component deployment error when copying zip in install/

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Trivial Trivial
  • Resolution: Unresolved
  • Affects Version/s: 3.1
  • Fix Version/s: None
  • Security Level: Public
  • Description:
    Hide

    Exception when copying component zip in install/ directory. Randomly (and seldom...) happens.
    Probably the deployment thread tries to deploy before the component zip is fully copied... and then takes a "corrupt" zip.
    Re-deploying the same zip is normally successful.

    Exception stack follows (before successful re-deployment of the same zip):

    [Petals.AutoLoaderServiceImpl]-WARNING 2010-08-25 16:59:49,285 Unable to read a JBI descriptor
    java.util.zip.ZipException: error in opening zip file
    at java.util.zip.ZipFile.open(Native Method)
    at java.util.zip.ZipFile.<init>(ZipFile.java:114)
    at java.util.zip.ZipFile.<init>(ZipFile.java:75)
    at org.ow2.petals.jbi.management.util.PackageHelper.loadDescriptor(PackageHelper.java:126)
    at org.ow2.petals.jbi.management.autoload.AutoLoaderServiceImpl.getJBIArchives(AutoLoaderServiceImpl.java:361)
    at org.ow2.petals.jbi.management.autoload.AutoLoaderServiceImpl.install(AutoLoaderServiceImpl.java:132)
    at org.ow2.petals.jbi.management.autoload.InstallDirectoryScanner.run(InstallDirectoryScanner.java:81)
    at java.util.TimerThread.mainLoop(Timer.java:512)
    at java.util.TimerThread.run(Timer.java:462)
    [Petals.AutoLoaderServiceImpl]-WARNING 2010-08-25 16:59:49,287 Unable to read a JBI descriptor
    java.util.zip.ZipException: error in opening zip file
    at java.util.zip.ZipFile.open(Native Method)
    at java.util.zip.ZipFile.<init>(ZipFile.java:114)
    at java.util.zip.ZipFile.<init>(ZipFile.java:75)
    at org.ow2.petals.jbi.management.util.PackageHelper.loadDescriptor(PackageHelper.java:126)
    at org.ow2.petals.jbi.management.autoload.AutoLoaderServiceImpl.getJBIArchives(AutoLoaderServiceImpl.java:361)
    at org.ow2.petals.jbi.management.autoload.AutoLoaderServiceImpl.install(AutoLoaderServiceImpl.java:148)
    at org.ow2.petals.jbi.management.autoload.InstallDirectoryScanner.run(InstallDirectoryScanner.java:81)
    at java.util.TimerThread.mainLoop(Timer.java:512)
    at java.util.TimerThread.run(Timer.java:462)
    [Petals.AutoLoaderServiceImpl]-WARNING 2010-08-25 16:59:49,288 Unable to read a JBI descriptor
    java.util.zip.ZipException: error in opening zip file
    at java.util.zip.ZipFile.open(Native Method)
    at java.util.zip.ZipFile.<init>(ZipFile.java:114)
    at java.util.zip.ZipFile.<init>(ZipFile.java:75)
    at org.ow2.petals.jbi.management.util.PackageHelper.loadDescriptor(PackageHelper.java:126)
    at org.ow2.petals.jbi.management.autoload.AutoLoaderServiceImpl.getJBIArchives(AutoLoaderServiceImpl.java:361)
    at org.ow2.petals.jbi.management.autoload.AutoLoaderServiceImpl.install(AutoLoaderServiceImpl.java:165)
    at org.ow2.petals.jbi.management.autoload.InstallDirectoryScanner.run(InstallDirectoryScanner.java:81)
    at java.util.TimerThread.mainLoop(Timer.java:512)
    at java.util.TimerThread.run(Timer.java:462)
    [Petals.AutoLoaderServiceImpl]-WARNING 2010-08-25 16:59:49,288 The archive 'petals-bc-presto-1.0-SNAPSHOT.zip' remains in the install list. PEtALS deletes it

    Show
    Exception when copying component zip in install/ directory. Randomly (and seldom...) happens. Probably the deployment thread tries to deploy before the component zip is fully copied... and then takes a "corrupt" zip. Re-deploying the same zip is normally successful. Exception stack follows (before successful re-deployment of the same zip): [Petals.AutoLoaderServiceImpl]-WARNING 2010-08-25 16:59:49,285 Unable to read a JBI descriptor java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:114) at java.util.zip.ZipFile.<init>(ZipFile.java:75) at org.ow2.petals.jbi.management.util.PackageHelper.loadDescriptor(PackageHelper.java:126) at org.ow2.petals.jbi.management.autoload.AutoLoaderServiceImpl.getJBIArchives(AutoLoaderServiceImpl.java:361) at org.ow2.petals.jbi.management.autoload.AutoLoaderServiceImpl.install(AutoLoaderServiceImpl.java:132) at org.ow2.petals.jbi.management.autoload.InstallDirectoryScanner.run(InstallDirectoryScanner.java:81) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) [Petals.AutoLoaderServiceImpl]-WARNING 2010-08-25 16:59:49,287 Unable to read a JBI descriptor java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:114) at java.util.zip.ZipFile.<init>(ZipFile.java:75) at org.ow2.petals.jbi.management.util.PackageHelper.loadDescriptor(PackageHelper.java:126) at org.ow2.petals.jbi.management.autoload.AutoLoaderServiceImpl.getJBIArchives(AutoLoaderServiceImpl.java:361) at org.ow2.petals.jbi.management.autoload.AutoLoaderServiceImpl.install(AutoLoaderServiceImpl.java:148) at org.ow2.petals.jbi.management.autoload.InstallDirectoryScanner.run(InstallDirectoryScanner.java:81) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) [Petals.AutoLoaderServiceImpl]-WARNING 2010-08-25 16:59:49,288 Unable to read a JBI descriptor java.util.zip.ZipException: error in opening zip file at java.util.zip.ZipFile.open(Native Method) at java.util.zip.ZipFile.<init>(ZipFile.java:114) at java.util.zip.ZipFile.<init>(ZipFile.java:75) at org.ow2.petals.jbi.management.util.PackageHelper.loadDescriptor(PackageHelper.java:126) at org.ow2.petals.jbi.management.autoload.AutoLoaderServiceImpl.getJBIArchives(AutoLoaderServiceImpl.java:361) at org.ow2.petals.jbi.management.autoload.AutoLoaderServiceImpl.install(AutoLoaderServiceImpl.java:165) at org.ow2.petals.jbi.management.autoload.InstallDirectoryScanner.run(InstallDirectoryScanner.java:81) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) [Petals.AutoLoaderServiceImpl]-WARNING 2010-08-25 16:59:49,288 The archive 'petals-bc-presto-1.0-SNAPSHOT.zip' remains in the install list. PEtALS deletes it
  • Environment:
    Linux Ubuntu

Activity

Hide
Sébastien André added a comment - Fri, 15 Oct 2010 - 19:09:30 +0200

I remember having the same problem before.

A client specifically asked to disable the autoloader on his production servers because it lowers performances to spool a directory like that.

I suggest to remove the autoloader when the petals-cli will be working.

Instead of "cp component.zip install/", one will have to type "petals-cli deploy component.zip".

Show
Sébastien André added a comment - Fri, 15 Oct 2010 - 19:09:30 +0200 I remember having the same problem before. A client specifically asked to disable the autoloader on his production servers because it lowers performances to spool a directory like that. I suggest to remove the autoloader when the petals-cli will be working. Instead of "cp component.zip install/", one will have to type "petals-cli deploy component.zip".
Hide
Christophe Hamerling added a comment - Mon, 18 Oct 2010 - 10:07:57 +0200

In my current custom distribution, I introduced an artifact repository for components, SA and SL. My management console use this artifact repository to deploy/install artefacts using extensions of the Petals Management API ie no more file copy into the install folder.

Show
Christophe Hamerling added a comment - Mon, 18 Oct 2010 - 10:07:57 +0200 In my current custom distribution, I introduced an artifact repository for components, SA and SL. My management console use this artifact repository to deploy/install artefacts using extensions of the Petals Management API ie no more file copy into the install folder.
Hide
Roland Naudin added a comment - Mon, 18 Oct 2010 - 10:15:34 +0200 - edited

The question is, do you have a drag and drop system that works?
The point in the current system is to detect that a file is locked, because it is not totally transferred in the 'install' repository.
I have tried things, around NIO, but it do not work apparently. Did you try Pierre Yves with the 'sync write mode' set to true on the OS?
Christophe Deneux was speaking of some algo he has done for that 'lock' issue, don't know what...

Show
Roland Naudin added a comment - Mon, 18 Oct 2010 - 10:15:34 +0200 - edited The question is, do you have a drag and drop system that works? The point in the current system is to detect that a file is locked, because it is not totally transferred in the 'install' repository. I have tried things, around NIO, but it do not work apparently. Did you try Pierre Yves with the 'sync write mode' set to true on the OS? Christophe Deneux was speaking of some algo he has done for that 'lock' issue, don't know what...
Hide
Christophe Hamerling added a comment - Mon, 18 Oct 2010 - 10:21:13 +0200

I usually dnd webapps about 80 Mo in tomcat and I never see problems... If dnd must be supported in petals, maybe some have to look the tomcat code...

Show
Christophe Hamerling added a comment - Mon, 18 Oct 2010 - 10:21:13 +0200 I usually dnd webapps about 80 Mo in tomcat and I never see problems... If dnd must be supported in petals, maybe some have to look the tomcat code...
Hide
Christophe DENEUX added a comment - Mon, 2 May 2011 - 12:12:59 +0200 - edited

Pierre-Yves,

Are you downloading the JBI archive directly into the directory 'install' of the autoloader ? With which browser ?
Log traces are the same as PETALSESBCONT-127. Perhaps it's a duplicated issue.

Show
Christophe DENEUX added a comment - Mon, 2 May 2011 - 12:12:59 +0200 - edited Pierre-Yves, Are you downloading the JBI archive directly into the directory 'install' of the autoloader ? With which browser ? Log traces are the same as PETALSESBCONT-127. Perhaps it's a duplicated issue.
Hide
Pierre-Yves Gibello added a comment - Mon, 9 May 2011 - 09:59:28 +0200

No browser. Simply "cp" on Linux.

Show
Pierre-Yves Gibello added a comment - Mon, 9 May 2011 - 09:59:28 +0200 No browser. Simply "cp" on Linux.

People

Dates

  • Created:
    Wed, 25 Aug 2010 - 17:07:27 +0200
    Updated:
    Mon, 9 May 2011 - 09:59:28 +0200