[
https://issues.apache.org/jira/browse/JCRVLT-339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Krystian Nowak updated JCRVLT-339:
----------------------------------
Description:
The logic in
[FSRegisteredPackage|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSPackageRegistry.java]
may be improved to handle truncated files proactively before [ZipVaultPackage
is instantiated in
FSPackageRegistry|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSPackageRegistry.java#L240]
while trying to open it to create _VaultPackage_ in [getPackage
method|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSRegisteredPackage.java#L74].
This kind of truncation is a mechanism in container based setups to effectively
reduce disk usage without functional impact.
As [getPackage in
RegisteredPackage|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/RegisteredPackage.java#L51]
is declared as not returning null (_@Nonnull_ annotation), but throwing
_IOException_ - this exceptional situation of truncation in filed-based case
might be signalled this way and handled properly by callers aware of the
truncation mechanism.
Currently the exception (in the case of file truncation) is thrown multiple
levels lower when accessing _java.util.zip.ZipFile_ with verbose and
unconditional logging on multiple levels as the one given below:
{noformat}
12.07.2019 15:06:48.730 *ERROR* [MyThread1]
org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage Error while loading
package /foo/bar/baz.zip.
12.07.2019 15:06:48.732 *ERROR* [MyThread1]
org.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry Cloud not
open file /foo/bar/baz.zip as ZipVaultPackage.
java.util.zip.ZipException: zip file is empty
at java.util.zip.ZipFile$Source.zerror(ZipFile.java:1535)
at java.util.zip.ZipFile$Source.findEND(ZipFile.java:1349)
at java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1443)
at java.util.zip.ZipFile$Source.<init>(ZipFile.java:1274)
at java.util.zip.ZipFile$Source.get(ZipFile.java:1237)
at java.util.zip.ZipFile$CleanableResource.<init>(ZipFile.java:727)
at java.util.zip.ZipFile$CleanableResource.get(ZipFile.java:844)
at java.util.zip.ZipFile.<init>(ZipFile.java:247)
at java.util.zip.ZipFile.<init>(ZipFile.java:177)
at java.util.jar.JarFile.<init>(JarFile.java:346)
at java.util.jar.JarFile.<init>(JarFile.java:317)
at java.util.jar.JarFile.<init>(JarFile.java:283)
at
org.apache.jackrabbit.vault.fs.io.ZipArchive.open(ZipArchive.java:103)
[org.apache.jackrabbit.vault:3.2.8]
at
org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.<init>(ZipVaultPackage.java:69)
[org.apache.jackrabbit.vault:3.2.8]
at
org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.<init>(ZipVaultPackage.java:61)
[org.apache.jackrabbit.vault:3.2.8]
at
org.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry.open(FSPackageRegistry.java:240)
[org.apache.jackrabbit.vault:3.2.8]
at
org.apache.jackrabbit.vault.packaging.registry.impl.FSRegisteredPackage.getPackage(FSRegisteredPackage.java:76)
[org.apache.jackrabbit.vault:3.2.8]
(...)
{noformat}
Instead a check for underlying file existence and size might be useful here and
in the case of truncated file a new implementation of
[VaultPackage|https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/VaultPackage.java]
for hollow packages might be returned.
(see also [^JCRVLT-339.patch] or this PR:
[https://github.com/apache/jackrabbit-filevault/pull/50])
Similar approach connected with underlying VLT package file truncation in
container based setups can be find in SLING-8105 and its corresponding change:
[https://github.com/apache/sling-org-apache-sling-feature-extension-content/commit/9eecc6d2137c8cafa70edcfd3faa839ed4412f4e]
was:
The logic in
[FSRegisteredPackage|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSPackageRegistry.java]
may be improved to handle truncated files proactively before [ZipVaultPackage
is instantiated in
FSPackageRegistry|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSPackageRegistry.java#L240]
while trying to open it to create _VaultPackage_ in [getPackage
method|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSRegisteredPackage.java#L74].
This kind of truncation is a mechanism in container based setups to effectively
reduce disk usage without functional impact.
As [getPackage in
RegisteredPackage|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/RegisteredPackage.java#L51]
is declared as not returning null (_@Nonnull_ annotation), but throwing
_IOException_ - this exceptional situation of truncation in filed-based case
might be signalled this way and handled properly by callers aware of the
truncation mechanism.
Currently the exception (in the case of file truncation) is thrown multiple
levels lower when accessing _java.util.zip.ZipFile_ with verbose and
unconditional logging on multiple levels as the one given below:
{noformat}
12.07.2019 15:06:48.730 *ERROR* [MyThread1]
org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage Error while loading
package /foo/bar/baz.zip.
12.07.2019 15:06:48.732 *ERROR* [MyThread1]
org.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry Cloud not
open file /foo/bar/baz.zip as ZipVaultPackage.
java.util.zip.ZipException: zip file is empty
at java.util.zip.ZipFile$Source.zerror(ZipFile.java:1535)
at java.util.zip.ZipFile$Source.findEND(ZipFile.java:1349)
at java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1443)
at java.util.zip.ZipFile$Source.<init>(ZipFile.java:1274)
at java.util.zip.ZipFile$Source.get(ZipFile.java:1237)
at java.util.zip.ZipFile$CleanableResource.<init>(ZipFile.java:727)
at java.util.zip.ZipFile$CleanableResource.get(ZipFile.java:844)
at java.util.zip.ZipFile.<init>(ZipFile.java:247)
at java.util.zip.ZipFile.<init>(ZipFile.java:177)
at java.util.jar.JarFile.<init>(JarFile.java:346)
at java.util.jar.JarFile.<init>(JarFile.java:317)
at java.util.jar.JarFile.<init>(JarFile.java:283)
at
org.apache.jackrabbit.vault.fs.io.ZipArchive.open(ZipArchive.java:103)
[org.apache.jackrabbit.vault:3.2.8]
at
org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.<init>(ZipVaultPackage.java:69)
[org.apache.jackrabbit.vault:3.2.8]
at
org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.<init>(ZipVaultPackage.java:61)
[org.apache.jackrabbit.vault:3.2.8]
at
org.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry.open(FSPackageRegistry.java:240)
[org.apache.jackrabbit.vault:3.2.8]
at
org.apache.jackrabbit.vault.packaging.registry.impl.FSRegisteredPackage.getPackage(FSRegisteredPackage.java:76)
[org.apache.jackrabbit.vault:3.2.8]
(...)
{noformat}
Instead a check for underlying file existence and size might be useful here and
in the case of truncated file a new implementation of
[VaultPackage|https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/VaultPackage.java]
for hollow packages might be returned.
(see also this PR: [https://github.com/apache/jackrabbit-filevault/pull/50])
Similar approach connected with underlying VLT package file truncation in
container based setups can be find in SLING-8105 and its corresponding change:
[https://github.com/apache/sling-org-apache-sling-feature-extension-content/commit/9eecc6d2137c8cafa70edcfd3faa839ed4412f4e]
> Add FSPackageRegistry support for hollow packages
> -------------------------------------------------
>
> Key: JCRVLT-339
> URL: https://issues.apache.org/jira/browse/JCRVLT-339
> Project: Jackrabbit FileVault
> Issue Type: Improvement
> Components: Packaging
> Affects Versions: 3.2.8
> Reporter: Krystian Nowak
> Priority: Major
> Attachments: JCRVLT-339.patch
>
>
> The logic in
> [FSRegisteredPackage|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSPackageRegistry.java]
> may be improved to handle truncated files proactively before
> [ZipVaultPackage is instantiated in
> FSPackageRegistry|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSPackageRegistry.java#L240]
> while trying to open it to create _VaultPackage_ in [getPackage
> method|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/impl/FSRegisteredPackage.java#L74].
> This kind of truncation is a mechanism in container based setups to
> effectively reduce disk usage without functional impact.
> As [getPackage in
> RegisteredPackage|https://github.com/apache/jackrabbit-filevault/blob/jackrabbit-filevault-3.2.8/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/registry/RegisteredPackage.java#L51]
> is declared as not returning null (_@Nonnull_ annotation), but throwing
> _IOException_ - this exceptional situation of truncation in filed-based case
> might be signalled this way and handled properly by callers aware of the
> truncation mechanism.
> Currently the exception (in the case of file truncation) is thrown multiple
> levels lower when accessing _java.util.zip.ZipFile_ with verbose and
> unconditional logging on multiple levels as the one given below:
> {noformat}
> 12.07.2019 15:06:48.730 *ERROR* [MyThread1]
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage Error while
> loading package /foo/bar/baz.zip.
> 12.07.2019 15:06:48.732 *ERROR* [MyThread1]
> org.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry Cloud
> not open file /foo/bar/baz.zip as ZipVaultPackage.
> java.util.zip.ZipException: zip file is empty
> at java.util.zip.ZipFile$Source.zerror(ZipFile.java:1535)
> at java.util.zip.ZipFile$Source.findEND(ZipFile.java:1349)
> at java.util.zip.ZipFile$Source.initCEN(ZipFile.java:1443)
> at java.util.zip.ZipFile$Source.<init>(ZipFile.java:1274)
> at java.util.zip.ZipFile$Source.get(ZipFile.java:1237)
> at java.util.zip.ZipFile$CleanableResource.<init>(ZipFile.java:727)
> at java.util.zip.ZipFile$CleanableResource.get(ZipFile.java:844)
> at java.util.zip.ZipFile.<init>(ZipFile.java:247)
> at java.util.zip.ZipFile.<init>(ZipFile.java:177)
> at java.util.jar.JarFile.<init>(JarFile.java:346)
> at java.util.jar.JarFile.<init>(JarFile.java:317)
> at java.util.jar.JarFile.<init>(JarFile.java:283)
> at
> org.apache.jackrabbit.vault.fs.io.ZipArchive.open(ZipArchive.java:103)
> [org.apache.jackrabbit.vault:3.2.8]
> at
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.<init>(ZipVaultPackage.java:69)
> [org.apache.jackrabbit.vault:3.2.8]
> at
> org.apache.jackrabbit.vault.packaging.impl.ZipVaultPackage.<init>(ZipVaultPackage.java:61)
> [org.apache.jackrabbit.vault:3.2.8]
> at
> org.apache.jackrabbit.vault.packaging.registry.impl.FSPackageRegistry.open(FSPackageRegistry.java:240)
> [org.apache.jackrabbit.vault:3.2.8]
> at
> org.apache.jackrabbit.vault.packaging.registry.impl.FSRegisteredPackage.getPackage(FSRegisteredPackage.java:76)
> [org.apache.jackrabbit.vault:3.2.8]
> (...)
> {noformat}
> Instead a check for underlying file existence and size might be useful here
> and in the case of truncated file a new implementation of
> [VaultPackage|https://github.com/apache/jackrabbit-filevault/blob/trunk/vault-core/src/main/java/org/apache/jackrabbit/vault/packaging/VaultPackage.java]
> for hollow packages might be returned.
> (see also [^JCRVLT-339.patch] or this PR:
> [https://github.com/apache/jackrabbit-filevault/pull/50])
> Similar approach connected with underlying VLT package file truncation in
> container based setups can be find in SLING-8105 and its corresponding
> change:
> [https://github.com/apache/sling-org-apache-sling-feature-extension-content/commit/9eecc6d2137c8cafa70edcfd3faa839ed4412f4e]
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
