[
https://issues.apache.org/jira/browse/OAK-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15013544#comment-15013544
]
Thomas Mueller commented on OAK-2843:
-------------------------------------
I implemented a new broadcast algorithm "tcp". The configuration options are:
"sendTo" (default: "localhost"), which is the space separated list of hosts (ip
addresses). "ports" with a start end end port (default 9800 and 9810). "key"
the unique repository id. Example configuration:
{noformat}
launchpad configuration (escaped):
persistentCache="crx-quickstart/repository/cache,size\=1024,binary\=0,broadcast\=tcp:key
123"
persistent cache URI (not escaped):
repo/cache,size=1024,broadcast=tcp:key hello;sendTo 192.168.0.1
192.168.0.2;ports 9100 9200
{noformat}
Currently, a unique "key" needs to be manually configured for each cluster
node. This key needs to be unique for the repository (each repository needs a
separate key), to make sure cluster nodes only talk to other cluster nodes of
the same repository. It would be much better to auto-configure this setting.
The "key" should not be stored in the repository once and then re-used, but
generated each time a new cluster node is added or removed, to ensure the key
is unique even if the repository backend storage is copied. Probably the best
place for that is in org.apache.jackrabbit.oak.plugins.document.ClusterView
(part of DocumentDiscoveryLiteService).
> 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
> Fix For: 1.3.11
>
>
> 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)
