You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Tobias Bocanegra (JIRA)" <ji...@apache.org> on 2019/07/16 23:40:00 UTC

[jira] [Commented] (JCRVLT-339) Add FSPackageRegistry support for hollow packages

    [ https://issues.apache.org/jira/browse/JCRVLT-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16886554#comment-16886554 ] 

Tobias Bocanegra commented on JCRVLT-339:
-----------------------------------------

thanks for the patch. [~dsuess] can you review it? you know the {{FSPackageRegistry}} better than me. thanks.

> 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)