[jira] [Updated] (OAK-3652) RDB support: extend RDB export tool for CSV export
[ https://issues.apache.org/jira/browse/OAK-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3652: Fix Version/s: 1.3.11 > RDB support: extend RDB export tool for CSV export > -- > > Key: OAK-3652 > URL: https://issues.apache.org/jira/browse/OAK-3652 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Affects Versions: 1.3.10 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.3.11 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3597) Support path based suggestions in oak.
[ https://issues.apache.org/jira/browse/OAK-3597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vikas Saurabh updated OAK-3597: --- Fix Version/s: (was: 1.4) > Support path based suggestions in oak. > -- > > Key: OAK-3597 > URL: https://issues.apache.org/jira/browse/OAK-3597 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Mohit Arora >Assignee: Vikas Saurabh > > Currently, suggestions in oak work only for certain properties for a > particular index. There should be a way to get suggestions based on path as > well. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3597) Support path based suggestions in oak.
[
https://issues.apache.org/jira/browse/OAK-3597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15011437#comment-15011437
]
Vikas Saurabh commented on OAK-3597:
Has some discussion with [~mohiaror] and his use-case required the document to
be returned with suggestion. That use-case is better server with a {{select *
from \[blah] as s where name(s) like 'foo%'}}. Removing fix version for now to
unschedule it.
> Support path based suggestions in oak.
> --
>
> Key: OAK-3597
> URL: https://issues.apache.org/jira/browse/OAK-3597
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Mohit Arora
>Assignee: Vikas Saurabh
>
> Currently, suggestions in oak work only for certain properties for a
> particular index. There should be a way to get suggestions based on path as
> well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3652) RDB support: extend RDB export tool for CSV export
[ https://issues.apache.org/jira/browse/OAK-3652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-3652. - Resolution: Fixed trunk: http://svn.apache.org/r1715010 > RDB support: extend RDB export tool for CSV export > -- > > Key: OAK-3652 > URL: https://issues.apache.org/jira/browse/OAK-3652 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Affects Versions: 1.3.10 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.3.11 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2472) Add support for atomic counters on cluster solutions
[
https://issues.apache.org/jira/browse/OAK-2472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15011329#comment-15011329
]
Davide Giannella commented on OAK-2472:
---
I'll try to summarise as best as I can the maelstrom I have in my
head.
There's an issue I'm stuck now, with the approach we took. Sooner or
later we'll have to call the [NodeStore.merge(Builder, CommitHook,
CommitInfo)|http://jackrabbit.apache.org/oak/docs/apidocs/org/apache/jackrabbit/oak/spi/state/NodeStore.html#merge%28org.apache.jackrabbit.oak.spi.state.NodeBuilder,%20org.apache.jackrabbit.oak.spi.commit.CommitHook,%20org.apache.jackrabbit.oak.spi.commit.CommitInfo%29]
in the scheduled task, in order to merge what it changed during
consolidation.
This give leave us with a problem that we don't have the CommitHooks
at the level we're playing and we need to know them.
In oak we have mainly four types of CommitHook: {{IndexEditor}},
{{Editor}}, {{ConflictHandler}} and {{CommitHook}} itself. The first
two are wrapped in their providers that are OSGi service as well.
I think we can leave the {{SecurityProvider}} as *not* a commit hook.
In the end of the repository construction, all them are converted into
one big {{CompositeCommitHook}}.
ConflictHandlers are automatically converted into CommitHook:
-
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/Oak.java#L467
EditorProvider are automatically converted into CommitHook:
-
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/Oak.java#L406
IndexEditorProvider are automatically converted into CommitHook:
-
https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/Oak.java#L620
This leave us with an "easy" answer at the question: what commit hook
should I provide? It's a Composite of all the {{List Add support for atomic counters on cluster solutions
>
>
> Key: OAK-2472
> URL: https://issues.apache.org/jira/browse/OAK-2472
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Reporter: Davide Giannella
>Assignee: Davide Giannella
> Labels: scalability
> Fix For: 1.4
>
> Attachments: atomic-counter.md
>
>
> As of OAK-2220 we added support for atomic counters in a non-clustered
> situation.
> This ticket is about covering the clustered ones.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2948) Expose DefaultSyncHandler
[
https://issues.apache.org/jira/browse/OAK-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15011568#comment-15011568
]
Tobias Bocanegra commented on OAK-2948:
---
no, the class is public:
{{org.apache.jackrabbit.oak.spi.security.authentication.external.basic.DefaultSyncConfig}}
> Expose DefaultSyncHandler
> -
>
> Key: OAK-2948
> URL: https://issues.apache.org/jira/browse/OAK-2948
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: Konrad Windszus
> Fix For: 1.3.2, 1.2.7, 1.0.22
>
>
> We do have the use case of extending the user sync. Unfortunately
> {{DefaultSyncHandler}} is not exposed, so if you want to change one single
> aspect of the user synchronisation you have to copy over the code from the
> {{DefaultSyncHandler}}. Would it be possible to make that class part of the
> exposed classes, so that deriving your own class from that DefaultSyncHandler
> is possible?
> Very often company LDAPs are not very standardized. In our case we face an
> issue, that the membership is being listed in a user attribute, rather than
> in a group attribute.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-3653) Incorrect last revision of cached node state
Vikas Saurabh created OAK-3653:
--
Summary: Incorrect last revision of cached node state
Key: OAK-3653
URL: https://issues.apache.org/jira/browse/OAK-3653
Project: Jackrabbit Oak
Issue Type: Bug
Components: documentmk
Reporter: Vikas Saurabh
While installing a package in one of the systems (Oak-1.0.16), we observed
broken workflow model. Upon further investigation, it was found that
{{baseVersion}} of the model was pointing to a node in version storage which
wasn't visible on the instance. This node was available in mongo and could also
be seen on a different instance of the cluster.
The node was created on the same instance where it wasn't visible (cluster id -
3)
Further investigation showed that for some (yet unknown) reason,
{{lastRevision}} for cached node state of node's parent at revision where the
node was created was stale (an older revision) which must have led to invalid
children list and hence unavailable node.
Attaching a few files which were captured during the investigation:
* oplog.json - oplog for +-10s for r151191c7601-0-3
* Capture.jpg - snapshot of groovy console output using script at \[0] to list
node children cache entry for parent
* Capture1.jpg - snapshot of groovy console output using script at \[1] to
traverse to invisible node
* Capture2.jpg - Almost same as Capture.jpg but this time for node cache
instead (using script at \[2])
The node which wasn't visible in mongo:
{noformat}
db.nodes.findOne({_id:
"7:/jcr:system/jcr:versionStorage/d9/9f/22/d99f2279-dcc9-40a0-9aa4-c91fe310287e/1.7"})
{
"_id" :
"7:/jcr:system/jcr:versionStorage/d9/9f/22/d99f2279-dcc9-40a0-9aa4-c91fe310287e/1.7",
"_deleted" : {
"r151191c7601-0-3" : "false"
},
"_commitRoot" : {
"r151191c7601-0-3" : "0"
},
"_lastRev" : {
"r0-0-3" : "r151191c7601-0-3"
},
"jcr:primaryType" : {
"r151191c7601-0-3" : "\"nam:nt:version\""
},
"jcr:uuid" : {
"r151191c7601-0-3" : "\"40234f1d-2435-4c6b-9962-20af22b1c948\""
},
"_modified" : NumberLong(1447825270),
"jcr:created" : {
"r151191c7601-0-3" : "\"dat:2015-11-17T21:41:14.058-08:00\""
},
"_children" : true,
"jcr:predecessors" : {
"r151191c7601-0-3" :
"[\"ref:6cecc77b-3020-4a47-b9cc-084a618aa957\"]"
},
"jcr:successors" : {
"r151191c7601-0-3" : "\"[0]:Reference\""
},
"_modCount" : NumberLong(1)
}
{noformat}
Last revision entry of cached node state of
{{/jcr:system/jcr:versionStorage/d9/9f/22/d99f2279-dcc9-40a0-9aa4-c91fe310287e}}
(parent) at revision {{r151191c7601-0-3}} was {{r14f035ebdf8-0-3}} (the last
revs were propagated correctly up till root for r151191c7601-0-3).
As a work-around, doing {{cache.invalidate(k)}} for node cache (inside the loop
of script at \[2]) revived the visibility of the node.
*Disclaimer*: _The issue was reported and investigated on a cluster backed by
mongo running on Oak-1.0.16. But, the problem itself doesn't seem like any
which have been fixed in later versions_
\[0]: {noformat}
def printNodeChildrenCache(def path) {
def session =
osgi.getService(org.apache.sling.jcr.api.SlingRepository.class).loginAdministrative(null)
try {
def rootNode = session.getRootNode()
def cache = rootNode.sessionDelegate.root.store.nodeChildrenCache
def cacheMap = cache.asMap()
cacheMap.each{k,v ->
if (k.toString().startsWith(path + "@")) {
println "${k}:${v}"
}
}
} finally {
session.logout()
}
}
printNodeChildrenCache("/jcr:system/jcr:versionStorage/d9/9f/22/d99f2279-dcc9-40a0-9aa4-c91fe310287e")
{noformat}
\[1]: {noformat}
def traverse(def path) {
def session =
osgi.getService(org.apache.sling.jcr.api.SlingRepository.class).loginAdministrative(null)
try {
def rootNode = session.getRootNode()
def nb = rootNode.sessionDelegate.root.store.root
def p = ''
path.tokenize('/').each() {
p = p + '/' + it
nb = nb.getChildNode(it)
println "${p} ${nb}"
}
} finally {
session.logout()
}
}
traverse("/jcr:system/jcr:versionStorage/d9/9f/22/d99f2279-dcc9-40a0-9aa4-c91fe310287e/1.7")
{noformat}
\[2]: {noformat}
def printNodeChildrenCache(def path) {
def session =
osgi.getService(org.apache.sling.jcr.api.SlingRepository.class).loginAdministrative(null)
try {
def rootNode = session.getRootNode()
def cache = rootNode.sessionDelegate.root.store.nodeCache
def cacheMap = cache.asMap()
cacheMap.each{k,v ->
if (k.toString().startsWith(path + "@")) {
println "${k}:${v}"
println "lastRev -> ${v.lastRevision}"
}
}
} finally {
session.logout()
}
}
[jira] [Commented] (OAK-3653) Incorrect last revision of cached node state
[
https://issues.apache.org/jira/browse/OAK-3653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15011786#comment-15011786
]
Vikas Saurabh commented on OAK-3653:
[~mreutegg], can you please take up this issue and schedule accordingly?
> Incorrect last revision of cached node state
>
>
> Key: OAK-3653
> URL: https://issues.apache.org/jira/browse/OAK-3653
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Reporter: Vikas Saurabh
> Attachments: Capture.JPG, Capture1.JPG, Capture2.JPG, oplog.json
>
>
> While installing a package in one of the systems (Oak-1.0.16), we observed
> broken workflow model. Upon further investigation, it was found that
> {{baseVersion}} of the model was pointing to a node in version storage which
> wasn't visible on the instance. This node was available in mongo and could
> also be seen on a different instance of the cluster.
> The node was created on the same instance where it wasn't visible (cluster id
> - 3)
> Further investigation showed that for some (yet unknown) reason,
> {{lastRevision}} for cached node state of node's parent at revision where the
> node was created was stale (an older revision) which must have led to invalid
> children list and hence unavailable node.
> Attaching a few files which were captured during the investigation:
> * [^oplog.json] - oplog for +-10s for r151191c7601-0-3
> * [^Capture.JPG]- snapshot of groovy console output using script at \[0] to
> list node children cache entry for parent
> * [^Capture1.JPG]- snapshot of groovy console output using script at \[1] to
> traverse to invisible node
> * [^Capture2.JPG]- Almost same as Capture.jpg but this time for node cache
> instead (using script at \[2])
> The node which wasn't visible in mongo:
> {noformat}
> db.nodes.findOne({_id:
> "7:/jcr:system/jcr:versionStorage/d9/9f/22/d99f2279-dcc9-40a0-9aa4-c91fe310287e/1.7"})
> {
> "_id" :
> "7:/jcr:system/jcr:versionStorage/d9/9f/22/d99f2279-dcc9-40a0-9aa4-c91fe310287e/1.7",
> "_deleted" : {
> "r151191c7601-0-3" : "false"
> },
> "_commitRoot" : {
> "r151191c7601-0-3" : "0"
> },
> "_lastRev" : {
> "r0-0-3" : "r151191c7601-0-3"
> },
> "jcr:primaryType" : {
> "r151191c7601-0-3" : "\"nam:nt:version\""
> },
> "jcr:uuid" : {
> "r151191c7601-0-3" :
> "\"40234f1d-2435-4c6b-9962-20af22b1c948\""
> },
> "_modified" : NumberLong(1447825270),
> "jcr:created" : {
> "r151191c7601-0-3" : "\"dat:2015-11-17T21:41:14.058-08:00\""
> },
> "_children" : true,
> "jcr:predecessors" : {
> "r151191c7601-0-3" :
> "[\"ref:6cecc77b-3020-4a47-b9cc-084a618aa957\"]"
> },
> "jcr:successors" : {
> "r151191c7601-0-3" : "\"[0]:Reference\""
> },
> "_modCount" : NumberLong(1)
> }
> {noformat}
> Last revision entry of cached node state of
> {{/jcr:system/jcr:versionStorage/d9/9f/22/d99f2279-dcc9-40a0-9aa4-c91fe310287e}}
> (parent) at revision {{r151191c7601-0-3}} was {{r14f035ebdf8-0-3}} (the last
> revs were propagated correctly up till root for r151191c7601-0-3).
> As a work-around, doing {{cache.invalidate(k)}} for node cache (inside the
> loop of script at \[2]) revived the visibility of the node.
> *Disclaimer*: _The issue was reported and investigated on a cluster backed by
> mongo running on Oak-1.0.16. But, the problem itself doesn't seem like any
> which have been fixed in later versions_
> \[0]: {noformat}
> def printNodeChildrenCache(def path) {
> def session =
> osgi.getService(org.apache.sling.jcr.api.SlingRepository.class).loginAdministrative(null)
> try {
> def rootNode = session.getRootNode()
> def cache = rootNode.sessionDelegate.root.store.nodeChildrenCache
> def cacheMap = cache.asMap()
> cacheMap.each{k,v ->
> if (k.toString().startsWith(path + "@")) {
> println "${k}:${v}"
> }
> }
> } finally {
> session.logout()
> }
> }
>
> printNodeChildrenCache("/jcr:system/jcr:versionStorage/d9/9f/22/d99f2279-dcc9-40a0-9aa4-c91fe310287e")
> {noformat}
> \[1]: {noformat}
> def traverse(def path) {
> def session =
> osgi.getService(org.apache.sling.jcr.api.SlingRepository.class).loginAdministrative(null)
> try {
> def rootNode = session.getRootNode()
> def nb = rootNode.sessionDelegate.root.store.root
> def p = ''
> path.tokenize('/').each() {
> p = p + '/' + it
> nb = nb.getChildNode(it)
> println "${p} ${nb}"
> }
> } finally {
> session.logout()
> }
> }
> traverse("/jcr:system/jcr:versionStorage/d9/9f/22/d99f2279-dcc9-40a0-9aa4-c91fe310287e/1.7")
> {noformat}
> \[2]:
[jira] [Updated] (OAK-3653) Incorrect last revision of cached node state
[
https://issues.apache.org/jira/browse/OAK-3653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-3653:
---
Description:
While installing a package in one of the systems (Oak-1.0.16), we observed
broken workflow model. Upon further investigation, it was found that
{{baseVersion}} of the model was pointing to a node in version storage which
wasn't visible on the instance. This node was available in mongo and could also
be seen on a different instance of the cluster.
The node was created on the same instance where it wasn't visible (cluster id -
3)
Further investigation showed that for some (yet unknown) reason,
{{lastRevision}} for cached node state of node's parent at revision where the
node was created was stale (an older revision) which must have led to invalid
children list and hence unavailable node.
Attaching a few files which were captured during the investigation:
* [^oplog.json] - oplog for +-10s for r151191c7601-0-3
* [^Capture.JPG]- snapshot of groovy console output using script at \[0] to
list node children cache entry for parent
* [^Capture1.JPG]- snapshot of groovy console output using script at \[1] to
traverse to invisible node
* [^Capture2.JPG]- Almost same as Capture.jpg but this time for node cache
instead (using script at \[2])
The node which wasn't visible in mongo:
{noformat}
db.nodes.findOne({_id:
"7:/jcr:system/jcr:versionStorage/d9/9f/22/d99f2279-dcc9-40a0-9aa4-c91fe310287e/1.7"})
{
"_id" :
"7:/jcr:system/jcr:versionStorage/d9/9f/22/d99f2279-dcc9-40a0-9aa4-c91fe310287e/1.7",
"_deleted" : {
"r151191c7601-0-3" : "false"
},
"_commitRoot" : {
"r151191c7601-0-3" : "0"
},
"_lastRev" : {
"r0-0-3" : "r151191c7601-0-3"
},
"jcr:primaryType" : {
"r151191c7601-0-3" : "\"nam:nt:version\""
},
"jcr:uuid" : {
"r151191c7601-0-3" : "\"40234f1d-2435-4c6b-9962-20af22b1c948\""
},
"_modified" : NumberLong(1447825270),
"jcr:created" : {
"r151191c7601-0-3" : "\"dat:2015-11-17T21:41:14.058-08:00\""
},
"_children" : true,
"jcr:predecessors" : {
"r151191c7601-0-3" :
"[\"ref:6cecc77b-3020-4a47-b9cc-084a618aa957\"]"
},
"jcr:successors" : {
"r151191c7601-0-3" : "\"[0]:Reference\""
},
"_modCount" : NumberLong(1)
}
{noformat}
Last revision entry of cached node state of
{{/jcr:system/jcr:versionStorage/d9/9f/22/d99f2279-dcc9-40a0-9aa4-c91fe310287e}}
(parent) at revision {{r151191c7601-0-3}} was {{r14f035ebdf8-0-3}} (the last
revs were propagated correctly up till root for r151191c7601-0-3).
As a work-around, doing {{cache.invalidate(k)}} for node cache (inside the loop
of script at \[2]) revived the visibility of the node.
*Disclaimer*: _The issue was reported and investigated on a cluster backed by
mongo running on Oak-1.0.16. But, the problem itself doesn't seem like any
which have been fixed in later versions_
\[0]: {noformat}
def printNodeChildrenCache(def path) {
def session =
osgi.getService(org.apache.sling.jcr.api.SlingRepository.class).loginAdministrative(null)
try {
def rootNode = session.getRootNode()
def cache = rootNode.sessionDelegate.root.store.nodeChildrenCache
def cacheMap = cache.asMap()
cacheMap.each{k,v ->
if (k.toString().startsWith(path + "@")) {
println "${k}:${v}"
}
}
} finally {
session.logout()
}
}
printNodeChildrenCache("/jcr:system/jcr:versionStorage/d9/9f/22/d99f2279-dcc9-40a0-9aa4-c91fe310287e")
{noformat}
\[1]: {noformat}
def traverse(def path) {
def session =
osgi.getService(org.apache.sling.jcr.api.SlingRepository.class).loginAdministrative(null)
try {
def rootNode = session.getRootNode()
def nb = rootNode.sessionDelegate.root.store.root
def p = ''
path.tokenize('/').each() {
p = p + '/' + it
nb = nb.getChildNode(it)
println "${p} ${nb}"
}
} finally {
session.logout()
}
}
traverse("/jcr:system/jcr:versionStorage/d9/9f/22/d99f2279-dcc9-40a0-9aa4-c91fe310287e/1.7")
{noformat}
\[2]: {noformat}
def printNodeChildrenCache(def path) {
def session =
osgi.getService(org.apache.sling.jcr.api.SlingRepository.class).loginAdministrative(null)
try {
def rootNode = session.getRootNode()
def cache = rootNode.sessionDelegate.root.store.nodeCache
def cacheMap = cache.asMap()
cacheMap.each{k,v ->
if (k.toString().startsWith(path + "@")) {
println "${k}:${v}"
println "lastRev -> ${v.lastRevision}"
}
}
} finally {
session.logout()
}
}
printNodeChildrenCache("/jcr:system/jcr:versionStorage/d9/9f/22/d99f2279-dcc9-40a0-9aa4-c91fe310287e")
{noformat}
was:
While installing a package in one of the systems (Oak-1.0.16), we observed
broken
[jira] [Updated] (OAK-3653) Incorrect last revision of cached node state
[
https://issues.apache.org/jira/browse/OAK-3653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vikas Saurabh updated OAK-3653:
---
Attachment: oplog.json
Capture2.JPG
Capture1.JPG
Capture.JPG
> Incorrect last revision of cached node state
>
>
> Key: OAK-3653
> URL: https://issues.apache.org/jira/browse/OAK-3653
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: documentmk
>Reporter: Vikas Saurabh
> Attachments: Capture.JPG, Capture1.JPG, Capture2.JPG, oplog.json
>
>
> While installing a package in one of the systems (Oak-1.0.16), we observed
> broken workflow model. Upon further investigation, it was found that
> {{baseVersion}} of the model was pointing to a node in version storage which
> wasn't visible on the instance. This node was available in mongo and could
> also be seen on a different instance of the cluster.
> The node was created on the same instance where it wasn't visible (cluster id
> - 3)
> Further investigation showed that for some (yet unknown) reason,
> {{lastRevision}} for cached node state of node's parent at revision where the
> node was created was stale (an older revision) which must have led to invalid
> children list and hence unavailable node.
> Attaching a few files which were captured during the investigation:
> * oplog.json - oplog for +-10s for r151191c7601-0-3
> * Capture.jpg - snapshot of groovy console output using script at \[0] to
> list node children cache entry for parent
> * Capture1.jpg - snapshot of groovy console output using script at \[1] to
> traverse to invisible node
> * Capture2.jpg - Almost same as Capture.jpg but this time for node cache
> instead (using script at \[2])
> The node which wasn't visible in mongo:
> {noformat}
> db.nodes.findOne({_id:
> "7:/jcr:system/jcr:versionStorage/d9/9f/22/d99f2279-dcc9-40a0-9aa4-c91fe310287e/1.7"})
> {
> "_id" :
> "7:/jcr:system/jcr:versionStorage/d9/9f/22/d99f2279-dcc9-40a0-9aa4-c91fe310287e/1.7",
> "_deleted" : {
> "r151191c7601-0-3" : "false"
> },
> "_commitRoot" : {
> "r151191c7601-0-3" : "0"
> },
> "_lastRev" : {
> "r0-0-3" : "r151191c7601-0-3"
> },
> "jcr:primaryType" : {
> "r151191c7601-0-3" : "\"nam:nt:version\""
> },
> "jcr:uuid" : {
> "r151191c7601-0-3" :
> "\"40234f1d-2435-4c6b-9962-20af22b1c948\""
> },
> "_modified" : NumberLong(1447825270),
> "jcr:created" : {
> "r151191c7601-0-3" : "\"dat:2015-11-17T21:41:14.058-08:00\""
> },
> "_children" : true,
> "jcr:predecessors" : {
> "r151191c7601-0-3" :
> "[\"ref:6cecc77b-3020-4a47-b9cc-084a618aa957\"]"
> },
> "jcr:successors" : {
> "r151191c7601-0-3" : "\"[0]:Reference\""
> },
> "_modCount" : NumberLong(1)
> }
> {noformat}
> Last revision entry of cached node state of
> {{/jcr:system/jcr:versionStorage/d9/9f/22/d99f2279-dcc9-40a0-9aa4-c91fe310287e}}
> (parent) at revision {{r151191c7601-0-3}} was {{r14f035ebdf8-0-3}} (the last
> revs were propagated correctly up till root for r151191c7601-0-3).
> As a work-around, doing {{cache.invalidate(k)}} for node cache (inside the
> loop of script at \[2]) revived the visibility of the node.
> *Disclaimer*: _The issue was reported and investigated on a cluster backed by
> mongo running on Oak-1.0.16. But, the problem itself doesn't seem like any
> which have been fixed in later versions_
> \[0]: {noformat}
> def printNodeChildrenCache(def path) {
> def session =
> osgi.getService(org.apache.sling.jcr.api.SlingRepository.class).loginAdministrative(null)
> try {
> def rootNode = session.getRootNode()
> def cache = rootNode.sessionDelegate.root.store.nodeChildrenCache
> def cacheMap = cache.asMap()
> cacheMap.each{k,v ->
> if (k.toString().startsWith(path + "@")) {
> println "${k}:${v}"
> }
> }
> } finally {
> session.logout()
> }
> }
>
> printNodeChildrenCache("/jcr:system/jcr:versionStorage/d9/9f/22/d99f2279-dcc9-40a0-9aa4-c91fe310287e")
> {noformat}
> \[1]: {noformat}
> def traverse(def path) {
> def session =
> osgi.getService(org.apache.sling.jcr.api.SlingRepository.class).loginAdministrative(null)
> try {
> def rootNode = session.getRootNode()
> def nb = rootNode.sessionDelegate.root.store.root
> def p = ''
> path.tokenize('/').each() {
> p = p + '/' + it
> nb = nb.getChildNode(it)
> println "${p} ${nb}"
> }
> } finally {
> session.logout()
> }
> }
> traverse("/jcr:system/jcr:versionStorage/d9/9f/22/d99f2279-dcc9-40a0-9aa4-c91fe310287e/1.7")
> {noformat}
> \[2]:
[jira] [Commented] (OAK-3632) Incorrect Value Conversion upon Node.setProperty and Node.setValue
[
https://issues.apache.org/jira/browse/OAK-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15010533#comment-15010533
]
Michael Dürig commented on OAK-3632:
I like the approach of the patch in general. However I'd like to move the
{{Conversions#checkSupportedConversion()}} somewhere else, optimally somewhere
in {{oak-jcr}}.
> Incorrect Value Conversion upon Node.setProperty and Node.setValue
> --
>
> Key: OAK-3632
> URL: https://issues.apache.org/jira/browse/OAK-3632
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: jcr
>Reporter: angela
> Attachments: OAK-3632.patch
>
>
> see container issue for test-cases and description
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3477) Make JMX Bean names predictable so they can be used in configurations.
[
https://issues.apache.org/jira/browse/OAK-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15010659#comment-15010659
]
Chetan Mehrotra commented on OAK-3477:
--
bq. Do we know what the consequences are when we happen to run into a name
conflict?
Checked that. The default whiteboard in Oak class eats any JMXException. For
OSGi case this is asynchronous so would not affect. I would change the default
to at least log a warning message
bq. Alternatively we could try to detect a name conflict and re-register in
such a case with disambiguation. Not sure it its worth the extra trouble
though.
Yup. Lets do this later if it becomes a real problem
> Make JMX Bean names predictable so they can be used in configurations.
> --
>
> Key: OAK-3477
> URL: https://issues.apache.org/jira/browse/OAK-3477
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.3.7
>Reporter: Ian Boston
>Assignee: Chetan Mehrotra
> Labels: candidate_oak_1_0, candidate_oak_1_2
> Fix For: 1.3.11
>
> Attachments: OAK-3477.patch
>
>
> In Oak there are JMX beans which get names of the form [1], which can be hard
> to use in monitoring tool configuration that dont support regexes as the ID
> will change. Where possible, the ID should be removed or made static. The
> name and type should be sufficient in most cases in Oak to make the JMX
> Object name unique.
> 1
> {code}
> org.apache.jackrabbit.oak:name="Consolidated Cache
> statistics",type="ConsolidatedCacheStats",id=6
> org.apache.jackrabbit.oak:name="CopyOnRead support
> statistics",type="CopyOnReadStats",id=7
> org.apache.jackrabbit.oak:name="Oak Repository
> Statistics",type="RepositoryStats",id=16
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3650) Index based excerpt should be used for binaries
[ https://issues.apache.org/jira/browse/OAK-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated OAK-3650: - Description: Index provided excerpt should be used for binaries, that is the case when for example an index excerpt exists yet the row value to be retrieved is property specific and thus the fallback provider kicks in, however that won't work for binary properties and therefore the excerpt provided by the index should be used. > Index based excerpt should be used for binaries > --- > > Key: OAK-3650 > URL: https://issues.apache.org/jira/browse/OAK-3650 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene, query >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Fix For: 1.3.11, 1.2.9, 1.0.25 > > > Index provided excerpt should be used for binaries, that is the case when for > example an index excerpt exists yet the row value to be retrieved is property > specific and thus the fallback provider kicks in, however that won't work for > binary properties and therefore the excerpt provided by the index should be > used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3612) The string/template cache of the SegmentWriter should be cleared before cleanup
[
https://issues.apache.org/jira/browse/OAK-3612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15010863#comment-15010863
]
Francesco Mari commented on OAK-3612:
-
The deadlock is more complicated than expected. It boils down to a call to
{{SegmentWriter#flush}} performed while holding the implicit lock for the
{{SegmentWriter}}. This deadlock is not easy to solve without going through a
refactoring of the {{SegmentWriter}}, which should be the scope of OAK-1828.
I run my tests using the less invasive solution proposed by [~alex.parvulescu],
obtaining good results. The standby node is now able to delete the
pre-compacted state when the cleanup operation is triggered through the JMX
bean.
{noformat}
18.11.2015 12:59:26.520 *INFO* [RMI TCP Connection(16)-10.132.4.207]
org.apache.jackrabbit.oak.plugins.segment.file.FileStore TarMK GC #0: cleanup
started. Current repository size is 1.2 GB (1249641472 bytes)
18.11.2015 12:59:26.773 *INFO* [RMI TCP Connection(16)-10.132.4.207]
org.apache.jackrabbit.oak.plugins.segment.file.TarReader-GC Cleaned segments
from data5a.tar:
e724aad7-dbf4-441b-a451-b92f0516c156,
35e3c300-00ea-4477-a005-e37db181c664, fd130fc5-0b2c-432b-a9b8-6b6167ff8312,
9ed0e54d-e3ab-4ef3-ad15-136781fb4b6b,
c4e93c7f-754d-4f6d-a9ff-51e5bac7acec,
0512412d-ea96-4eea-ac9d-8e401ea35914, c523dcd2-1e31-495e-a15f-0ceaee0e66ec,
4c54a6f4-3c12-41a2-ac25-9d45dff38fa8,
edc6a4cf-c358-4fef-a043-90857135e760,
beeafeda-3486-4931-a58e-c57e41e5c51c, 7e63ecc3-2ab5-407e-a86b-896ca1f7e895,
1dd480ee-efe0-4757-afec-1e290af3f8c9,
5e245021-67be-4266-af9c-347d5032e79c,
ef99a42b-3c37-4ac3-ae50-0de8aa441d29, efbdd640-4c04-4ef7-a21b-4fc3db8ee96b,
0decb0ae-88bf-4897-a102-15f97e015084,
59ad4f38-3f70-44fc-a013-f259ebf1ca36,
ab78d2db-426f-42dc-a03f-9f23e24b4c32, 6e4b1472-5af2-4a1e-a2d3-47a19c1bd109,
58f50b51-458e-4931-aca5-3a78f849a0b9,
68212eb1-c960-421c-a7cf-3e91ba9114f5,
c52df7b9-93cc-421b-aa83-d70523ca3476
18.11.2015 12:59:26.783 *INFO* [RMI TCP Connection(16)-10.132.4.207]
org.apache.jackrabbit.oak.plugins.segment.file.FileStore TarMK GC #0: cleanup
marking file for deletion: data5a.tar
18.11.2015 12:59:26.783 *INFO* [RMI TCP Connection(16)-10.132.4.207]
org.apache.jackrabbit.oak.plugins.segment.file.FileStore TarMK GC #0: cleanup
completed in 263.8 ms (263 ms). Post cleanup size is 1.2 GB (1249584128 bytes)
and space reclaimed 57.3 kB (57344 bytes). Compaction map weight/depth is 0 B/0
(0 bytes/0).
{noformat}
I will perform some more tests, but the fix seems to be effective so far.
> The string/template cache of the SegmentWriter should be cleared before
> cleanup
> ---
>
> Key: OAK-3612
> URL: https://issues.apache.org/jira/browse/OAK-3612
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: segmentmk
>Reporter: Francesco Mari
> Fix For: 1.4
>
> Attachments: OAK-3612-01.patch
>
>
> The string/template cache of the SegmentWriter
> (org.apache.jackrabbit.oak.plugins.segment.SegmentWriter#records) is not
> cleared before the cleanup phase. This might maintain in-memory references to
> segments, thus preventing them to be cleaned up.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-3650) Index based excerpt should be used for binaries
Tommaso Teofili created OAK-3650: Summary: Index based excerpt should be used for binaries Key: OAK-3650 URL: https://issues.apache.org/jira/browse/OAK-3650 Project: Jackrabbit Oak Issue Type: Improvement Components: lucene, query Reporter: Tommaso Teofili Fix For: 1.3.11, 1.2.9, 1.0.25 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3634) RDB/MongoDocumentStore may return stale documents
[
https://issues.apache.org/jira/browse/OAK-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15010759#comment-15010759
]
Marcel Reutegger commented on OAK-3634:
---
I agree with you. Change the test and require update() to correctly reflect
changes in the cache that happened before.
> RDB/MongoDocumentStore may return stale documents
> -
>
> Key: OAK-3634
> URL: https://issues.apache.org/jira/browse/OAK-3634
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mongomk, rdbmk
>Affects Versions: 1.3.10
>Reporter: Julian Reschke
> Attachments: OAK-3634.diff
>
>
> It appears that the implementations of the {{update}} method sometimes
> populate the memory cache with documents that do not reflect any current or
> previous state in the persistence (that is, miss changes made by another
> node).
> (will attach test)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2187) Document cache invalidation logic generating lots of garbage
[
https://issues.apache.org/jira/browse/OAK-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15010768#comment-15010768
]
Chetan Mehrotra commented on OAK-2187:
--
+1 for that. Opened OAK-3651 to remove the hierarchical invalidation logic
> Document cache invalidation logic generating lots of garbage
>
>
> Key: OAK-2187
> URL: https://issues.apache.org/jira/browse/OAK-2187
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core
>Affects Versions: 1.0.7
> Environment: CQ6SP1+HF5176(Oak 1.0.7), 3 authors, 2 mongo in replica
> set with another arbiter.
>Reporter: Vikas Saurabh
>Assignee: Chetan Mehrotra
>
> We are observing around 2GB of temporary objects getting created every 20-30
> seconds
> Following is the result from
> {{/system/console/jmx/org.apache.jackrabbit.oak%3Aid%3D8%2Cname%3D"Consolidated+Cache+statistics"%2Ctype%3D"ConsolidatedCacheStats"}}:
> ||averageLoadPenalty||elementCount||evictionCount||hitCount||hitRate||loadCount||loadExceptionCount||loadSuccessCount||maxWeight||missCount||missRate||name||requestCount||totalLoadTime||totalWeight||
> |2ms|136054|14855|8293718384|0.96|222767|0|222767|612.0
> MB|372951359|0.043|Document-Documents|869743|8 min, 0 sec|611.2 MB|
> |0ms|95600|262264|146336|0.19|0|0|0|53.7
> MB|609878|0.81|Document-Diff|756214|0 min, 0 sec|53.7 MB|
> |0ms|1|0|31212|0.17|0|0|0|32.2 MB|156684|0.83|Document-DocChildren|187896|0
> min, 0 sec|4.8 kB|
> |3ms|78781|110556|25953581|0.98|181461|0|181461|107.4
> MB|508826|0.019|Document-NodeChildren|26462407|11 min, 29 sec|107.2 MB|
> |0ms|201619|2542876|440737116|0.99|2744495|0|2744495|268.4
> MB|2866721|0.0065|Document-NodeState|443603837|8 min, 36 sec|268.4 MB|
> Following is the thread-dump:
> {code}
> 2014-10-14 12:57:20
> Full thread dump OpenJDK 64-Bit Server VM (24.65-b04 mixed mode):
> "Thread-8668" - Thread t@18303
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown
> Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "Thread-8667" - Thread t@18302
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown
> Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "Thread-8666" - Thread t@18301
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown
> Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "Thread-8665" - Thread t@18300
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown
> Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "Thread-8664" - Thread t@18299
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown
> Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "Thread-8663" - Thread t@18298
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at
[jira] [Created] (OAK-3651) Remove HierrachialCacheInvalidator
Chetan Mehrotra created OAK-3651: Summary: Remove HierrachialCacheInvalidator Key: OAK-3651 URL: https://issues.apache.org/jira/browse/OAK-3651 Project: Jackrabbit Oak Issue Type: Task Components: mongomk Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Priority: Minor Fix For: 1.3.11 As discussed in OAK-2187 and due to changes done in OAK-3002 HierrachialCacheInvalidator is now redundant and should be removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3650) Index based excerpt should be used for binaries
[ https://issues.apache.org/jira/browse/OAK-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili resolved OAK-3650. -- Resolution: Fixed fixed in r1714961, 1714966, 1714971 > Index based excerpt should be used for binaries > --- > > Key: OAK-3650 > URL: https://issues.apache.org/jira/browse/OAK-3650 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene, query >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Fix For: 1.3.11, 1.2.9, 1.0.25 > > > Index provided excerpt should be used for binaries, that is the case when for > example an index excerpt exists yet the row value to be retrieved is property > specific and thus the fallback provider kicks in, however that won't work for > binary properties and therefore the excerpt provided by the index should be > used. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3648) Use StandardTokenizer instead of ClassicTokenizer in OakAnalyzer
[
https://issues.apache.org/jira/browse/OAK-3648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15010786#comment-15010786
]
Tommaso Teofili commented on OAK-3648:
--
thanks [~catholicon], it looks good to me.
> Use StandardTokenizer instead of ClassicTokenizer in OakAnalyzer
>
>
> Key: OAK-3648
> URL: https://issues.apache.org/jira/browse/OAK-3648
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: lucene
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
> Fix For: 1.3.11
>
>
> This is related to OAK-3276 where the intent was to use {{StandardAnalyzer}}
> by default (instead of {{OakAnalyzer}}). As discussed there, we need specific
> word delimiter which isn't possible with StandardAnalyzer, so we instead
> should switch over to StandardTokenizer in OakAnalyer itself.
> A few motivations to do that:
> * Better unicode support
> * ClassicTokenizer is the old (~lucene 3.1) implementation of standard
> tokenizer
> One of the key difference between classic and standard tokenizer is the way
> they delimit words (standard analyzer follows unicode text segmentation
> rules)... but that difference gets nullified as we have our own
> WordDelimiterFilter.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2689) Test failure: QueryResultTest.testGetSize
[
https://issues.apache.org/jira/browse/OAK-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15010893#comment-15010893
]
Marcel Reutegger commented on OAK-2689:
---
Unfortunately it is not that easy to merge Thomas change. It depends on the
rather large change done in OAK-2977.
I will just merge the ignore entry by Michael.
> Test failure: QueryResultTest.testGetSize
> -
>
> Key: OAK-2689
> URL: https://issues.apache.org/jira/browse/OAK-2689
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
> Environment: Jenkins, Ubuntu:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
>Reporter: Michael Dürig
>Assignee: Thomas Mueller
> Labels: CI, Jenkins
> Fix For: 1.3.9
>
>
> {{org.apache.jackrabbit.core.query.QueryResultTest.testGetSize}} fails every
> couple of builds:
> {noformat}
> junit.framework.AssertionFailedError: Wrong size of NodeIterator in result
> expected:<48> but was:<-1>
> at junit.framework.Assert.fail(Assert.java:50)
> at junit.framework.Assert.failNotEquals(Assert.java:287)
> at junit.framework.Assert.assertEquals(Assert.java:67)
> at junit.framework.Assert.assertEquals(Assert.java:134)
> at
> org.apache.jackrabbit.core.query.QueryResultTest.testGetSize(QueryResultTest.java:47)
> {noformat}
> Failure seen at builds: 29, 39, 59, 61, 114, 117, 118, 120, 139, 142
> See e.g.
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/59/jdk=jdk-1.6u45,label=Ubuntu,nsfixtures=DOCUMENT_NS,profile=unittesting/testReport/junit/org.apache.jackrabbit.core.query/QueryResultTest/testGetSize/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3478) Provide JMX Beans for Oak that can be monitored by external tooling.
[ https://issues.apache.org/jira/browse/OAK-3478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15010908#comment-15010908 ] Ian Boston commented on OAK-3478: - @Chetan Mehrotra The bean "Oak Repository Statistics-simple" produces the right type of stats, but I think the the "per second" approach wont work as the sequence of numbers from the existing TimeSeries follows the pattern 0,0,0,0,0,0,0,76100,0,0,0,0,0,0,0 etc. If the monitoring tool happens to query either side of the 71600 value, then it get 0. To get 76100 it has to query at exactly the correct time. You could use the per minute value but it would be better not to re-invent the research in this area and look at what others have already proven to work in production. Most Metrics gathering systems use some form of moving average eg http://en.wikipedia.org/wiki/Moving_average#Exponential_moving_average or a pure counter to let the monitoring tool do the work. Pure counters are not very good as they tend to hit overflow problems, Moving averages of some form are better, provided the Windows or reservoirs can be implemented efficiently. Since averages are not always that useful when identifying performance most metrics tools also provide live histogram of the metric to produce 50%, 99.99%. 99.99% becomes important if the operation is performed thousands of times where each operation correlates with others, as a slow operation 0.001 % of the time will impact all operations with absolute certainty. Oak has plenty of places where this is a characteristic, starting with queues. To produce those sort of stats you may need to implement http://www.cs.umd.edu/~samir/498/vitter.pdf. The link was taken from Codehale Metrics which has various implementations testing in production. If Oak is not prepared to use a third party library for metrics support it should learn from what others have used successfully in production. > Provide JMX Beans for Oak that can be monitored by external tooling. > > > Key: OAK-3478 > URL: https://issues.apache.org/jira/browse/OAK-3478 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, jcr, lucene, query >Affects Versions: 1.3.7 >Reporter: Ian Boston >Assignee: Chetan Mehrotra > Fix For: 1.3.11 > > Attachments: OAK-3478-v1.patch > > > The Current JMX beans, while ok in the Sling Web Console are hard if not > impossible to monitor with external tooling, as external tooling will poll > for current values, ideally from named attributes containing primitive types. > Those values containing timers, counters or gauges. Timers timing an > operation. Counters counting an operation. Guages measuring an instantaneous > value. > The request is to provide a small number of JMX beans that can be configured > into an external monitoring tool like AppDynamics, Ganglia, NewRelic, Splunk > etc etc, which in turn will provide long term time series and statistics. > Primitive values of this form can also be graphed with ease in JConsole, > VisualVM etc. A improvement for the Sling Web Console might be to add a > Console that can maintain a TimeSeries graph of any JMX bean by object name > in the same way Ganglia, AppDynamics does, however that may be duplicating > existing functionality. > The Metrics Library could be considered to provide the above functionality > for all JMX beans and monitoring, although its footprint at 111K might be > considered too big as an additional dependency. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2187) Document cache invalidation logic generating lots of garbage
[
https://issues.apache.org/jira/browse/OAK-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15010762#comment-15010762
]
Marcel Reutegger commented on OAK-2187:
---
bq. So removing the old variant requires a different handling of that
IOException case first.
How about replacing the hierarchical invalidation in that case with a simple
invalidate all? We could then remove the unused hierarchical invalidation logic.
> Document cache invalidation logic generating lots of garbage
>
>
> Key: OAK-2187
> URL: https://issues.apache.org/jira/browse/OAK-2187
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core
>Affects Versions: 1.0.7
> Environment: CQ6SP1+HF5176(Oak 1.0.7), 3 authors, 2 mongo in replica
> set with another arbiter.
>Reporter: Vikas Saurabh
>Assignee: Chetan Mehrotra
>
> We are observing around 2GB of temporary objects getting created every 20-30
> seconds
> Following is the result from
> {{/system/console/jmx/org.apache.jackrabbit.oak%3Aid%3D8%2Cname%3D"Consolidated+Cache+statistics"%2Ctype%3D"ConsolidatedCacheStats"}}:
> ||averageLoadPenalty||elementCount||evictionCount||hitCount||hitRate||loadCount||loadExceptionCount||loadSuccessCount||maxWeight||missCount||missRate||name||requestCount||totalLoadTime||totalWeight||
> |2ms|136054|14855|8293718384|0.96|222767|0|222767|612.0
> MB|372951359|0.043|Document-Documents|869743|8 min, 0 sec|611.2 MB|
> |0ms|95600|262264|146336|0.19|0|0|0|53.7
> MB|609878|0.81|Document-Diff|756214|0 min, 0 sec|53.7 MB|
> |0ms|1|0|31212|0.17|0|0|0|32.2 MB|156684|0.83|Document-DocChildren|187896|0
> min, 0 sec|4.8 kB|
> |3ms|78781|110556|25953581|0.98|181461|0|181461|107.4
> MB|508826|0.019|Document-NodeChildren|26462407|11 min, 29 sec|107.2 MB|
> |0ms|201619|2542876|440737116|0.99|2744495|0|2744495|268.4
> MB|2866721|0.0065|Document-NodeState|443603837|8 min, 36 sec|268.4 MB|
> Following is the thread-dump:
> {code}
> 2014-10-14 12:57:20
> Full thread dump OpenJDK 64-Bit Server VM (24.65-b04 mixed mode):
> "Thread-8668" - Thread t@18303
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown
> Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "Thread-8667" - Thread t@18302
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown
> Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "Thread-8666" - Thread t@18301
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown
> Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "Thread-8665" - Thread t@18300
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown
> Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "Thread-8664" - Thread t@18299
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown
> Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "Thread-8663" - Thread t@18298
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
>
[jira] [Commented] (OAK-2948) Expose DefaultSyncHandler
[
https://issues.apache.org/jira/browse/OAK-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15010913#comment-15010913
]
Nicolas Peltier commented on OAK-2948:
--
[~tripod] (cc [~kwin]), there is still something wrong i'd say, or i don't see
a solution for which the defaultsyncconfig handling:
DefaultSyncConfig parameters are all set in implementation of it, and only way
to get DefaultSyncConfig is through the implementation that is not exported,
with the .of(..) method.
Creating my own SyncHandler thus needs to copy the full DefaultSyncConfigImpl
configuration...
i guess what we could have here is a public activate method (so i can call
super.activate(..))?
> Expose DefaultSyncHandler
> -
>
> Key: OAK-2948
> URL: https://issues.apache.org/jira/browse/OAK-2948
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: auth-external
>Reporter: Konrad Windszus
> Fix For: 1.3.2, 1.2.7, 1.0.22
>
>
> We do have the use case of extending the user sync. Unfortunately
> {{DefaultSyncHandler}} is not exposed, so if you want to change one single
> aspect of the user synchronisation you have to copy over the code from the
> {{DefaultSyncHandler}}. Would it be possible to make that class part of the
> exposed classes, so that deriving your own class from that DefaultSyncHandler
> is possible?
> Very often company LDAPs are not very standardized. In our case we face an
> issue, that the membership is being listed in a user attribute, rather than
> in a group attribute.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3632) Incorrect Value Conversion upon Node.setProperty and Node.setValue
[
https://issues.apache.org/jira/browse/OAK-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15010741#comment-15010741
]
angela commented on OAK-3632:
-
sure. it doesn't need to be on {{Conversions}}. Since is actually copied from
the specification (hopefully without any mistake), we could also add it on
jackrabbit-jcr commons. then it's accessible to everyone. e.g. {{ValueHelper}}.
since the latter already perform the conversion in a JCR compliant way, we
could also consider delegating the value conversion to this helper class when
setting values in {{NodeDelegatee}}; however i fear that this would require
much bigger changes than introducing the extra check.
> Incorrect Value Conversion upon Node.setProperty and Node.setValue
> --
>
> Key: OAK-3632
> URL: https://issues.apache.org/jira/browse/OAK-3632
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: jcr
>Reporter: angela
> Attachments: OAK-3632.patch
>
>
> see container issue for test-cases and description
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3632) Incorrect Value Conversion upon Node.setProperty and Node.setValue
[ https://issues.apache.org/jira/browse/OAK-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15010730#comment-15010730 ] angela commented on OAK-3632: - ack. > Incorrect Value Conversion upon Node.setProperty and Node.setValue > -- > > Key: OAK-3632 > URL: https://issues.apache.org/jira/browse/OAK-3632 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: jcr >Reporter: angela > Attachments: OAK-3632.patch > > > see container issue for test-cases and description -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3477) Make JMX Bean names predictable so they can be used in configurations.
[
https://issues.apache.org/jira/browse/OAK-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved OAK-3477.
--
Resolution: Fixed
Applied a modified patch with 1714964
* {{type}} and {{name}} would now only be quoted if required - Makes referring
to MBean name simpler
* {{id}} is dropped
If a duplicate MBean is registered that default Whiteboard would log warning.
On OSGi based setup the MBean is registered in a separate flow via whiteboard
pattern so any exception would not affect the caller
> Make JMX Bean names predictable so they can be used in configurations.
> --
>
> Key: OAK-3477
> URL: https://issues.apache.org/jira/browse/OAK-3477
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.3.7
>Reporter: Ian Boston
>Assignee: Chetan Mehrotra
> Labels: candidate_oak_1_0, candidate_oak_1_2
> Fix For: 1.3.11
>
> Attachments: OAK-3477.patch
>
>
> In Oak there are JMX beans which get names of the form [1], which can be hard
> to use in monitoring tool configuration that dont support regexes as the ID
> will change. Where possible, the ID should be removed or made static. The
> name and type should be sufficient in most cases in Oak to make the JMX
> Object name unique.
> 1
> {code}
> org.apache.jackrabbit.oak:name="Consolidated Cache
> statistics",type="ConsolidatedCacheStats",id=6
> org.apache.jackrabbit.oak:name="CopyOnRead support
> statistics",type="CopyOnReadStats",id=7
> org.apache.jackrabbit.oak:name="Oak Repository
> Statistics",type="RepositoryStats",id=16
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3478) Provide JMX Beans for Oak that can be monitored by external tooling.
[ https://issues.apache.org/jira/browse/OAK-3478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15010755#comment-15010755 ] Ian Boston commented on OAK-3478: - @Michael Dürig SLING-4849 might do what you need if you want to decouple monitoring. > Provide JMX Beans for Oak that can be monitored by external tooling. > > > Key: OAK-3478 > URL: https://issues.apache.org/jira/browse/OAK-3478 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, jcr, lucene, query >Affects Versions: 1.3.7 >Reporter: Ian Boston >Assignee: Chetan Mehrotra > Fix For: 1.3.11 > > Attachments: OAK-3478-v1.patch > > > The Current JMX beans, while ok in the Sling Web Console are hard if not > impossible to monitor with external tooling, as external tooling will poll > for current values, ideally from named attributes containing primitive types. > Those values containing timers, counters or gauges. Timers timing an > operation. Counters counting an operation. Guages measuring an instantaneous > value. > The request is to provide a small number of JMX beans that can be configured > into an external monitoring tool like AppDynamics, Ganglia, NewRelic, Splunk > etc etc, which in turn will provide long term time series and statistics. > Primitive values of this form can also be graphed with ease in JConsole, > VisualVM etc. A improvement for the Sling Web Console might be to add a > Console that can maintain a TimeSeries graph of any JMX bean by object name > in the same way Ganglia, AppDynamics does, however that may be duplicating > existing functionality. > The Metrics Library could be considered to provide the above functionality > for all JMX beans and monitoring, although its footprint at 111K might be > considered too big as an additional dependency. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-3613) Backport TarMK revision gc related issues
[ https://issues.apache.org/jira/browse/OAK-3613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14998629#comment-14998629 ] Michael Dürig edited comment on OAK-3613 at 11/18/15 11:25 AM: --- OAK-2734: Compaction does not finish on repository with continuous writes ([1675311|http://svn.apache.org/r1675311]) OAK-2862: CompactionMap#compress() inefficient for large compaction maps ([1678958|http://svn.apache.org/r1678958], [1679959|http://svn.apache.org/r1679959], [1679995|http://svn.apache.org/r1679995], [1683780|http://svn.apache.org/r1683780]) OAK-2713: High memory usage of CompactionMap ([1679958|http://svn.apache.org/r1679958]) (1.0 only) OAK-2849: Improve revision gc on SegmentMK ([1691216|http://svn.apache.org/r1691216], [1693194|http://svn.apache.org/r1693194]) OAK-3094: Potential ClassCastException with LIRS cache builder ([1690657|http://svn.apache.org/r1690657], [1690672|http://svn.apache.org/r1690672]) OAK-3095: Add eviction listener to LIRS cache ([1690991|http://svn.apache.org/r1690991]) OAK-3007: SegmentStore cache does not take "string" map into account ([1691217|http://svn.apache.org/r1691217], [1691218|http://svn.apache.org/r1691218]) OAK-3055: Improve segment cache in SegmentTracker ([1691219|http://svn.apache.org/r1691219], [1691220|http://svn.apache.org/r1691220]) OAK-3109: OOME in tarkmk standby tests ([1692272|http://svn.apache.org/r1692272], [1695829|http://svn.apache.org/r1695829], [1695830|http://svn.apache.org/r1695830]) OAK-3051: Improve compaction gain estimation logging for the case where there are no tar readers ([1691589|http://svn.apache.org/r1691589]) OAK-2384: SegmentNotFoundException when keeping JCR Value references ([1650503|http://svn.apache.org/r1650503], [1670137|http://svn.apache.org/r1670137]) (1.0 only) OAK-3095: Add eviction listener to LIRS cache ([1692234|http://svn.apache.org/r1692234]) OAK-3055: Improve segment cache in SegmentTracker ([1692235|http://svn.apache.org/r1692235]) OAK-3139: SNFE in persisted comapation map when using CLEAN_OLD ([1693022|http://svn.apache.org/r1693022], [1693195|http://svn.apache.org/r1693195]) OAK-3168: SegmentCache flushes Segment on update ([1694022|http://svn.apache.org/r1694022]) OAK-3179: Deadlock between persisted compaction map and cleanup ([1694208|http://svn.apache.org/r1694208]) OAK-3177: Compaction slow on repository with continuous writes ([1694497|http://svn.apache.org/r1694497]) OAK-3264: Deadlock between persisted compaction map and cleanup 2 ( [1696956|http://svn.apache.org/r1696956]) OAK-2875: Namespaces keep references to old node states ([1697423|http://svn.apache.org/r1697423]) OAK-3317: ConcurrentModificationException when running SegmentOverflowExceptionIT ([1700252|http://svn.apache.org/r1700252]) OAK-3347: Ineffective cleanup after compaction due to references to root ([1701239|http://svn.apache.org/r1701239]) OAK-3329: TarMK cleanup blocks writers ([1706818|http://svn.apache.org/r1706818]) OAK-3481: CompationMapTest does not close file store ([1706974|http://svn.apache.org/r1706974]) OAK-3172: Unreleased closed sessions can keep a root reference from getting collected ([1707073|http://svn.apache.org/r1707073]) OAK-3502: Improve logging during cleanup ([1707753|http://svn.apache.org/r1707753]) OAK-3501: PersistedCompactionMap could release reference to records early ([1708051|http://svn.apache.org/r1708051]) OAK-3511: Test failure: CompactionMapTest.removeSome ([1708297|http://svn.apache.org/r1708297], [1708298|http://svn.apache.org/r1708298]) OAK-3330: FileStore lock contention with concurrent writers ([1708401|http://svn.apache.org/r1708401], [1708402|http://svn.apache.org/r1708402], [1708403|http://svn.apache.org/r1708403]) OAK-3506: Uniformization of compaction log messages ([1708447|http://svn.apache.org/r1708447], [1710629|http://svn.apache.org/r1710629]) OAK-2581: Metatype info for SegmentNodeStoreService ([1664942|http://svn.apache.org/r1664942]) (1.0 only) OAK-2870: Introduce a SegmentNodeStoreBuilder to help wire a SegmentNodeStore ([1679998|http://svn.apache.org/r1679998]) OAK-3123: NPE in RecordIdMap ([1691965|http://svn.apache.org/r1691965]) OAK-1446: Offline tool to repair TarMK ([1586363|http://svn.apache.org/r1586363]) (1.0 only) OAK-3158: IAE when specifiying 2G cache for FileStore ([1694639|http://svn.apache.org/r1694639], [1702240|http://svn.apache.org/r1702240]) OAK-2962: SegmentNodeStoreService fails to handle empty strings in the OSGi configuration ([1687171|http://svn.apache.org/r1687171]) OAK-3048: Enable lookup of OSGi configuration from framework first and component next ([1693868|http://svn.apache.org/r1693868]) OAK-3052: Make compaction gain estimate threshold configurable ([1689805|http://svn.apache.org/r1689805]) OAK-3125: Skip compaction estimation if threshold is 0 ([1692063|http://svn.apache.org/r1692063],
[jira] [Commented] (OAK-2689) Test failure: QueryResultTest.testGetSize
[
https://issues.apache.org/jira/browse/OAK-2689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15010895#comment-15010895
]
Marcel Reutegger commented on OAK-2689:
---
Added to known issues list in 1.2 branch: http://svn.apache.org/r1714986 and
1.0 branch: http://svn.apache.org/r1714988
> Test failure: QueryResultTest.testGetSize
> -
>
> Key: OAK-2689
> URL: https://issues.apache.org/jira/browse/OAK-2689
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
> Environment: Jenkins, Ubuntu:
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/
>Reporter: Michael Dürig
>Assignee: Thomas Mueller
> Labels: CI, Jenkins
> Fix For: 1.3.9
>
>
> {{org.apache.jackrabbit.core.query.QueryResultTest.testGetSize}} fails every
> couple of builds:
> {noformat}
> junit.framework.AssertionFailedError: Wrong size of NodeIterator in result
> expected:<48> but was:<-1>
> at junit.framework.Assert.fail(Assert.java:50)
> at junit.framework.Assert.failNotEquals(Assert.java:287)
> at junit.framework.Assert.assertEquals(Assert.java:67)
> at junit.framework.Assert.assertEquals(Assert.java:134)
> at
> org.apache.jackrabbit.core.query.QueryResultTest.testGetSize(QueryResultTest.java:47)
> {noformat}
> Failure seen at builds: 29, 39, 59, 61, 114, 117, 118, 120, 139, 142
> See e.g.
> https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/59/jdk=jdk-1.6u45,label=Ubuntu,nsfixtures=DOCUMENT_NS,profile=unittesting/testReport/junit/org.apache.jackrabbit.core.query/QueryResultTest/testGetSize/
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3646) Inconsistent read of hierarchy
[ https://issues.apache.org/jira/browse/OAK-3646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15010950#comment-15010950 ] Marcel Reutegger commented on OAK-3646: --- The issue happens when revisions of a change are purged from the RevisionComparator and the order of two revisions changes. With the revision comparator and delayed visibility of changes from other cluster nodes it frequently happens that a local revision L happens before a foreign revision F even though timestamp(F) < timestamp(L). The RevisionComparator maintains this visibility information for revisions no older than one hour. I think the only viable solution is to add this information to the 'readRevision' of a node state. Right now a node state is identified by a path and a revision. In addition the key must also include the most recent visible revision from other cluster nodes. This way the information of the RevisionComparator is captured in the key and will survive the RevisionComparator purge. > Inconsistent read of hierarchy > --- > > Key: OAK-3646 > URL: https://issues.apache.org/jira/browse/OAK-3646 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, documentmk >Affects Versions: 1.0, 1.2 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Fix For: 1.4 > > > This is similar to OAK-3388, but about hierarchy information like which child > nodes exist at a given revision of the parent node. This issue only occurs in > a cluster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3559) Bulk document updates in MongoDocumentStore
[
https://issues.apache.org/jira/browse/OAK-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomek Rękawek updated OAK-3559:
---
Attachment: OAK-3559.patch
> Bulk document updates in MongoDocumentStore
> ---
>
> Key: OAK-3559
> URL: https://issues.apache.org/jira/browse/OAK-3559
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: core, documentmk, mongomk
>Reporter: Tomek Rękawek
> Fix For: 1.4
>
> Attachments: OAK-3559.patch
>
>
> The {{DocumentStore#createOrUpdate(Collection, UpdateOp)}} method is invoked
> in a loop in the {{Commit#applyToDocumentStore()}}, once for each changed
> node. Investigate if it's possible to implement a batch version of the
> createOrUpdate method, using the MongoDB [Bulk
> API|https://docs.mongodb.org/manual/reference/method/Bulk/#Bulk]. It should
> return all documents before they are modified, so the Commit class can
> discover conflicts (if they are any).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-2187) Document cache invalidation logic generating lots of garbage
[
https://issues.apache.org/jira/browse/OAK-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15010668#comment-15010668
]
Stefan Egli commented on OAK-2187:
--
It looks to me as if the old variant could not easily be removed since the new
variant uses ExternalSort which can throw an IOException. So removing the old
variant requires a different handling of that IOException case first.
> Document cache invalidation logic generating lots of garbage
>
>
> Key: OAK-2187
> URL: https://issues.apache.org/jira/browse/OAK-2187
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core
>Affects Versions: 1.0.7
> Environment: CQ6SP1+HF5176(Oak 1.0.7), 3 authors, 2 mongo in replica
> set with another arbiter.
>Reporter: Vikas Saurabh
>Assignee: Chetan Mehrotra
>
> We are observing around 2GB of temporary objects getting created every 20-30
> seconds
> Following is the result from
> {{/system/console/jmx/org.apache.jackrabbit.oak%3Aid%3D8%2Cname%3D"Consolidated+Cache+statistics"%2Ctype%3D"ConsolidatedCacheStats"}}:
> ||averageLoadPenalty||elementCount||evictionCount||hitCount||hitRate||loadCount||loadExceptionCount||loadSuccessCount||maxWeight||missCount||missRate||name||requestCount||totalLoadTime||totalWeight||
> |2ms|136054|14855|8293718384|0.96|222767|0|222767|612.0
> MB|372951359|0.043|Document-Documents|869743|8 min, 0 sec|611.2 MB|
> |0ms|95600|262264|146336|0.19|0|0|0|53.7
> MB|609878|0.81|Document-Diff|756214|0 min, 0 sec|53.7 MB|
> |0ms|1|0|31212|0.17|0|0|0|32.2 MB|156684|0.83|Document-DocChildren|187896|0
> min, 0 sec|4.8 kB|
> |3ms|78781|110556|25953581|0.98|181461|0|181461|107.4
> MB|508826|0.019|Document-NodeChildren|26462407|11 min, 29 sec|107.2 MB|
> |0ms|201619|2542876|440737116|0.99|2744495|0|2744495|268.4
> MB|2866721|0.0065|Document-NodeState|443603837|8 min, 36 sec|268.4 MB|
> Following is the thread-dump:
> {code}
> 2014-10-14 12:57:20
> Full thread dump OpenJDK 64-Bit Server VM (24.65-b04 mixed mode):
> "Thread-8668" - Thread t@18303
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown
> Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "Thread-8667" - Thread t@18302
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown
> Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "Thread-8666" - Thread t@18301
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown
> Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "Thread-8665" - Thread t@18300
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown
> Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "Thread-8664" - Thread t@18299
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown
> Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "Thread-8663" - Thread t@18298
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a
[jira] [Created] (OAK-3649) Extract node document cache from Mongo and RDB document stores
Tomek Rękawek created OAK-3649: -- Summary: Extract node document cache from Mongo and RDB document stores Key: OAK-3649 URL: https://issues.apache.org/jira/browse/OAK-3649 Project: Jackrabbit Oak Issue Type: Improvement Components: documentmk, mongomk, rdbmk Reporter: Tomek Rękawek Priority: Minor Fix For: 1.4 MongoDocumentStore and RDBDocumentStore contains copy & pasted methods responsible for handling node document cache. Extract these into a new NodeDocumentCache. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-2187) Document cache invalidation logic generating lots of garbage
[
https://issues.apache.org/jira/browse/OAK-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chetan Mehrotra resolved OAK-2187.
--
Resolution: Won't Fix
Fix Version/s: (was: 1.4)
Resolving as Wont Fix as with OAK-3002 a newer approach is used. Older approach
is only used as a fallaback if there is some issue in using Journal based
approach. So given older approach is not used much severity of this issue is
reduced.
[~mreutegg] [~egli] Should we get rid of older cache invalidation logic in
trunk completely?
> Document cache invalidation logic generating lots of garbage
>
>
> Key: OAK-2187
> URL: https://issues.apache.org/jira/browse/OAK-2187
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core
>Affects Versions: 1.0.7
> Environment: CQ6SP1+HF5176(Oak 1.0.7), 3 authors, 2 mongo in replica
> set with another arbiter.
>Reporter: Vikas Saurabh
>Assignee: Chetan Mehrotra
>
> We are observing around 2GB of temporary objects getting created every 20-30
> seconds
> Following is the result from
> {{/system/console/jmx/org.apache.jackrabbit.oak%3Aid%3D8%2Cname%3D"Consolidated+Cache+statistics"%2Ctype%3D"ConsolidatedCacheStats"}}:
> ||averageLoadPenalty||elementCount||evictionCount||hitCount||hitRate||loadCount||loadExceptionCount||loadSuccessCount||maxWeight||missCount||missRate||name||requestCount||totalLoadTime||totalWeight||
> |2ms|136054|14855|8293718384|0.96|222767|0|222767|612.0
> MB|372951359|0.043|Document-Documents|869743|8 min, 0 sec|611.2 MB|
> |0ms|95600|262264|146336|0.19|0|0|0|53.7
> MB|609878|0.81|Document-Diff|756214|0 min, 0 sec|53.7 MB|
> |0ms|1|0|31212|0.17|0|0|0|32.2 MB|156684|0.83|Document-DocChildren|187896|0
> min, 0 sec|4.8 kB|
> |3ms|78781|110556|25953581|0.98|181461|0|181461|107.4
> MB|508826|0.019|Document-NodeChildren|26462407|11 min, 29 sec|107.2 MB|
> |0ms|201619|2542876|440737116|0.99|2744495|0|2744495|268.4
> MB|2866721|0.0065|Document-NodeState|443603837|8 min, 36 sec|268.4 MB|
> Following is the thread-dump:
> {code}
> 2014-10-14 12:57:20
> Full thread dump OpenJDK 64-Bit Server VM (24.65-b04 mixed mode):
> "Thread-8668" - Thread t@18303
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown
> Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "Thread-8667" - Thread t@18302
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown
> Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "Thread-8666" - Thread t@18301
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown
> Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "Thread-8665" - Thread t@18300
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown
> Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "Thread-8664" - Thread t@18299
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown
> Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "Thread-8663" - Thread
[jira] [Comment Edited] (OAK-2187) Document cache invalidation logic generating lots of garbage
[
https://issues.apache.org/jira/browse/OAK-2187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15010562#comment-15010562
]
Chetan Mehrotra edited comment on OAK-2187 at 11/18/15 9:27 AM:
Resolving as Wont Fix as with OAK-3002 a newer approach is used. Older approach
is only used as a fallaback if there is some issue in using Journal based
approach. So given older approach is not used much severity of this issue is
reduced.
[~mreutegg] [~egli] [~catholicon] Should we get rid of older cache invalidation
logic in trunk completely?
was (Author: chetanm):
Resolving as Wont Fix as with OAK-3002 a newer approach is used. Older approach
is only used as a fallaback if there is some issue in using Journal based
approach. So given older approach is not used much severity of this issue is
reduced.
[~mreutegg] [~egli] Should we get rid of older cache invalidation logic in
trunk completely?
> Document cache invalidation logic generating lots of garbage
>
>
> Key: OAK-2187
> URL: https://issues.apache.org/jira/browse/OAK-2187
> Project: Jackrabbit Oak
> Issue Type: Task
> Components: core
>Affects Versions: 1.0.7
> Environment: CQ6SP1+HF5176(Oak 1.0.7), 3 authors, 2 mongo in replica
> set with another arbiter.
>Reporter: Vikas Saurabh
>Assignee: Chetan Mehrotra
>
> We are observing around 2GB of temporary objects getting created every 20-30
> seconds
> Following is the result from
> {{/system/console/jmx/org.apache.jackrabbit.oak%3Aid%3D8%2Cname%3D"Consolidated+Cache+statistics"%2Ctype%3D"ConsolidatedCacheStats"}}:
> ||averageLoadPenalty||elementCount||evictionCount||hitCount||hitRate||loadCount||loadExceptionCount||loadSuccessCount||maxWeight||missCount||missRate||name||requestCount||totalLoadTime||totalWeight||
> |2ms|136054|14855|8293718384|0.96|222767|0|222767|612.0
> MB|372951359|0.043|Document-Documents|869743|8 min, 0 sec|611.2 MB|
> |0ms|95600|262264|146336|0.19|0|0|0|53.7
> MB|609878|0.81|Document-Diff|756214|0 min, 0 sec|53.7 MB|
> |0ms|1|0|31212|0.17|0|0|0|32.2 MB|156684|0.83|Document-DocChildren|187896|0
> min, 0 sec|4.8 kB|
> |3ms|78781|110556|25953581|0.98|181461|0|181461|107.4
> MB|508826|0.019|Document-NodeChildren|26462407|11 min, 29 sec|107.2 MB|
> |0ms|201619|2542876|440737116|0.99|2744495|0|2744495|268.4
> MB|2866721|0.0065|Document-NodeState|443603837|8 min, 36 sec|268.4 MB|
> Following is the thread-dump:
> {code}
> 2014-10-14 12:57:20
> Full thread dump OpenJDK 64-Bit Server VM (24.65-b04 mixed mode):
> "Thread-8668" - Thread t@18303
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown
> Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "Thread-8667" - Thread t@18302
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown
> Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "Thread-8666" - Thread t@18301
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown
> Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "Thread-8665" - Thread t@18300
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on <400eb4d3> (a java.lang.Object)
> at EDU.oswego.cs.dl.util.concurrent.LinkedQueue.poll(Unknown Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor.getTask(Unknown
> Source)
> at EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Worker.run(Unknown
> Source)
> at java.lang.Thread.run(Thread.java:745)
>Locked ownable synchronizers:
> - None
> "Thread-8664" - Thread t@18299
>java.lang.Thread.State: TIMED_WAITING
> at java.lang.Object.wait(Native Method)
> - waiting on
[jira] [Commented] (OAK-3634) RDB/MongoDocumentStore may return stale documents
[
https://issues.apache.org/jira/browse/OAK-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15010693#comment-15010693
]
Julian Reschke commented on OAK-3634:
-
So how do we proceed from here?
1) The aforementioned unit test checks something we intend to change (and I'm
guilty of writing that test). Should we fix/remove the test?
2) My concern is that allowing update() to populate the cache with potentially
incorrect information will make it harder to debug other caching related
issues, thus I'd propose to fix it right away.
> RDB/MongoDocumentStore may return stale documents
> -
>
> Key: OAK-3634
> URL: https://issues.apache.org/jira/browse/OAK-3634
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mongomk, rdbmk
>Affects Versions: 1.3.10
>Reporter: Julian Reschke
> Attachments: OAK-3634.diff
>
>
> It appears that the implementations of the {{update}} method sometimes
> populate the memory cache with documents that do not reflect any current or
> previous state in the persistence (that is, miss changes made by another
> node).
> (will attach test)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3632) Incorrect Value Conversion upon Node.setProperty and Node.setValue
[
https://issues.apache.org/jira/browse/OAK-3632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15010526#comment-15010526
]
Michael Dürig commented on OAK-3632:
Just to be clear, the class comment of {{Conversions}} doesn't say to be "fully
compliant" with JSR 283. To the contrary, it mentions that is defines
additional conversions.
> Incorrect Value Conversion upon Node.setProperty and Node.setValue
> --
>
> Key: OAK-3632
> URL: https://issues.apache.org/jira/browse/OAK-3632
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: jcr
>Reporter: angela
> Attachments: OAK-3632.patch
>
>
> see container issue for test-cases and description
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3478) Provide JMX Beans for Oak that can be monitored by external tooling.
[
https://issues.apache.org/jira/browse/OAK-3478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15010669#comment-15010669
]
Michael Dürig commented on OAK-3478:
I think in general we should get rid of the time series and leave recording
tasks to monitoring tools. However, as this is not possible for all cases the
suggested approach looks like a good start to me. Instead of baking this into
Oak I would rather like to decouple it. Couldn't we make this into a separate
utility for monitoring that could be deployed and configured OSGi style? The
implementation could live e.g. in {{jcr-commons}} (like {{TimeSeries}}) and
default configuration/provisioning could happen from upstream projects like
Sling/Granite/AEM.
> Provide JMX Beans for Oak that can be monitored by external tooling.
>
>
> Key: OAK-3478
> URL: https://issues.apache.org/jira/browse/OAK-3478
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, jcr, lucene, query
>Affects Versions: 1.3.7
>Reporter: Ian Boston
>Assignee: Chetan Mehrotra
> Fix For: 1.3.11
>
> Attachments: OAK-3478-v1.patch
>
>
> The Current JMX beans, while ok in the Sling Web Console are hard if not
> impossible to monitor with external tooling, as external tooling will poll
> for current values, ideally from named attributes containing primitive types.
> Those values containing timers, counters or gauges. Timers timing an
> operation. Counters counting an operation. Guages measuring an instantaneous
> value.
> The request is to provide a small number of JMX beans that can be configured
> into an external monitoring tool like AppDynamics, Ganglia, NewRelic, Splunk
> etc etc, which in turn will provide long term time series and statistics.
> Primitive values of this form can also be graphed with ease in JConsole,
> VisualVM etc. A improvement for the Sling Web Console might be to add a
> Console that can maintain a TimeSeries graph of any JMX bean by object name
> in the same way Ganglia, AppDynamics does, however that may be duplicating
> existing functionality.
> The Metrics Library could be considered to provide the above functionality
> for all JMX beans and monitoring, although its footprint at 111K might be
> considered too big as an additional dependency.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-318) Excerpt support
[
https://issues.apache.org/jira/browse/OAK-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tommaso Teofili resolved OAK-318.
-
Resolution: Fixed
Assignee: Tommaso Teofili
I think we can consider this resolve as per current {{SimpleExcerptProvider}}
implementation in combination with Index based excerpt support (see OAK-818,
OAK-1783, OAK-3580).
> Excerpt support
> ---
>
> Key: OAK-318
> URL: https://issues.apache.org/jira/browse/OAK-318
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: core, query
>Reporter: Alex Parvulescu
>Assignee: Tommaso Teofili
> Fix For: 1.3.11
>
>
> Test class: ExcerptTest.
> Right now I only see parse errors:
> Caused by: java.text.ParseException: Query:
> {noformat}
> testroot/*[jcr:contains(., 'jackrabbit')]/rep:excerpt((*).); expected:
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3477) Make JMX Bean names predictable so they can be used in configurations.
[
https://issues.apache.org/jira/browse/OAK-3477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15010549#comment-15010549
]
Michael Dürig commented on OAK-3477:
Looks good I think. Do we know what the consequences are when we happen to run
into a name conflict? The impact should be contained within monitoring and not
affect overall system stability. Maybe we could do some validation around this.
Alternatively we could try to detect a name conflict and re-register in such a
case with disambiguation. Not sure it its worth the extra trouble though.
> Make JMX Bean names predictable so they can be used in configurations.
> --
>
> Key: OAK-3477
> URL: https://issues.apache.org/jira/browse/OAK-3477
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
>Affects Versions: 1.3.7
>Reporter: Ian Boston
>Assignee: Chetan Mehrotra
> Labels: candidate_oak_1_0, candidate_oak_1_2
> Fix For: 1.3.11
>
> Attachments: OAK-3477.patch
>
>
> In Oak there are JMX beans which get names of the form [1], which can be hard
> to use in monitoring tool configuration that dont support regexes as the ID
> will change. Where possible, the ID should be removed or made static. The
> name and type should be sufficient in most cases in Oak to make the JMX
> Object name unique.
> 1
> {code}
> org.apache.jackrabbit.oak:name="Consolidated Cache
> statistics",type="ConsolidatedCacheStats",id=6
> org.apache.jackrabbit.oak:name="CopyOnRead support
> statistics",type="CopyOnReadStats",id=7
> org.apache.jackrabbit.oak:name="Oak Repository
> Statistics",type="RepositoryStats",id=16
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3634) RDB/MongoDocumentStore may return stale documents
[
https://issues.apache.org/jira/browse/OAK-3634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15010457#comment-15010457
]
Marcel Reutegger commented on OAK-3634:
---
For consistency with behavior of other write operations in the DocumentStore, I
would still suggest to fix/change update(). All other write operations make
changes visible that happened before. This is a requirement for conflict
detection. So far the conflict detection does not depend on update(), which
probably means there is no urgent need to change the current implementation. A
commit either uses create(), createOrUpdate() or findAndUpdate(). Those
operations ensure the happens before semantics.
> RDB/MongoDocumentStore may return stale documents
> -
>
> Key: OAK-3634
> URL: https://issues.apache.org/jira/browse/OAK-3634
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mongomk, rdbmk
>Affects Versions: 1.3.10
>Reporter: Julian Reschke
> Attachments: OAK-3634.diff
>
>
> It appears that the implementations of the {{update}} method sometimes
> populate the memory cache with documents that do not reflect any current or
> previous state in the persistence (that is, miss changes made by another
> node).
> (will attach test)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3559) Bulk document updates in MongoDocumentStore
[
https://issues.apache.org/jira/browse/OAK-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomek Rękawek updated OAK-3559:
---
Attachment: (was: OAK-3559.patch)
> Bulk document updates in MongoDocumentStore
> ---
>
> Key: OAK-3559
> URL: https://issues.apache.org/jira/browse/OAK-3559
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: core, documentmk, mongomk
>Reporter: Tomek Rękawek
> Fix For: 1.4
>
> Attachments: OAK-3559.patch
>
>
> The {{DocumentStore#createOrUpdate(Collection, UpdateOp)}} method is invoked
> in a loop in the {{Commit#applyToDocumentStore()}}, once for each changed
> node. Investigate if it's possible to implement a batch version of the
> createOrUpdate method, using the MongoDB [Bulk
> API|https://docs.mongodb.org/manual/reference/method/Bulk/#Bulk]. It should
> return all documents before they are modified, so the Commit class can
> discover conflicts (if they are any).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (OAK-3650) Index based excerpt should be used for binaries
[ https://issues.apache.org/jira/browse/OAK-3650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili reassigned OAK-3650: Assignee: Tommaso Teofili > Index based excerpt should be used for binaries > --- > > Key: OAK-3650 > URL: https://issues.apache.org/jira/browse/OAK-3650 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene, query >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Fix For: 1.3.11, 1.2.9, 1.0.25 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3646) Inconsistent read of hierarchy
[ https://issues.apache.org/jira/browse/OAK-3646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15011126#comment-15011126 ] Marcel Reutegger commented on OAK-3646: --- Added another test similar to the previous one. This one creates child nodes and does not involve garbage collection: http://svn.apache.org/r1715007 > Inconsistent read of hierarchy > --- > > Key: OAK-3646 > URL: https://issues.apache.org/jira/browse/OAK-3646 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, documentmk >Affects Versions: 1.0, 1.2 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Fix For: 1.4 > > > This is similar to OAK-3388, but about hierarchy information like which child > nodes exist at a given revision of the parent node. This issue only occurs in > a cluster. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3652) RDB support: extend RDB export tool for CSV export
Julian Reschke created OAK-3652: --- Summary: RDB support: extend RDB export tool for CSV export Key: OAK-3652 URL: https://issues.apache.org/jira/browse/OAK-3652 Project: Jackrabbit Oak Issue Type: Technical task Components: rdbmk Affects Versions: 1.3.10 Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1736) Support for Faceted Search
[ https://issues.apache.org/jira/browse/OAK-1736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated OAK-1736: - Attachment: OAK-1736.2.patch updated patch > Support for Faceted Search > -- > > Key: OAK-1736 > URL: https://issues.apache.org/jira/browse/OAK-1736 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: lucene, query, solr >Reporter: Thomas Mueller >Assignee: Tommaso Teofili > Fix For: 1.4 > > Attachments: OAK-1736.2.patch > > > Details to be defined. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3654) Integrate with Metrics for various stats collection
[ https://issues.apache.org/jira/browse/OAK-3654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra updated OAK-3654: - Description: As suggested by [~ianeboston] in OAK-3478 current approach of collecting TimeSeries data is not easily consumable by other monitoring systems. Also just extracting the last moment data and exposing it in simple form would not be useful. Instead of that we should look into using Metrics library [1] for collecting metrics. To avoid having dependency on Metrics API all over in Oak we can come up with minimal interfaces which can be used in Oak and then provide an implementation backed by Metric. This task is meant to explore that aspect and come up with proposed changes to see if its feasible to make this change * metrics-core ~100KB in size with no dependency * ASL Licensee [1] http://metrics.dropwizard.io was: As suggested by [~ianeboston] in OAK-3478 current approach of collecting TimeSeries data is not easily consumable by other monitoring systems. Also just extracting the last moment data and exposing it in simple form would not be useful. Instead of that we should look into using Metrics library [1] for collecting metrics. To avoid having dependency on Metrics API all over in Oak we can come up with minimal interfaces which can be used in Oak and then provide an implementation backed by Metric. This task is meant to explore that aspect and come up with proposed changes to see if its feasible to make this change [1] http://metrics.dropwizard.io > Integrate with Metrics for various stats collection > > > Key: OAK-3654 > URL: https://issues.apache.org/jira/browse/OAK-3654 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: core >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: 1.4 > > > As suggested by [~ianeboston] in OAK-3478 current approach of collecting > TimeSeries data is not easily consumable by other monitoring systems. Also > just extracting the last moment data and exposing it in simple form would not > be useful. > Instead of that we should look into using Metrics library [1] for collecting > metrics. To avoid having dependency on Metrics API all over in Oak we can > come up with minimal interfaces which can be used in Oak and then provide an > implementation backed by Metric. > This task is meant to explore that aspect and come up with proposed changes > to see if its feasible to make this change > * metrics-core ~100KB in size with no dependency > * ASL Licensee > [1] http://metrics.dropwizard.io -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3478) Provide JMX Beans for Oak that can be monitored by external tooling.
[
https://issues.apache.org/jira/browse/OAK-3478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15012786#comment-15012786
]
Chetan Mehrotra commented on OAK-3478:
--
{quote}
The bean "Oak Repository Statistics-simple" produces the right type of stats,
but I think the the "per second" approach wont work as the sequence of numbers
from the existing TimeSeries follows the pattern
0,0,0,0,0,0,0,76100,0,0,0,0,0,0,0 etc. If the monitoring tool happens to
query either side of the 71600 value, then it get 0. To get 76100 it
has to query at exactly the correct time. You could use the per minute
value but it would be better not to re-invent the research in this area and
look at what others have already proven to work in production.
{quote}
Makes sense. Opened OAK-3654 to determine effort required to provide a metric
based implementation. Would close this issue as Wont Fix then
> Provide JMX Beans for Oak that can be monitored by external tooling.
>
>
> Key: OAK-3478
> URL: https://issues.apache.org/jira/browse/OAK-3478
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, jcr, lucene, query
>Affects Versions: 1.3.7
>Reporter: Ian Boston
>Assignee: Chetan Mehrotra
> Fix For: 1.3.11
>
> Attachments: OAK-3478-v1.patch
>
>
> The Current JMX beans, while ok in the Sling Web Console are hard if not
> impossible to monitor with external tooling, as external tooling will poll
> for current values, ideally from named attributes containing primitive types.
> Those values containing timers, counters or gauges. Timers timing an
> operation. Counters counting an operation. Guages measuring an instantaneous
> value.
> The request is to provide a small number of JMX beans that can be configured
> into an external monitoring tool like AppDynamics, Ganglia, NewRelic, Splunk
> etc etc, which in turn will provide long term time series and statistics.
> Primitive values of this form can also be graphed with ease in JConsole,
> VisualVM etc. A improvement for the Sling Web Console might be to add a
> Console that can maintain a TimeSeries graph of any JMX bean by object name
> in the same way Ganglia, AppDynamics does, however that may be duplicating
> existing functionality.
> The Metrics Library could be considered to provide the above functionality
> for all JMX beans and monitoring, although its footprint at 111K might be
> considered too big as an additional dependency.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-3654) Integrate with Metrics for various stats collection
Chetan Mehrotra created OAK-3654: Summary: Integrate with Metrics for various stats collection Key: OAK-3654 URL: https://issues.apache.org/jira/browse/OAK-3654 Project: Jackrabbit Oak Issue Type: New Feature Components: core Reporter: Chetan Mehrotra Assignee: Chetan Mehrotra Fix For: 1.4 As suggested by [~ianeboston] in OAK-3478 current approach of collecting TimeSeries data is not easily consumable by other monitoring systems. Also just extracting the last moment data and exposing it in simple form would not be useful. Instead of that we should look into using Metrics library [1] for collecting metrics. To avoid having dependency on Metrics API all over in Oak we can come up with minimal interfaces which can be used in Oak and then provide an implementation backed by Metric. This task is meant to explore that aspect and come up with proposed changes to see if its feasible to make this change [1] http://metrics.dropwizard.io -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2843) Broadcasting cache
[ https://issues.apache.org/jira/browse/OAK-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15013099#comment-15013099 ] Thomas Mueller commented on OAK-2843: - While testing, I found UDP did not work reliably on my machine. This was also experienced by others (the unit test originally failed when using VPN; and for Angela IPv6 doesn't seem to work). So I implemented a simple TCP broadcaster as well, and tested this. I found out that the simple implementation slows down startup quite a bit, because broadcasting is done synchronously right now. I need to decouple broadcasting to another thread, and use a ring buffer, so that if there are a lot of broadcasts, only as many are sent as there is actually time to send, so that performance doesn't suffer. > 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)
[jira] [Resolved] (OAK-3478) Provide JMX Beans for Oak that can be monitored by external tooling.
[ https://issues.apache.org/jira/browse/OAK-3478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved OAK-3478. -- Resolution: Won't Fix Fix Version/s: (was: 1.3.11) OAK-3654 supercedes this > Provide JMX Beans for Oak that can be monitored by external tooling. > > > Key: OAK-3478 > URL: https://issues.apache.org/jira/browse/OAK-3478 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, jcr, lucene, query >Affects Versions: 1.3.7 >Reporter: Ian Boston >Assignee: Chetan Mehrotra > Attachments: OAK-3478-v1.patch > > > The Current JMX beans, while ok in the Sling Web Console are hard if not > impossible to monitor with external tooling, as external tooling will poll > for current values, ideally from named attributes containing primitive types. > Those values containing timers, counters or gauges. Timers timing an > operation. Counters counting an operation. Guages measuring an instantaneous > value. > The request is to provide a small number of JMX beans that can be configured > into an external monitoring tool like AppDynamics, Ganglia, NewRelic, Splunk > etc etc, which in turn will provide long term time series and statistics. > Primitive values of this form can also be graphed with ease in JConsole, > VisualVM etc. A improvement for the Sling Web Console might be to add a > Console that can maintain a TimeSeries graph of any JMX bean by object name > in the same way Ganglia, AppDynamics does, however that may be duplicating > existing functionality. > The Metrics Library could be considered to provide the above functionality > for all JMX beans and monitoring, although its footprint at 111K might be > considered too big as an additional dependency. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3651) Remove HierrachialCacheInvalidator
[ https://issues.apache.org/jira/browse/OAK-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chetan Mehrotra resolved OAK-3651. -- Resolution: Fixed Done in 1715092. MongoDocumentStore#invalidateCache call now does invalidation by iteration > Remove HierrachialCacheInvalidator > -- > > Key: OAK-3651 > URL: https://issues.apache.org/jira/browse/OAK-3651 > Project: Jackrabbit Oak > Issue Type: Task > Components: mongomk >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Labels: technical_debt > Fix For: 1.3.11 > > > As discussed in OAK-2187 and due to changes done in OAK-3002 > HierrachialCacheInvalidator is now redundant and should be removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
