jackrabbit-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Jackrabbit Wiki] Update of "JCR Binary Usecase" by ThomasMueller
Date Wed, 06 Jul 2016 12:03:10 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Jackrabbit Wiki" for change notification.

The "JCR Binary Usecase" page has been changed by ThomasMueller:

added UC10

  Key aspect here is that where possible we should be able to avoid IO. Also have a look at
[[https://kafka.apache.org/08/design.html#maximizingefficiency|Kafka design]] which tries
to make use of OS cache as much as possible and avoid Io via jvm if possible thus providing
much better throughputs
- === UC5 - Transferring the file to `FileDataStore` with minimal overhead ===
+ === UC5 - Transferring the file to FileDataStore with minimal overhead ===
  '' Need a way to construct JCR Binary via a File reference where File instance  "ownership
is transferred" say via rename without spooling its content again''
@@ -94, +94 @@

  Currently, each cluster node connects to S3 and has a "local cache" on the file system.
Binaries are uploaded asynchronously to S3, that means first written to the local cache. If
a binary is added in one cluster node, it is not immediately available on S3 to be read from
another cluster node, if async upload is enabled.
+ === UC10 - Efficiently concatenate / split / modify binaries ===
+ Multiple (some large) TIFF files are concatenated into a PTIFF file, and when reading, in
some cases only a subset of the PTIFF is read, and sometimes the whole. Metadata of an existing
(large) TIFF is changed.
  == Solution Proposals ==
@@ -128, +132 @@

  Or provide a way to create a JCR binary from a S3 binary. Moving from S3 to S3 might not
be a problem.
- === UC7 - Random write access in binaries ===
+ === UC7 + UC10 - Random write access in binaries ===

View raw message