[
https://issues.apache.org/jira/browse/OAK-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15024597#comment-15024597
]
Thomas Mueller commented on OAK-2843:
-------------------------------------
http://svn.apache.org/1716149 disable UDP tests, re-enable TCP tests, increase
timeout
If TCP tests fail again I would like to analyze why. The Jenkins failure is
strange, as the failure seems to be in the same thread that invalidated the key
(not via broadcasting, but via direct cache manipulation):
{noformat}
broadcastTCP(org.apache.jackrabbit.oak.plugins.document.persistentCache.BroadcastTest)
Time elapsed: 0.093 sec <<< FAILURE!
java.lang.AssertionError: expected null, but was:<Hello World 0>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotNull(Assert.java:755)
at org.junit.Assert.assertNull(Assert.java:737)
at org.junit.Assert.assertNull(Assert.java:747)
at
org.apache.jackrabbit.oak.plugins.document.persistentCache.BroadcastTest.broadcast(BroadcastTest.java:206)
at
org.apache.jackrabbit.oak.plugins.document.persistentCache.BroadcastTest.broadcastTCP(BroadcastTest.java:144)
{noformat}
> 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.12
>
>
> 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)
