[
https://issues.apache.org/jira/browse/TIKA-2849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16824895#comment-16824895
]
Boris Petrov commented on TIKA-2849:
------------------------------------
[[email protected]] I see now, thanks. By "parsing" you mean
text-extraction, correct?
The funny thing is that we have our own abstraction of a File (which could be a
local file, a network one or just a stream in memory) and we use Tika by
*always* passing a stream we get from this File of ours. And we have our own
method of converting this File to a local file (which is smart and doesn't make
a copy if this is already a local file). But now I see that Tika actually
prefers in some places a file to be passed instead of a stream (which, by the
way, I haven't read anywhere in the documentation so you might want to improve
that a bit so others are not bitten like me) but that doesn't very well match
our own File abstraction.
So a question I would ask now is is it possible, when calling {{Tika.parse}} or
{{Tika.detect}}, to *know* whether it/a detector will need to spool to a file
so that we can use our own mechanism for that and not pass it a stream but
rather a file?
> TikaInputStream copies the input stream locally
> -----------------------------------------------
>
> Key: TIKA-2849
> URL: https://issues.apache.org/jira/browse/TIKA-2849
> Project: Tika
> Issue Type: Bug
> Affects Versions: 1.20
> Reporter: Boris Petrov
> Assignee: Tim Allison
> Priority: Major
> Fix For: 1.21
>
>
> When doing "tika.detect(stream, name)" and the stream is a "TikaInputStream",
> execution gets to "TikaInputStream#getPath" which does a "Files.copy(in,
> path, REPLACE_EXISTING);" which is very, very bad. This input stream could
> be, as in our case, an input stream from a network file which is tens or
> hundreds of gigabytes large. Copying it locally is a huge waste of resources
> to say the least. Why does it do that and can I make it not do it? Or is this
> something that has to be fixed in Tika?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
