[jira] [Commented] (OAK-2843) Broadcasting cache

["Thomas Mueller (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OAK-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14991832#comment-14991832 ] 

Thomas Mueller commented on OAK-2843:
-------------------------------------

http://svn.apache.org/r1712796 (trunk)

Simple in-memory (for unit tests) and UDP multicast (for demo purposes) implementations. This should allow to test if (and how much) broadcasting cache entries helps for a cluster.

To try it, change the persistent cache configuration, and append "udp:group:228.6.7.9;key:test;port:9876;aes".

Group is the multicast group. Key is the unique key; ensure each cluster uses a unique key (it would be better if that key is stored in the repository itself, but that's not done right now). AES will encrypt data, however the current implementation is just meant to see how much encryption affects performance, not for protecting or authentication.

> Broadcasting cache
> ------------------
>
>                 Key: OAK-2843
>                 URL: https://issues.apache.org/jira/browse/OAK-2843
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: mongomk
>            Reporter: Thomas Mueller
>            Assignee: Thomas Mueller
>
> In a cluster environment, we could speed up reading if the cache(s) broadcast data to other instances. This would avoid bottlenecks at the storage layer (MongoDB, RDBMs).
> The configuration metadata (IP addresses and ports of where to send data to, a unique identifier of the repository and the cluster nodes, possibly encryption key) rarely changes and can be stored in the same place as we store cluster metadata (cluster info collection). That way, in many cases no manual configuration is needed. We could use TCP/IP and / or UDP.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)