[jira] [Updated] (OAK-3419) ClusterNodeInfo.createInstance fails to clean up random entries
[
https://issues.apache.org/jira/browse/OAK-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-3419:
Affects Version/s: 1.0.19
> ClusterNodeInfo.createInstance fails to clean up random entries
> ---
>
> Key: OAK-3419
> URL: https://issues.apache.org/jira/browse/OAK-3419
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.2.4, 1.3.5, 1.0.19
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Labels: resilience
> Fix For: 1.3.7
>
>
> {code}
> String mId = "" + doc.get(MACHINE_ID_KEY);
> String iId = "" + doc.get(INSTANCE_ID_KEY);
> if (machineId.startsWith(RANDOM_PREFIX)) {
> // remove expired entries with random keys
> store.remove(Collection.CLUSTER_NODES, key);
> continue;
> }
> {code}
> The intent seems to be to cleanup entries in the cluster node table that
> start with RANDOM_PREFIX. However, {{machineId}} is checked instead of
> {{mId}}. When {{createInstance}} is called with a random id, the whole table
> might get wiped out.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3419) ClusterNodeInfo.createInstance fails to clean up random entries
[
https://issues.apache.org/jira/browse/OAK-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke resolved OAK-3419.
-
Resolution: Fixed
trunk: http://svn.apache.org/r1703878
1.2: http://svn.apache.org/r1703882
1.0: http://svn.apache.org/r1703883
> ClusterNodeInfo.createInstance fails to clean up random entries
> ---
>
> Key: OAK-3419
> URL: https://issues.apache.org/jira/browse/OAK-3419
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.2.4, 1.3.5, 1.0.19
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Labels: resilience
> Fix For: 1.3.7, 1.2.7, 1.0.22
>
>
> {code}
> String mId = "" + doc.get(MACHINE_ID_KEY);
> String iId = "" + doc.get(INSTANCE_ID_KEY);
> if (machineId.startsWith(RANDOM_PREFIX)) {
> // remove expired entries with random keys
> store.remove(Collection.CLUSTER_NODES, key);
> continue;
> }
> {code}
> The intent seems to be to cleanup entries in the cluster node table that
> start with RANDOM_PREFIX. However, {{machineId}} is checked instead of
> {{mId}}. When {{createInstance}} is called with a random id, the whole table
> might get wiped out.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3419) ClusterNodeInfo.createInstance fails to clean up random entries
[
https://issues.apache.org/jira/browse/OAK-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-3419:
Fix Version/s: 1.2.7
> ClusterNodeInfo.createInstance fails to clean up random entries
> ---
>
> Key: OAK-3419
> URL: https://issues.apache.org/jira/browse/OAK-3419
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.2.4, 1.3.5, 1.0.19
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Labels: resilience
> Fix For: 1.3.7, 1.2.7, 1.0.22
>
>
> {code}
> String mId = "" + doc.get(MACHINE_ID_KEY);
> String iId = "" + doc.get(INSTANCE_ID_KEY);
> if (machineId.startsWith(RANDOM_PREFIX)) {
> // remove expired entries with random keys
> store.remove(Collection.CLUSTER_NODES, key);
> continue;
> }
> {code}
> The intent seems to be to cleanup entries in the cluster node table that
> start with RANDOM_PREFIX. However, {{machineId}} is checked instead of
> {{mId}}. When {{createInstance}} is called with a random id, the whole table
> might get wiped out.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3419) ClusterNodeInfo.createInstance fails to clean up random entries
[
https://issues.apache.org/jira/browse/OAK-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-3419:
Fix Version/s: 1.0.22
> ClusterNodeInfo.createInstance fails to clean up random entries
> ---
>
> Key: OAK-3419
> URL: https://issues.apache.org/jira/browse/OAK-3419
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.2.4, 1.3.5, 1.0.19
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Labels: resilience
> Fix For: 1.3.7, 1.2.7, 1.0.22
>
>
> {code}
> String mId = "" + doc.get(MACHINE_ID_KEY);
> String iId = "" + doc.get(INSTANCE_ID_KEY);
> if (machineId.startsWith(RANDOM_PREFIX)) {
> // remove expired entries with random keys
> store.remove(Collection.CLUSTER_NODES, key);
> continue;
> }
> {code}
> The intent seems to be to cleanup entries in the cluster node table that
> start with RANDOM_PREFIX. However, {{machineId}} is checked instead of
> {{mId}}. When {{createInstance}} is called with a random id, the whole table
> might get wiped out.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-3423) RandomAuthorizableNodeName should not be part of the default configuration of SecurityProviderImpl
Francesco Mari created OAK-3423:
---
Summary: RandomAuthorizableNodeName should not be part of the
default configuration of SecurityProviderImpl
Key: OAK-3423
URL: https://issues.apache.org/jira/browse/OAK-3423
Project: Jackrabbit Oak
Issue Type: Bug
Components: security
Reporter: Francesco Mari
Assignee: Francesco Mari
OAK-3201 identified {{RandomAuthorizableNodeName}} as the default choice for
{{SecurityProviderImpl}}. This choice is wrong and should be reverted. In
particular, {{RandomAuthorizableNodeName}} should switch back to a required
configuration policy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3418) ClusterNodeInfo uses irrelevant network interface IDs on Windows
[ https://issues.apache.org/jira/browse/OAK-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14875746#comment-14875746 ] Julian Reschke commented on OAK-3418: - Maybe we could count the number of unique bytes, and when that's below a certain threshold (3?) push the id to a fallback list only to be used if the "good" list is empty? > ClusterNodeInfo uses irrelevant network interface IDs on Windows > > > Key: OAK-3418 > URL: https://issues.apache.org/jira/browse/OAK-3418 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Julian Reschke >Assignee: Thomas Mueller > Labels: resilience > Fix For: 1.3.7 > > > On Windows, all kinds of adapters (tunnel, VPN) return a hardware address of > 00-00-00-00-00-00-00-E0 (note 8 bytes, not 6). These addresses are useless > for the identification of the machine, however they get used because they are > the lowest value. > A potential fix is to change the validity check to: > if (mac != null && mac.length == 6) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3419) ClusterNodeInfo.createInstance fails to clean up random entries
[
https://issues.apache.org/jira/browse/OAK-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-3419:
Affects Version/s: 1.2.4
> ClusterNodeInfo.createInstance fails to clean up random entries
> ---
>
> Key: OAK-3419
> URL: https://issues.apache.org/jira/browse/OAK-3419
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.2.4, 1.3.5
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Labels: resilience
> Fix For: 1.3.7
>
>
> {code}
> String mId = "" + doc.get(MACHINE_ID_KEY);
> String iId = "" + doc.get(INSTANCE_ID_KEY);
> if (machineId.startsWith(RANDOM_PREFIX)) {
> // remove expired entries with random keys
> store.remove(Collection.CLUSTER_NODES, key);
> continue;
> }
> {code}
> The intent seems to be to cleanup entries in the cluster node table that
> start with RANDOM_PREFIX. However, {{machineId}} is checked instead of
> {{mId}}. When {{createInstance}} is called with a random id, the whole table
> might get wiped out.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3419) ClusterNodeInfo.createInstance fails to clean up random entries
[
https://issues.apache.org/jira/browse/OAK-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-3419:
Fix Version/s: 1.3.7
> ClusterNodeInfo.createInstance fails to clean up random entries
> ---
>
> Key: OAK-3419
> URL: https://issues.apache.org/jira/browse/OAK-3419
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.2.4, 1.3.5
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Labels: resilience
> Fix For: 1.3.7
>
>
> {code}
> String mId = "" + doc.get(MACHINE_ID_KEY);
> String iId = "" + doc.get(INSTANCE_ID_KEY);
> if (machineId.startsWith(RANDOM_PREFIX)) {
> // remove expired entries with random keys
> store.remove(Collection.CLUSTER_NODES, key);
> continue;
> }
> {code}
> The intent seems to be to cleanup entries in the cluster node table that
> start with RANDOM_PREFIX. However, {{machineId}} is checked instead of
> {{mId}}. When {{createInstance}} is called with a random id, the whole table
> might get wiped out.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3418) ClusterNodeInfo uses irrelevant network interface IDs on Windows
[ https://issues.apache.org/jira/browse/OAK-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14875735#comment-14875735 ] Julian Reschke commented on OAK-3418: - Another source of error: ClusterNodeInfo just decided to pick the loopback device, which had an empty, non-null hardware address which resulted in a "" string representation. > ClusterNodeInfo uses irrelevant network interface IDs on Windows > > > Key: OAK-3418 > URL: https://issues.apache.org/jira/browse/OAK-3418 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Julian Reschke >Assignee: Thomas Mueller > Labels: resilience > Fix For: 1.3.7 > > > On Windows, all kinds of adapters (tunnel, VPN) return a hardware address of > 00-00-00-00-00-00-00-E0 (note 8 bytes, not 6). These addresses are useless > for the identification of the machine, however they get used because they are > the lowest value. > A potential fix is to change the validity check to: > if (mac != null && mac.length == 6) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3422) RDBDocumentStore: improve index diagnostics
[ https://issues.apache.org/jira/browse/OAK-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-3422. - Resolution: Fixed trunk: http://svn.apache.org/r703858 1.2: http://svn.apache.org/r1703864 1.0: http://svn.apache.org/r1703870 > RDBDocumentStore: improve index diagnostics > --- > > Key: OAK-3422 > URL: https://issues.apache.org/jira/browse/OAK-3422 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Affects Versions: 1.2.4, 1.3.5, 1.0.19 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.3.7, 1.2.7, 1.0.22 > > > ...by including the index type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3422) RDBDocumentStore: improve index diagnostics
[ https://issues.apache.org/jira/browse/OAK-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3422: Fix Version/s: 1.0.22 > RDBDocumentStore: improve index diagnostics > --- > > Key: OAK-3422 > URL: https://issues.apache.org/jira/browse/OAK-3422 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Affects Versions: 1.2.4, 1.3.5, 1.0.19 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.3.7, 1.2.7, 1.0.22 > > > ...by including the index type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3422) RDBDocumentStore: improve index diagnostics
[ https://issues.apache.org/jira/browse/OAK-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3422: Fix Version/s: 1.2.7 > RDBDocumentStore: improve index diagnostics > --- > > Key: OAK-3422 > URL: https://issues.apache.org/jira/browse/OAK-3422 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Affects Versions: 1.2.4, 1.3.5, 1.0.19 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.3.7, 1.2.7 > > > ...by including the index type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OAK-3419) ClusterNodeInfo.createInstance fails to clean up random entries
[
https://issues.apache.org/jira/browse/OAK-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke reassigned OAK-3419:
---
Assignee: Julian Reschke
> ClusterNodeInfo.createInstance fails to clean up random entries
> ---
>
> Key: OAK-3419
> URL: https://issues.apache.org/jira/browse/OAK-3419
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.3.5
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Labels: resilience
>
> {code}
> String mId = "" + doc.get(MACHINE_ID_KEY);
> String iId = "" + doc.get(INSTANCE_ID_KEY);
> if (machineId.startsWith(RANDOM_PREFIX)) {
> // remove expired entries with random keys
> store.remove(Collection.CLUSTER_NODES, key);
> continue;
> }
> {code}
> The intent seems to be to cleanup entries in the cluster node table that
> start with RANDOM_PREFIX. However, {{machineId}} is checked instead of
> {{mId}}. When {{createInstance}} is called with a random id, the whole table
> might get wiped out.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3419) ClusterNodeInfo.createInstance fails to clean up random entries
[
https://issues.apache.org/jira/browse/OAK-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-3419:
Affects Version/s: 1.3.5
> ClusterNodeInfo.createInstance fails to clean up random entries
> ---
>
> Key: OAK-3419
> URL: https://issues.apache.org/jira/browse/OAK-3419
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.3.5
>Reporter: Julian Reschke
>Assignee: Julian Reschke
> Labels: resilience
>
> {code}
> String mId = "" + doc.get(MACHINE_ID_KEY);
> String iId = "" + doc.get(INSTANCE_ID_KEY);
> if (machineId.startsWith(RANDOM_PREFIX)) {
> // remove expired entries with random keys
> store.remove(Collection.CLUSTER_NODES, key);
> continue;
> }
> {code}
> The intent seems to be to cleanup entries in the cluster node table that
> start with RANDOM_PREFIX. However, {{machineId}} is checked instead of
> {{mId}}. When {{createInstance}} is called with a random id, the whole table
> might get wiped out.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3421) RDBDocumentStore: force DB2 to use a clustered index
[ https://issues.apache.org/jira/browse/OAK-3421?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3421: Attachment: OAK-3421.diff (work in progress) > RDBDocumentStore: force DB2 to use a clustered index > > > Key: OAK-3421 > URL: https://issues.apache.org/jira/browse/OAK-3421 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke > Attachments: OAK-3421.diff > > > DB2 by default does not create a clustered index; consider to force it to do > so. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3422) RDBDocumentStore: improve index diagnostics
[ https://issues.apache.org/jira/browse/OAK-3422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3422: Fix Version/s: 1.3.7 > RDBDocumentStore: improve index diagnostics > --- > > Key: OAK-3422 > URL: https://issues.apache.org/jira/browse/OAK-3422 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Affects Versions: 1.2.4, 1.3.5, 1.0.19 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.3.7 > > > ...by including the index type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3418) ClusterNodeInfo uses irrelevant network interface IDs on Windows
[ https://issues.apache.org/jira/browse/OAK-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14875635#comment-14875635 ] Thomas Mueller commented on OAK-3418: - Probably as part of another Jira issue: In order to re-use the cluster id, we should consider decreasing the lease time, and maybe sleep until the lease is expired. > ClusterNodeInfo uses irrelevant network interface IDs on Windows > > > Key: OAK-3418 > URL: https://issues.apache.org/jira/browse/OAK-3418 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Julian Reschke >Assignee: Thomas Mueller > Labels: resilience > Fix For: 1.3.7 > > > On Windows, all kinds of adapters (tunnel, VPN) return a hardware address of > 00-00-00-00-00-00-00-E0 (note 8 bytes, not 6). These addresses are useless > for the identification of the machine, however they get used because they are > the lowest value. > A potential fix is to change the validity check to: > if (mac != null && mac.length == 6) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3418) ClusterNodeInfo uses irrelevant network interface IDs on Windows
[
https://issues.apache.org/jira/browse/OAK-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14875634#comment-14875634
]
Thomas Mueller commented on OAK-3418:
-
We might want to use the most "stable" mac address. There might be multiple:
{noformat}
Windows:
name:eth1 (Bluetooth Device (Personal Area Network)) (without IPv4 address)
name:eth2 (Realtek PCIe GBE Family Controller)
name:eth3 (Cisco AnyConnect Secure Mobility Client Virtual Miniport Adapter for
Windows x64)
name:net3 (Microsoft Wi-Fi Direct Virtual Adapter) (without IPv4)
name:net2 (Microsoft Teredo Tunneling Adapter) -> 00e0
name:net4 (Microsoft ISATAP Adapter #2) -> 00e0
name:net5 (Dell Wireless 1703 802.11b|g|n (2.4GHz)) (without IPv4)
MacOS:
name:awdl0 (awdl0) (Apple Wireless Direct Link; Bluetooth; without IPv4)
name:en0 (en0)
{noformat}
> ClusterNodeInfo uses irrelevant network interface IDs on Windows
>
>
> Key: OAK-3418
> URL: https://issues.apache.org/jira/browse/OAK-3418
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Julian Reschke
>Assignee: Thomas Mueller
> Labels: resilience
> Fix For: 1.3.7
>
>
> On Windows, all kinds of adapters (tunnel, VPN) return a hardware address of
> 00-00-00-00-00-00-00-E0 (note 8 bytes, not 6). These addresses are useless
> for the identification of the machine, however they get used because they are
> the lowest value.
> A potential fix is to change the validity check to:
> if (mac != null && mac.length == 6)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-3422) RDBDocumentStore: improve index diagnostics
Julian Reschke created OAK-3422: --- Summary: RDBDocumentStore: improve index diagnostics Key: OAK-3422 URL: https://issues.apache.org/jira/browse/OAK-3422 Project: Jackrabbit Oak Issue Type: Technical task Components: rdbmk Affects Versions: 1.0.19, 1.3.5, 1.2.4 Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor ...by including the index type. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3421) RDBDocumentStore: force DB2 to use a clustered index
Julian Reschke created OAK-3421: --- Summary: RDBDocumentStore: force DB2 to use a clustered index Key: OAK-3421 URL: https://issues.apache.org/jira/browse/OAK-3421 Project: Jackrabbit Oak Issue Type: Technical task Components: rdbmk Reporter: Julian Reschke DB2 by default does not create a clustered index; consider to force it to do so. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3418) ClusterNodeInfo uses irrelevant network interface IDs on Windows
[ https://issues.apache.org/jira/browse/OAK-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14875629#comment-14875629 ] Julian Reschke commented on OAK-3418: - Proposal: 1) For now, filter out the problematic hardware address 2) Improve logging (DocumentNodeStore startup could log a new more details about the ClusterNodeInfo it is using) 3) Create a separate issue for a "proper" solution of the problem > ClusterNodeInfo uses irrelevant network interface IDs on Windows > > > Key: OAK-3418 > URL: https://issues.apache.org/jira/browse/OAK-3418 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Julian Reschke >Assignee: Thomas Mueller > Labels: resilience > Fix For: 1.3.7 > > > On Windows, all kinds of adapters (tunnel, VPN) return a hardware address of > 00-00-00-00-00-00-00-E0 (note 8 bytes, not 6). These addresses are useless > for the identification of the machine, however they get used because they are > the lowest value. > A potential fix is to change the validity check to: > if (mac != null && mac.length == 6) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3418) ClusterNodeInfo uses irrelevant network interface IDs on Windows
[ https://issues.apache.org/jira/browse/OAK-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14875624#comment-14875624 ] Thomas Mueller commented on OAK-3418: - See also http://stackoverflow.com/questions/16448995/get-mac-address-of-system-in-java > ClusterNodeInfo uses irrelevant network interface IDs on Windows > > > Key: OAK-3418 > URL: https://issues.apache.org/jira/browse/OAK-3418 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Julian Reschke >Assignee: Thomas Mueller > Labels: resilience > Fix For: 1.3.7 > > > On Windows, all kinds of adapters (tunnel, VPN) return a hardware address of > 00-00-00-00-00-00-00-E0 (note 8 bytes, not 6). These addresses are useless > for the identification of the machine, however they get used because they are > the lowest value. > A potential fix is to change the validity check to: > if (mac != null && mac.length == 6) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3418) ClusterNodeInfo uses irrelevant network interface IDs on Windows
[ https://issues.apache.org/jira/browse/OAK-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-3418: Fix Version/s: 1.3.7 > ClusterNodeInfo uses irrelevant network interface IDs on Windows > > > Key: OAK-3418 > URL: https://issues.apache.org/jira/browse/OAK-3418 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Julian Reschke >Assignee: Thomas Mueller > Labels: resilience > Fix For: 1.3.7 > > > On Windows, all kinds of adapters (tunnel, VPN) return a hardware address of > 00-00-00-00-00-00-00-E0 (note 8 bytes, not 6). These addresses are useless > for the identification of the machine, however they get used because they are > the lowest value. > A potential fix is to change the validity check to: > if (mac != null && mac.length == 6) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OAK-3418) ClusterNodeInfo uses irrelevant network interface IDs on Windows
[ https://issues.apache.org/jira/browse/OAK-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller reassigned OAK-3418: --- Assignee: Thomas Mueller > ClusterNodeInfo uses irrelevant network interface IDs on Windows > > > Key: OAK-3418 > URL: https://issues.apache.org/jira/browse/OAK-3418 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Julian Reschke >Assignee: Thomas Mueller > Labels: resilience > > On Windows, all kinds of adapters (tunnel, VPN) return a hardware address of > 00-00-00-00-00-00-00-E0 (note 8 bytes, not 6). These addresses are useless > for the identification of the machine, however they get used because they are > the lowest value. > A potential fix is to change the validity check to: > if (mac != null && mac.length == 6) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3416) Query: join on different property types fails
[
https://issues.apache.org/jira/browse/OAK-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14847307#comment-14847307
]
Thomas Mueller commented on OAK-3416:
-
http://svn.apache.org/r1703776 (trunk)
> Query: join on different property types fails
> -
>
> Key: OAK-3416
> URL: https://issues.apache.org/jira/browse/OAK-3416
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Fix For: 1.3.7
>
>
> A join on properties with different node types, for example reference and
> string, does not work as expected. Example:
> {noformat}
> select [a].* from [nt:unstructured] as [a]
> inner join [nt:unstructured] as [b]
> on [a].[jcr:uuid] = [b].[join] where issamenode([a], '/a')
> {noformat}
> The query works as expected if the property "join" is of type string, but not
> it is of type reference.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3416) Query: join on different property types fails
[
https://issues.apache.org/jira/browse/OAK-3416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Mueller resolved OAK-3416.
-
Resolution: Fixed
> Query: join on different property types fails
> -
>
> Key: OAK-3416
> URL: https://issues.apache.org/jira/browse/OAK-3416
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: query
>Reporter: Thomas Mueller
>Assignee: Thomas Mueller
> Fix For: 1.3.7
>
>
> A join on properties with different node types, for example reference and
> string, does not work as expected. Example:
> {noformat}
> select [a].* from [nt:unstructured] as [a]
> inner join [nt:unstructured] as [b]
> on [a].[jcr:uuid] = [b].[join] where issamenode([a], '/a')
> {noformat}
> The query works as expected if the property "join" is of type string, but not
> it is of type reference.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3420) DocumentNodeStoreService fails to restart DocumentNodeStore
[ https://issues.apache.org/jira/browse/OAK-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3420: Attachment: DocumentNodeStoreConfigTest.groovy modified test class showing the problem > DocumentNodeStoreService fails to restart DocumentNodeStore > --- > > Key: OAK-3420 > URL: https://issues.apache.org/jira/browse/OAK-3420 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Julian Reschke > Labels: resilience > Attachments: DocumentNodeStoreConfigTest.groovy > > > Scenario (test case will follow): > 1) service configured for RDBDocumentStore with DataSources > 2) gets started > 3) DataSource unregisters, DocumentNodeStore gets shut down > 4) DataSource is registered again > 5) restart of DocumentNodeStore fails with NPE because at least one required > component (executor?) now is null > We need to decide whether this is a scenario that should be supported or not. > If yes, we need to fix it. If no, we need to make the code more robust and > improve diagnostics. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3418) ClusterNodeInfo uses irrelevant network interface IDs on Windows
[ https://issues.apache.org/jira/browse/OAK-3418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3418: Labels: resilience (was: ) > ClusterNodeInfo uses irrelevant network interface IDs on Windows > > > Key: OAK-3418 > URL: https://issues.apache.org/jira/browse/OAK-3418 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Julian Reschke > Labels: resilience > > On Windows, all kinds of adapters (tunnel, VPN) return a hardware address of > 00-00-00-00-00-00-00-E0 (note 8 bytes, not 6). These addresses are useless > for the identification of the machine, however they get used because they are > the lowest value. > A potential fix is to change the validity check to: > if (mac != null && mac.length == 6) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3419) ClusterNodeInfo.createInstance fails to clean up random entries
[
https://issues.apache.org/jira/browse/OAK-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-3419:
Labels: resilience (was: )
> ClusterNodeInfo.createInstance fails to clean up random entries
> ---
>
> Key: OAK-3419
> URL: https://issues.apache.org/jira/browse/OAK-3419
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Julian Reschke
> Labels: resilience
>
> {code}
> String mId = "" + doc.get(MACHINE_ID_KEY);
> String iId = "" + doc.get(INSTANCE_ID_KEY);
> if (machineId.startsWith(RANDOM_PREFIX)) {
> // remove expired entries with random keys
> store.remove(Collection.CLUSTER_NODES, key);
> continue;
> }
> {code}
> The intent seems to be to cleanup entries in the cluster node table that
> start with RANDOM_PREFIX. However, {{machineId}} is checked instead of
> {{mId}}. When {{createInstance}} is called with a random id, the whole table
> might get wiped out.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3420) DocumentNodeStoreService fails to restart DocumentNodeStore
[ https://issues.apache.org/jira/browse/OAK-3420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3420: Labels: resilience (was: ) > DocumentNodeStoreService fails to restart DocumentNodeStore > --- > > Key: OAK-3420 > URL: https://issues.apache.org/jira/browse/OAK-3420 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Reporter: Julian Reschke > Labels: resilience > > Scenario (test case will follow): > 1) service configured for RDBDocumentStore with DataSources > 2) gets started > 3) DataSource unregisters, DocumentNodeStore gets shut down > 4) DataSource is registered again > 5) restart of DocumentNodeStore fails with NPE because at least one required > component (executor?) now is null > We need to decide whether this is a scenario that should be supported or not. > If yes, we need to fix it. If no, we need to make the code more robust and > improve diagnostics. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3420) DocumentNodeStoreService fails to restart DocumentNodeStore
Julian Reschke created OAK-3420: --- Summary: DocumentNodeStoreService fails to restart DocumentNodeStore Key: OAK-3420 URL: https://issues.apache.org/jira/browse/OAK-3420 Project: Jackrabbit Oak Issue Type: Bug Components: core Reporter: Julian Reschke Scenario (test case will follow): 1) service configured for RDBDocumentStore with DataSources 2) gets started 3) DataSource unregisters, DocumentNodeStore gets shut down 4) DataSource is registered again 5) restart of DocumentNodeStore fails with NPE because at least one required component (executor?) now is null We need to decide whether this is a scenario that should be supported or not. If yes, we need to fix it. If no, we need to make the code more robust and improve diagnostics. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2909) Review and improve Oak and Jcr repository setup
[
https://issues.apache.org/jira/browse/OAK-2909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari updated OAK-2909:
Fix Version/s: (was: 1.3.7)
> Review and improve Oak and Jcr repository setup
> ---
>
> Key: OAK-2909
> URL: https://issues.apache.org/jira/browse/OAK-2909
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, jcr
>Reporter: Michael Dürig
>Assignee: Francesco Mari
> Labels: modularization, technical_debt
>
> There is the {{Oak}} and {{Jcr}} builder classes for setting up Oak and Jcr
> repositories. Both builders don't have clear semantics regarding the life
> cycle of the individual components they register. On top of that the
> requirements regarding those life cycles differ depending on whether the
> individual components run within an OSGi container or not. In the former case
> the container would already manage the life cycle so the builder should not.
> IMO we should specify the builders to only be used for non OSGi deployments
> and have the manage the life cycles of the components they instantiate. OTOH
> for OSGi deployments we should leverage OSGi subsystems to properly set
> things up.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-2932) Limit the scope of exported packages
[ https://issues.apache.org/jira/browse/OAK-2932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Francesco Mari updated OAK-2932: Fix Version/s: (was: 1.3.7) > Limit the scope of exported packages > > > Key: OAK-2932 > URL: https://issues.apache.org/jira/browse/OAK-2932 > Project: Jackrabbit Oak > Issue Type: Sub-task >Reporter: Michael Dürig >Assignee: Francesco Mari > Labels: modularization, osgi, technical_debt > > Oak currently exports *a lot* of packages even though those are only used by > Oak itself. We should probably leverage OSGi subsystems here and only export > the bare minimum to the outside world. This will simplify evolution of Oak > internal APIs as with the current approach changes to such APIs always leak > to the outside world. > That is, we should have an Oak OSGi sub-system as an deployment option. > Clients would then only need to deploy that into their OSGi container and > would only see APIs actually meant to be exported for everyone (like e.g. the > JCR API). At the same time Oak could go on leveraging OSGi inside this > subsystem. > cc [~bosschaert] as you introduced us to this idea. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3358) Make SecurityProviderImpl independent from OSGi
[
https://issues.apache.org/jira/browse/OAK-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari resolved OAK-3358.
-
Resolution: Not A Problem
Fix Version/s: 1.3.7
The changes made to SecurityProviderImpl to resolve OAK-3201 make this issue
irrelevant.
> Make SecurityProviderImpl independent from OSGi
> ---
>
> Key: OAK-3358
> URL: https://issues.apache.org/jira/browse/OAK-3358
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Francesco Mari
>Assignee: Francesco Mari
> Fix For: 1.3.7
>
>
> This issue is a follow-up of OAK-3201. {{SecurityProviderImpl}} is currently
> doing two different things. First, it is an implementation of
> {{SecurityProvider}} that is supposed to be used outside of OSGi. Second, it
> is an OSGi component capable of fetching its dependencies from the service
> registry.
> I propose to split this two concerns in two different classes, and apply this
> concept to both {{SecurityProviderImpl}} and its dependencies. I proposed a
> patch in OAK-3201 outlining a possible solution. The comments in OAK-3201
> provide more insights about the proposal.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3201) Use static references in SecurityProviderImpl for composite services
[
https://issues.apache.org/jira/browse/OAK-3201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Francesco Mari resolved OAK-3201.
-
Resolution: Fixed
> Use static references in SecurityProviderImpl for composite services
>
>
> Key: OAK-3201
> URL: https://issues.apache.org/jira/browse/OAK-3201
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Francesco Mari
>Assignee: Francesco Mari
> Fix For: 1.3.7
>
> Attachments: OAK-3201-01.patch, OAK-3201-02.patch, OAK-3201-03.patch,
> OAK-3201-04.patch, OAK-3201-05.patch, OAK-3201-06.patch, OAK-3201-07.patch,
> OAK-3201-08.patch, OAK-3201-09.patch, mbean-test.log
>
>
> {{SecurityProviderImpl}} has dynamic references to many other services, like
> {{RestrictionProvider}}, that represent the configuration of this component.
> Being these services dynamic, the OSGi runtime has no clear dependency
> relationship between the {{SecurityProviderImpl}} and the required services.
> Thus, it may happen that an instance of {{SecurityProviderImpl}} is published
> before the services it requires are started, creating a window where the
> {{SecurityProviderimpl}} is operating differently from the way it's
> configured.
> I suggest to turn the dynamic references in {{SecurityProviderImpl}} to
> static ones to improve the consistency of the implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3201) Use static references in SecurityProviderImpl for composite services
[
https://issues.apache.org/jira/browse/OAK-3201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14805138#comment-14805138
]
Francesco Mari commented on OAK-3201:
-
Committed in trunk in r1703758.
> Use static references in SecurityProviderImpl for composite services
>
>
> Key: OAK-3201
> URL: https://issues.apache.org/jira/browse/OAK-3201
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Reporter: Francesco Mari
>Assignee: Francesco Mari
> Fix For: 1.3.7
>
> Attachments: OAK-3201-01.patch, OAK-3201-02.patch, OAK-3201-03.patch,
> OAK-3201-04.patch, OAK-3201-05.patch, OAK-3201-06.patch, OAK-3201-07.patch,
> OAK-3201-08.patch, OAK-3201-09.patch, mbean-test.log
>
>
> {{SecurityProviderImpl}} has dynamic references to many other services, like
> {{RestrictionProvider}}, that represent the configuration of this component.
> Being these services dynamic, the OSGi runtime has no clear dependency
> relationship between the {{SecurityProviderImpl}} and the required services.
> Thus, it may happen that an instance of {{SecurityProviderImpl}} is published
> before the services it requires are started, creating a window where the
> {{SecurityProviderimpl}} is operating differently from the way it's
> configured.
> I suggest to turn the dynamic references in {{SecurityProviderImpl}} to
> static ones to improve the consistency of the implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
