[JCRVLT-339] Add FSPackageRegistry support for hollow packages

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 3.2.8
• Fix Version/s: 3.4.0
• Component/s: Packaging
• Assignee: Unassigned
• Reporter: Krystian Nowak
• Created: 15/Jul/19 09:10
• Updated: 13/Sep/19 07:31
• Resolved: 18/Jul/19 02:16

Description

The logic in FSRegisteredPackage may be improved to handle truncated files proactively before ZipVaultPackage is instantiated in FSPackageRegistry while trying to open it to create VaultPackage in getPackage method.

This kind of truncation is a mechanism in container based setups to effectively reduce disk usage without functional impact.
As getPackage in RegisteredPackage 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:

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]
(...)

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

Issue Links

• is related to: SLING-8105 Make ContentHandler able to handle/ignore truncated files