[jira] [Commented] (OAK-7456) Build Jackrabbit Oak #1412 failed
[ https://issues.apache.org/jira/browse/OAK-7456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16459281#comment-16459281 ] Hudson commented on OAK-7456: - Previously failing build now is OK. Passed run: [Jackrabbit Oak #1416|https://builds.apache.org/job/Jackrabbit%20Oak/1416/] [console log|https://builds.apache.org/job/Jackrabbit%20Oak/1416/console] > Build Jackrabbit Oak #1412 failed > - > > Key: OAK-7456 > URL: https://issues.apache.org/jira/browse/OAK-7456 > Project: Jackrabbit Oak > Issue Type: Bug > Components: continuous integration >Reporter: Hudson >Priority: Major > > No description is provided > The build Jackrabbit Oak #1412 has failed. > First failed run: [Jackrabbit Oak > #1412|https://builds.apache.org/job/Jackrabbit%20Oak/1412/] [console > log|https://builds.apache.org/job/Jackrabbit%20Oak/1412/console] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (OAK-7459) oak-run compact should support Azure Segment Store
[
https://issues.apache.org/jira/browse/OAK-7459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16458423#comment-16458423
]
Tomek Rękawek commented on OAK-7459:
It seems that if we want to use a single-string, we should create it on our
own. The official AzCopy tool, which can be used to copy blobs between
containers and have similar requirements as our oak-upgrade, uses at least two
strings:
* the HTTP referencing the blob (contains account name, container name and
path): https://myaccount.blob.core.windows.net/mycontainer/abc.txt
* the secret key.
Reference:
https://docs.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-linux#download-single-blob
> oak-run compact should support Azure Segment Store
> --
>
> Key: OAK-7459
> URL: https://issues.apache.org/jira/browse/OAK-7459
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: run, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
> Labels: tooling
> Fix For: 1.10, 1.9.1
>
>
> {{oak-run compact}} should accept Azure URIs for the segment store in order
> to enable OffRC for Azure Segment Store. Proposed options to add:
> * {{azure-connection}}: connection URL to to connect to the Azure Storage
> * {{azure-container}}: name of the container to use
> * {{azure-root-path}}: segment store directory
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (OAK-7459) oak-run compact should support Azure Segment Store
[
https://issues.apache.org/jira/browse/OAK-7459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16458423#comment-16458423
]
Tomek Rękawek edited comment on OAK-7459 at 4/30/18 9:23 AM:
-
It seems that if we want to use a single string, we have to create our own
format. The official AzCopy tool, which can be used to copy blobs between
containers and have similar requirements as our oak-upgrade, uses at least two
strings:
* the HTTP referencing the blob (contains account name, container name and
path): https://myaccount.blob.core.windows.net/mycontainer/abc.txt
* the secret key.
Reference:
https://docs.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-linux#download-single-blob
was (Author: tomek.rekawek):
It seems that if we want to use a single-string, we should create it on our
own. The official AzCopy tool, which can be used to copy blobs between
containers and have similar requirements as our oak-upgrade, uses at least two
strings:
* the HTTP referencing the blob (contains account name, container name and
path): https://myaccount.blob.core.windows.net/mycontainer/abc.txt
* the secret key.
Reference:
https://docs.microsoft.com/en-us/azure/storage/common/storage-use-azcopy-linux#download-single-blob
> oak-run compact should support Azure Segment Store
> --
>
> Key: OAK-7459
> URL: https://issues.apache.org/jira/browse/OAK-7459
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: run, segment-tar
>Reporter: Andrei Dulceanu
>Assignee: Andrei Dulceanu
>Priority: Major
> Labels: tooling
> Fix For: 1.10, 1.9.1
>
>
> {{oak-run compact}} should accept Azure URIs for the segment store in order
> to enable OffRC for Azure Segment Store. Proposed options to add:
> * {{azure-connection}}: connection URL to to connect to the Azure Storage
> * {{azure-container}}: name of the container to use
> * {{azure-root-path}}: segment store directory
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (OAK-6087) Avoid reads from MongoDB primary
[ https://issues.apache.org/jira/browse/OAK-6087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16458422#comment-16458422 ] Tomek Rękawek commented on OAK-6087: With regards to OAK-3865: big +1, if MongoDB now provides this kind of consistency we should use it. > Avoid reads from MongoDB primary > > > Key: OAK-6087 > URL: https://issues.apache.org/jira/browse/OAK-6087 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger >Priority: Major > Labels: scalability > Attachments: OAK-6087.patch > > > With OAK-2106 Oak now attempts to read from a MongoDB secondary when it > detects the requested data is available on the secondary. > When multiple Oak cluster nodes are deployed on a MongoDB replica set, many > reads are still directed to the primary. One of the reasons why this is seen > in practice, are observers and JCR event listeners that are triggered rather > soon after a change happens and therefore read recently modified documents. > This makes it difficult for Oak to direct calls to a nearby secondary, > because changes may not yet be available there. > A rather simple solution for the observers may be to delay processing of > changes until they are available on the near secondary. > A more sophisticated solution discussed offline could hide the replica set > entirely and always read from the nearest secondary. Writes would obviously > still go to the primary, but only return when the write is available also on > the nearest secondary. This guarantees that any subsequent read is able to > see the preceding write. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
