[jira] [Updated] (OAK-4585) Text extraction: runtime status monitoring
[ https://issues.apache.org/jira/browse/OAK-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-4585: Fix Version/s: 1.6 > Text extraction: runtime status monitoring > -- > > Key: OAK-4585 > URL: https://issues.apache.org/jira/browse/OAK-4585 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.6, 1.5.8, 1.4.7 > > > Text extraction is sometimes slow, and, in case of a bug in the text > extraction library, can even get stuck in an endless loop. > Right now, it is not easy to understand what is going on, even when looking > at full thread dumps. (Debug) log information about the current state of text > extraction would be nice as well. > I suggest we add debug level logging for the current extracted binary > (content identity). For larger binaries, we can also temporarily set the > thread name (append "Extracting "). That way, it is > relatively easy to see if text extraction is stuck simply looking at full > thread dumps, without having to change the log level and then reindex. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4585) Text extraction: runtime status monitoring
[ https://issues.apache.org/jira/browse/OAK-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-4585: Fix Version/s: (was: 1.6) 1.5.8 > Text extraction: runtime status monitoring > -- > > Key: OAK-4585 > URL: https://issues.apache.org/jira/browse/OAK-4585 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.5.8, 1.4.7 > > > Text extraction is sometimes slow, and, in case of a bug in the text > extraction library, can even get stuck in an endless loop. > Right now, it is not easy to understand what is going on, even when looking > at full thread dumps. (Debug) log information about the current state of text > extraction would be nice as well. > I suggest we add debug level logging for the current extracted binary > (content identity). For larger binaries, we can also temporarily set the > thread name (append "Extracting "). That way, it is > relatively easy to see if text extraction is stuck simply looking at full > thread dumps, without having to change the log level and then reindex. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4585) Text extraction: runtime status monitoring
[ https://issues.apache.org/jira/browse/OAK-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-4585: -- Fix Version/s: (was: 1.4.6) 1.4.7 > Text extraction: runtime status monitoring > -- > > Key: OAK-4585 > URL: https://issues.apache.org/jira/browse/OAK-4585 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.6, 1.4.7 > > > Text extraction is sometimes slow, and, in case of a bug in the text > extraction library, can even get stuck in an endless loop. > Right now, it is not easy to understand what is going on, even when looking > at full thread dumps. (Debug) log information about the current state of text > extraction would be nice as well. > I suggest we add debug level logging for the current extracted binary > (content identity). For larger binaries, we can also temporarily set the > thread name (append "Extracting "). That way, it is > relatively easy to see if text extraction is stuck simply looking at full > thread dumps, without having to change the log level and then reindex. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4585) Text extraction: runtime status monitoring
[ https://issues.apache.org/jira/browse/OAK-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-4585: -- Fix Version/s: (was: 1.5.7) 1.6 > Text extraction: runtime status monitoring > -- > > Key: OAK-4585 > URL: https://issues.apache.org/jira/browse/OAK-4585 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.6, 1.4.6 > > > Text extraction is sometimes slow, and, in case of a bug in the text > extraction library, can even get stuck in an endless loop. > Right now, it is not easy to understand what is going on, even when looking > at full thread dumps. (Debug) log information about the current state of text > extraction would be nice as well. > I suggest we add debug level logging for the current extracted binary > (content identity). For larger binaries, we can also temporarily set the > thread name (append "Extracting "). That way, it is > relatively easy to see if text extraction is stuck simply looking at full > thread dumps, without having to change the log level and then reindex. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-4585) Text extraction: runtime status monitoring
[ https://issues.apache.org/jira/browse/OAK-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas Mueller updated OAK-4585: Fix Version/s: 1.5.7 1.4.6 > Text extraction: runtime status monitoring > -- > > Key: OAK-4585 > URL: https://issues.apache.org/jira/browse/OAK-4585 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: lucene >Reporter: Thomas Mueller >Assignee: Thomas Mueller > Fix For: 1.4.6, 1.5.7 > > > Text extraction is sometimes slow, and, in case of a bug in the text > extraction library, can even get stuck in an endless loop. > Right now, it is not easy to understand what is going on, even when looking > at full thread dumps. (Debug) log information about the current state of text > extraction would be nice as well. > I suggest we add debug level logging for the current extracted binary > (content identity). For larger binaries, we can also temporarily set the > thread name (append "Extracting "). That way, it is > relatively easy to see if text extraction is stuck simply looking at full > thread dumps, without having to change the log level and then reindex. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
