[
https://issues.apache.org/jira/browse/TIKA-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Radim Rehurek updated TIKA-3103:
--------------------------------
Description:
We're using the Tika Server with OCR:
_java -jar /pii_tools/tika/tika-server-1.24.1.jar -p 9998 -spawnChild -JXmx500m_
This used to work fine in previous versions (1.22, without _-spawnChild_).
But after upgrading to 1.24.1 with _-spawnChild_, two undersirable things
happen:
h3. 1. The CPU runs at 100% for >10 minutes, long after any Tika requests
should have finished.
These (zombie?) processes show in _top_ as Tesseract and consume all CPU cores
at 100%.
They eventually die but the machine is unusable in the mean time.
*Expected behaviour:* Tika cleans up spawned processes after itself: at most
after its timeout limit (which is 2 minutes I believe?)
h3. 2. The temp is full of files like:
{{root@38acd588ee22:/# ll /tmp/}}
{{total 197320}}
{{drwxrwxrwt 1 root root 24576 May 20 09:35 ./}}
{{drwxr-xr-x 1 root root 4096 May 20 08:40 ../}}
{{-rw-r--r-- 1 root root 9273920 May 20 08:56
TIKA_streamstore_11144988934311367241.tmp}}
{{-rw-r--r-- 1 root root 8938048 May 20 08:57
TIKA_streamstore_11649337406504198407.tmp}}
{{-rw-r--r-- 1 root root 9478720 May 20 08:56
TIKA_streamstore_13551529918743702933.tmp}}
{{-rw-r--r-- 1 root root 9151040 May 20 08:57
TIKA_streamstore_13568226047805501311.tmp}}
{{-rw-r--r-- 1 root root 7701056 May 20 08:56
TIKA_streamstore_13908373602714189455.tmp}}
{{-rw-r--r-- 1 root root 8847936 May 20 08:57
TIKA_streamstore_1480509612453630180.tmp}}
{{-rw-r--r-- 1 root root 4612672 May 20 08:57
TIKA_streamstore_15069413591682978216.tmp}}
{{-rw-r--r-- 1 root root 9486912 May 20 08:57
TIKA_streamstore_15221713181998716407.tmp}}
{{-rw-r--r-- 1 root root 5341760 May 20 08:57
TIKA_streamstore_1625697673397832661.tmp}}
{{-rw-r--r-- 1 root root 4637248 May 20 08:57
TIKA_streamstore_16818171974807595017.tmp}}
{{-rw-r--r-- 1 root root 9486912 May 20 08:57
TIKA_streamstore_17417982601345062665.tmp}}
{{-rw-r--r-- 1 root root 10584640 May 20 08:56
TIKA_streamstore_2032295370426928403.tmp}}
{{-rw-r--r-- 1 root root 7930432 May 20 08:56
TIKA_streamstore_2397616717844251306.tmp}}
{{…}}
{{-rw-r--r-- 1 root root 33367 May 20 08:55
apache-tika-11167866320029165062.tmp}}
{{-rw-r--r-- 1 root root 44353 May 20 08:54
apache-tika-1152515137515755865.tmp}}
{{-rw-r--r-- 1 root root 245279 May 20 08:52
apache-tika-12106368488659105236.tmp}}
{{-rw-r--r-- 1 root root 1759 May 20 08:47
apache-tika-12291680472524021463.tmp}}
{{-rw-r--r-- 1 root root 242756 May 20 08:49
apache-tika-12949538006801506982.tmp}}
{{-rw-r--r-- 1 root root 237290 May 20 08:49
apache-tika-13079688841505150289.tmp}}
{{-rw-r--r-- 1 root root 36232 May 20 08:46
apache-tika-14415716489394502082.tmp}}
{{-rw------- 1 root root 0 May 20 08:52 apache-tika-14763602384771268526.tmp}}
{{-rw-r--r-- 1 root root 317 May 20 09:09
apache-tika-14763602384771268526.tmp.txt}}
{{-rw------- 1 root root 0 May 20 08:54 apache-tika-15290421001014637244.tmp}}
{{-rw-r--r-- 1 root root 1912 May 20 09:13
apache-tika-15290421001014637244.tmp.txt}}
{{-rw-r--r-- 1 root root 33367 May 20 08:55
apache-tika-16361958133359282808.tmp}}
{{-rw-r--r-- 1 root root 6851 May 20 08:52
apache-tika-16442252641151531142.tmp}}
{{-rw------- 1 root root 0 May 20 08:52 apache-tika-16625923825737504853.tmp}}
{{-rw-r--r-- 1 root root 377 May 20 09:00
apache-tika-16625923825737504853.tmp.txt}}
{{-rw-r--r-- 1 root root 42924 May 20 08:50
apache-tika-16723588295792292246.tmp}}
slowly filling up the disk.
*Expected behaviour*: Tika cleans up disk space after itself.
These bugs I critical for us so we had to revert back to 1.22. What's the best
way to avoid these issues?
was:
We're using the Tika Server with OCR:
_java -jar /pii_tools/tika/tika-server-1.24.1.jar -p 9998 -spawnChild -JXmx500m_
This used to work fine in previous versions (1.22, without _-spawnChild_).
But after upgrading to 1.24.1 with _-spawnChild_, two undersirable things
happen:
h3. 1. The CPU runs at 100% for >10 minutes, long after any Tika requests
should have finished.
These (zombie?) processes show in _top_ as Tesseract and consume all CPU cores
at 100%.
They eventually die but the machine is unusable in the mean time.
*Expected behaviour:* Tika cleans up spawned processes after itself: at most
after its timeout limit (which is 2 minutes I believe?)
h3. 2. The temp is full of files like:
{{root@38acd588ee22:/# ll /tmp/}}
{{total 197320}}
{{drwxrwxrwt 1 root root 24576 May 20 09:35 ./}}
{{drwxr-xr-x 1 root root 4096 May 20 08:40 ../}}
{{-rw-r--r-- 1 root root 9273920 May 20 08:56
TIKA_streamstore_11144988934311367241.tmp}}
{{-rw-r--r-- 1 root root 8938048 May 20 08:57
TIKA_streamstore_11649337406504198407.tmp}}
{{-rw-r--r-- 1 root root 9478720 May 20 08:56
TIKA_streamstore_13551529918743702933.tmp}}
{{-rw-r--r-- 1 root root 9151040 May 20 08:57
TIKA_streamstore_13568226047805501311.tmp}}
{{-rw-r--r-- 1 root root 7701056 May 20 08:56
TIKA_streamstore_13908373602714189455.tmp}}
{{-rw-r--r-- 1 root root 8847936 May 20 08:57
TIKA_streamstore_1480509612453630180.tmp}}
{{-rw-r--r-- 1 root root 4612672 May 20 08:57
TIKA_streamstore_15069413591682978216.tmp}}
{{-rw-r--r-- 1 root root 9486912 May 20 08:57
TIKA_streamstore_15221713181998716407.tmp}}
{{-rw-r--r-- 1 root root 5341760 May 20 08:57
TIKA_streamstore_1625697673397832661.tmp}}
{{-rw-r--r-- 1 root root 4637248 May 20 08:57
TIKA_streamstore_16818171974807595017.tmp}}
{{-rw-r--r-- 1 root root 9486912 May 20 08:57
TIKA_streamstore_17417982601345062665.tmp}}
{{-rw-r--r-- 1 root root 10584640 May 20 08:56
TIKA_streamstore_2032295370426928403.tmp}}
{{-rw-r--r-- 1 root root 7930432 May 20 08:56
TIKA_streamstore_2397616717844251306.tmp}}
{{…}}
{{-rw-r--r-- 1 root root 33367 May 20 08:55
apache-tika-11167866320029165062.tmp}}
{{-rw-r--r-- 1 root root 44353 May 20 08:54
apache-tika-1152515137515755865.tmp}}
{{-rw-r--r-- 1 root root 245279 May 20 08:52
apache-tika-12106368488659105236.tmp}}
{{-rw-r--r-- 1 root root 1759 May 20 08:47
apache-tika-12291680472524021463.tmp}}
{{-rw-r--r-- 1 root root 242756 May 20 08:49
apache-tika-12949538006801506982.tmp}}
{{-rw-r--r-- 1 root root 237290 May 20 08:49
apache-tika-13079688841505150289.tmp}}
{{-rw-r--r-- 1 root root 36232 May 20 08:46
apache-tika-14415716489394502082.tmp}}
{{-rw------- 1 root root 0 May 20 08:52 apache-tika-14763602384771268526.tmp}}
{{-rw-r--r-- 1 root root 317 May 20 09:09
apache-tika-14763602384771268526.tmp.txt}}
{{-rw------- 1 root root 0 May 20 08:54 apache-tika-15290421001014637244.tmp}}
{{-rw-r--r-- 1 root root 1912 May 20 09:13
apache-tika-15290421001014637244.tmp.txt}}
{{-rw-r--r-- 1 root root 33367 May 20 08:55
apache-tika-16361958133359282808.tmp}}
{{-rw-r--r-- 1 root root 6851 May 20 08:52
apache-tika-16442252641151531142.tmp}}
{{-rw------- 1 root root 0 May 20 08:52 apache-tika-16625923825737504853.tmp}}
{{-rw-r--r-- 1 root root 377 May 20 09:00
apache-tika-16625923825737504853.tmp.txt}}
{{-rw-r--r-- 1 root root 42924 May 20 08:50
apache-tika-16723588295792292246.tmp}}
slowly filling up the disk.
*Expected behaviour*: Tika cleans up disk space after itself.
These bugs I critical for us so we had to revert back to 1.22. What's the best
way to avoid these issues?
> Tesseract fails to respect timeouts and clean up after itself
> -------------------------------------------------------------
>
> Key: TIKA-3103
> URL: https://issues.apache.org/jira/browse/TIKA-3103
> Project: Tika
> Issue Type: Bug
> Components: ocr
> Affects Versions: 1.24.1
> Reporter: Radim Rehurek
> Priority: Critical
>
> We're using the Tika Server with OCR:
> _java -jar /pii_tools/tika/tika-server-1.24.1.jar -p 9998 -spawnChild
> -JXmx500m_
>
> This used to work fine in previous versions (1.22, without _-spawnChild_).
> But after upgrading to 1.24.1 with _-spawnChild_, two undersirable things
> happen:
> h3. 1. The CPU runs at 100% for >10 minutes, long after any Tika requests
> should have finished.
> These (zombie?) processes show in _top_ as Tesseract and consume all CPU
> cores at 100%.
> They eventually die but the machine is unusable in the mean time.
> *Expected behaviour:* Tika cleans up spawned processes after itself: at most
> after its timeout limit (which is 2 minutes I believe?)
> h3. 2. The temp is full of files like:
> {{root@38acd588ee22:/# ll /tmp/}}
> {{total 197320}}
> {{drwxrwxrwt 1 root root 24576 May 20 09:35 ./}}
> {{drwxr-xr-x 1 root root 4096 May 20 08:40 ../}}
> {{-rw-r--r-- 1 root root 9273920 May 20 08:56
> TIKA_streamstore_11144988934311367241.tmp}}
> {{-rw-r--r-- 1 root root 8938048 May 20 08:57
> TIKA_streamstore_11649337406504198407.tmp}}
> {{-rw-r--r-- 1 root root 9478720 May 20 08:56
> TIKA_streamstore_13551529918743702933.tmp}}
> {{-rw-r--r-- 1 root root 9151040 May 20 08:57
> TIKA_streamstore_13568226047805501311.tmp}}
> {{-rw-r--r-- 1 root root 7701056 May 20 08:56
> TIKA_streamstore_13908373602714189455.tmp}}
> {{-rw-r--r-- 1 root root 8847936 May 20 08:57
> TIKA_streamstore_1480509612453630180.tmp}}
> {{-rw-r--r-- 1 root root 4612672 May 20 08:57
> TIKA_streamstore_15069413591682978216.tmp}}
> {{-rw-r--r-- 1 root root 9486912 May 20 08:57
> TIKA_streamstore_15221713181998716407.tmp}}
> {{-rw-r--r-- 1 root root 5341760 May 20 08:57
> TIKA_streamstore_1625697673397832661.tmp}}
> {{-rw-r--r-- 1 root root 4637248 May 20 08:57
> TIKA_streamstore_16818171974807595017.tmp}}
> {{-rw-r--r-- 1 root root 9486912 May 20 08:57
> TIKA_streamstore_17417982601345062665.tmp}}
> {{-rw-r--r-- 1 root root 10584640 May 20 08:56
> TIKA_streamstore_2032295370426928403.tmp}}
> {{-rw-r--r-- 1 root root 7930432 May 20 08:56
> TIKA_streamstore_2397616717844251306.tmp}}
> {{…}}
> {{-rw-r--r-- 1 root root 33367 May 20 08:55
> apache-tika-11167866320029165062.tmp}}
> {{-rw-r--r-- 1 root root 44353 May 20 08:54
> apache-tika-1152515137515755865.tmp}}
> {{-rw-r--r-- 1 root root 245279 May 20 08:52
> apache-tika-12106368488659105236.tmp}}
> {{-rw-r--r-- 1 root root 1759 May 20 08:47
> apache-tika-12291680472524021463.tmp}}
> {{-rw-r--r-- 1 root root 242756 May 20 08:49
> apache-tika-12949538006801506982.tmp}}
> {{-rw-r--r-- 1 root root 237290 May 20 08:49
> apache-tika-13079688841505150289.tmp}}
> {{-rw-r--r-- 1 root root 36232 May 20 08:46
> apache-tika-14415716489394502082.tmp}}
> {{-rw------- 1 root root 0 May 20 08:52
> apache-tika-14763602384771268526.tmp}}
> {{-rw-r--r-- 1 root root 317 May 20 09:09
> apache-tika-14763602384771268526.tmp.txt}}
> {{-rw------- 1 root root 0 May 20 08:54
> apache-tika-15290421001014637244.tmp}}
> {{-rw-r--r-- 1 root root 1912 May 20 09:13
> apache-tika-15290421001014637244.tmp.txt}}
> {{-rw-r--r-- 1 root root 33367 May 20 08:55
> apache-tika-16361958133359282808.tmp}}
> {{-rw-r--r-- 1 root root 6851 May 20 08:52
> apache-tika-16442252641151531142.tmp}}
> {{-rw------- 1 root root 0 May 20 08:52
> apache-tika-16625923825737504853.tmp}}
> {{-rw-r--r-- 1 root root 377 May 20 09:00
> apache-tika-16625923825737504853.tmp.txt}}
> {{-rw-r--r-- 1 root root 42924 May 20 08:50
> apache-tika-16723588295792292246.tmp}}
>
> slowly filling up the disk.
> *Expected behaviour*: Tika cleans up disk space after itself.
>
> These bugs I critical for us so we had to revert back to 1.22. What's the
> best way to avoid these issues?
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
