tika-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tyler Palsulich (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (TIKA-591) Separate launcer process for forking JVMs
Date Sun, 01 Mar 2015 07:43:05 GMT

    [ https://issues.apache.org/jira/browse/TIKA-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14342034#comment-14342034
] 

Tyler Palsulich commented on TIKA-591:
--------------------------------------

Is there still interest in this, or is it superseded by tika-batch?

> Separate launcer process for forking JVMs
> -----------------------------------------
>
>                 Key: TIKA-591
>                 URL: https://issues.apache.org/jira/browse/TIKA-591
>             Project: Tika
>          Issue Type: Improvement
>          Components: parser
>            Reporter: Jukka Zitting
>            Assignee: Jukka Zitting
>            Priority: Minor
>
> As a followup to TIKA-416, it would be good to implement at least optional support for
a separate launcher process for the ForkParser feature. The need for such an extra process
came up in JCR-2864 where a reference to http://developers.sun.com/solaris/articles/subprocess/subprocess.html
 was made.
> To summarize, the problem is that the ProcessBuilder.start() call can result in a temporary
duplication of the memory space of the parent JVM. Even with copy-on-write semantics this
can be a fairly expensive operation and prone to out-of-memory issues especially in large-scale
deployments where the parent JVM already uses the majority of the available RAM on a computer.
> A similar problem is also being discussed at HADOOP-5059.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message