[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13649562#comment-13649562
]
Tommaso Teofili commented on JCR-3534:
--------------------------------------
> the public API is still missing (BinaryReferenceMessage is in a jackrabbit
> internal package); I think a public api Binary getBinaryBySecureID() (or
> similar) like in the first patch is still required
I thought we weren't agreeing on this and we wanted no public APIs, but I'm
open to creating a public one.
> instead of resolving the message upon writing to the repository, it is
> instead written as Binary (with the message as contents)
how would you do it instead? I understood having it as a special Binary sounded
ok.
> but it's never resolved to the final binary that you want (if the message is
> valid)
when the binary reference message is received the receiving repository has to
generate a signature from the received content id using its own secret, if the
generated signature matches the signature received along with the content id in
the reference message then it means it was generated using the same secret and
therefore comes from the same repository.
Regarding the final binary if it doesn't exist or it doesn't come from the same
repository then it has to be "sent" in a subsequent call, if it exists and the
signature matches then probably the things that's missing is if that has
changed, thus probably sending something like the actual binary length as part
of the binary reference message would be helpful.
> and then you'd write the returned Binary right to the repository (no delayed
> resolution)
but to obtain this, wouldn't that mean that we basically send the final binary
itself along with the message?
> this is important, since the application level code needs to know if that
> getBinaryBySecureID() worked or not (returns non-null or not) so it can
> handle the case by asking for the full binary as stream over its own message
> protocol
> btw, some lucene-related java files are accidentally included in the patch
> with import reorgs
thanks for pointing out, probably some overlooked left out from other changes
Alex, thanks for your comments, hopefully I've clarified what my solution looks
like; if you'd use a different approach it'd be good to have a broader overview
of it (or perhaps I just misunderstood).
> Add JackrabbitSession.getValueByContentId method
> ------------------------------------------------
>
> Key: JCR-3534
> URL: https://issues.apache.org/jira/browse/JCR-3534
> Project: Jackrabbit Content Repository
> Issue Type: New Feature
> Components: jackrabbit-api, jackrabbit-core
> Affects Versions: 2.6
> Reporter: Felix Meschberger
> Assignee: Tommaso Teofili
> Attachments: JCR-3534.patch, JCR-3534.patch
>
>
> we have a couple of use cases, where we would like to leverage the global
> data store to prevent sending around and copying around large binary data
> unnecessarily: We have two separate Jackrabbit instances configured to use
> the same DataStore (for the sake of this discussion assume we have the
> problems of concurrent access and garbage collection under control). When
> sending content from one instance to the other instance we don't want to send
> potentially large binary data (e.g. video files) if not needed.
> The idea is for the sender to just send the content identity from
> JackrabbitValue.getContentIdentity(). The receiver would then check whether
> the such content already exists and would reuse if so:
> String ci = contentIdentity_from_sender;
> try {
> Value v = session.getValueByContentIdentity(ci);
> Property p = targetNode.setProperty(propName, v);
> } catch (ItemNotFoundException ie) {
> // unknown or invalid content Identity
> } catch (RepositoryException re) {
> // some other exception
> }
> Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method
> would allow for round tripping the JackrabbitValue.getContentIdentity()
> preventing superfluous binary data copying and moving.
> See also the dev@ thread
> http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
