It's quite likely the blob is being downloaded from S3 as Thomas mentioned.
The fixes done only affect the DSGC code paths.
There is a S3DataStore property - proactiveCaching which you can turn off
as it is true by default.
Thanks
Amit
On Fri, Sep 16, 2016 at 12:13 PM, Chetan Mehrotra wrote:
>
I think we fixes have been recently done in this area. However it
would be good to have an integration test for reference check scenario
to ensure that it unnecessarily does not download the blobs
Chetan Mehrotra
On Fri, Sep 16, 2016 at 11:56 AM, Thomas Mueller wrote:
> Hi,
>
> Possibly the bina
Hi,
Possibly the binary is downloaded from S3 in this case. We have seen
similar performance issues with datastore GC when using the S3 datastore.
It should be possible to verify this with full thread dumps. Plus we would
see where exactly the download occurs. Maybe it is checking the length or
s
Hi all,
while working with Oak S3 DS I have witnessed slowness (no numbers, just
'slow' from a user perspective) in persisting a binary using its reference;
although this may be related to some environment specific issue I wondered
about the reference binary handling we introduced in JCR-3534 [1].
