[
https://issues.apache.org/jira/browse/OAK-3885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15105177#comment-15105177
]
Julian Reschke edited comment on OAK-3885 at 1/18/16 1:55 PM:
--------------------------------------------------------------
trunk: http://svn.apache.org/r1725216
1.2: http://svn.apache.org/r1725270 http://svn.apache.org/r1725229
1.0: http://svn.apache.org/r1725272 http://svn.apache.org/r1725238
was (Author: reschke):
trunk: http://svn.apache.org/r1725216
1.2: http://svn.apache.org/r1725229
1.0: http://svn.apache.org/r1725238
> enhance stability of clusterNodeInfo's machineId
> ------------------------------------------------
>
> Key: OAK-3885
> URL: https://issues.apache.org/jira/browse/OAK-3885
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk
> Affects Versions: 1.2.9, 1.0.25, 1.3.13
> Reporter: Julian Reschke
> Assignee: Julian Reschke
> Priority: Minor
> Fix For: 1.0.26, 1.2.10, 1.3.14
>
> Attachments: OAK-3885.diff
>
>
> We currently use network interface information to derive a unique machine ID
> (ClusterNodeInfo.getMachineId()). Among the 6-byte addresses, we use the
> "smallest".
> At least on Windows machines, connecting through a VPN inserts a new low
> machineID into the list, causing the machineID to vary depending on whether
> the VPN is connected or not.
> I don't see a clean way to filter these addresses. We *could* inspect the
> names of the interfaces and treat those containing "VPN" or "Virtual" to be
> less relevant. Of course that would be an ugly hack, but it would fix the
> problem for now.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
