[
https://issues.apache.org/jira/browse/OAK-4712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15476266#comment-15476266
]
Amit Jain edited comment on OAK-4712 at 9/9/16 7:59 AM:
--------------------------------------------------------
bq. A new interface, BlobIdBlob, was added, extending Blob. This represents a
kind of blob that also has a blob ID that can be retrieved. SegmentBlob and
BlobStoreBlob now implement this interface, since both support getBlobId().
We could do an instance of check also. It is a little ugly but will not need an
public interface to expose the detail.
Apart from that couple of things I noticed about the actual path -> binary
mapping implementation.
* An important point is that current implementation only considers nodes having
{{jcr:data}} property. This should be changed as this only works for
{{nt:file}} node types.
We should consider any property of type {{Type.BINARY}}. In effect the path
input parameter should be path of the node that directly contains the binary
property and then use that to check for existence. Note that
** There can be multiple direct properties of Type.BINARY and/or
** Possibly even be an array of Type.BINARY in a single property
So, these should be taken into account probably returning false even if one of
the property found under a path to be not synced.
* A minor point but we can make use of {{PathUtils}} class instead of your
split implementation etc.
was (Author: amitjain):
bq. A new interface, BlobIdBlob, was added, extending Blob. This represents a
kind of blob that also has a blob ID that can be retrieved. SegmentBlob and
BlobStoreBlob now implement this interface, since both support getBlobId().
We could do an instance of check also. It is a little ugly but will not need an
public interface to expose the detail.
Apart from that couple of things I noticed about the actual path -> binary
mapping implementation.
* An important point is that current implementation only considers nodes having
{{jcr:data}} property. This should be changed as this only works for
{{nt:file}} node types.
We should consider any property of type {{Type.BINARY}}. In effect the path
input parameter should be path of the node that directly contains the binary
property and then use that to check for existence. Note that ** There can be
multiple direct properties of Type.BINARY and/or
** Possibly even be an array of Type.BINARY in a single property
So, these should be taken into account probably returning false even if one of
the property found under a path to be not synced.
* A minor point but we can make use of {{PathUtils}} class instead of your
split implementation etc.
> Publish S3DataStore stats in JMX MBean
> --------------------------------------
>
> Key: OAK-4712
> URL: https://issues.apache.org/jira/browse/OAK-4712
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: blob
> Reporter: Matt Ryan
> Attachments: OAK-4712.2.diff, OAK-4712.3.diff, OAK-4712.4.diff
>
>
> This feature is to publish statistics about the S3DataStore via a JMX MBean.
> There are two statistics suggested:
> * Indicate the number of files actively being synchronized from the local
> cache into S3
> * Given a path to a local file, indicate whether synchronization of file into
> S3 has completed
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
