You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@nutch.apache.org by Claudio Martella <cl...@tis.bz.it> on 2010/06/30 15:52:01 UTC
Hangup of fetcher threads
Hello,
I'm using nutch 1.1 (with crawl command) to crawl an intranet document
archive via webdav. At the end of each fetch phase the fetcher hungs
like this:
-activeThreads=5, spinWaiting=0, fetchQueues.totalSize=250
from my analysis of network traffic, nothing is passing by. The logs show:
2010-06-30 13:38:35,335 INFO fetcher.Fetcher - fetching
https://192.168.10.10/data/public/50.90_In_Bearbeitung/Stefano%20P/normen2010/normen2010.indd
2010-06-30 13:38:35,381 INFO auth.AuthChallengeProcessor - basic
authentication scheme selected
2010-06-30 13:38:35,819 INFO fetcher.Fetcher - -activeThreads=5,
spinWaiting=0, fetchQueues.totalSize=249
2010-06-30 13:38:36,824 INFO fetcher.Fetcher - -activeThreads=5,
spinWaiting=0, fetchQueues.totalSize=250
which i guess means i finish downloading the specified file and then it
hungs until:
2010-06-30 13:43:35,963 INFO fetcher.Fetcher - -activeThreads=5,
spinWaiting=0, fetchQueues.totalSize=250
2010-06-30 13:43:35,963 WARN fetcher.Fetcher - Aborting with 5 hung
threads.
so basically 5 minutes without doing anything.
this is my configuration in nutch-site.xml related to fetcher:
<property>
<name>fetcher.server.delay</name>
<value>0.0</value>
</property>
<property>
<name>fetcher.server.min.delay</name>
<value>0.0</value>
</property>
<property>
<name>fetcher.threads.fetch</name>
<value>5</value>
</property>
<property>
<name>fetcher.threads.per.host</name>
<value>5</value>
</property>
<property>
<name>fetcher.threads.per.host.by.ip</name>
<value>false</value>
</property>
Any idea why this is happening?
Thanks
Claudio
--
Claudio Martella
Digital Technologies
Unit Research & Development - Analyst
TIS innovation park
Via Siemens 19 | Siemensstr. 19
39100 Bolzano | 39100 Bozen
Tel. +39 0471 068 123
Fax +39 0471 068 129
claudio.martella@tis.bz.it http://www.tis.bz.it
Short information regarding use of personal data. According to Section 13 of Italian Legislative Decree no. 196 of 30 June 2003, we inform you that we process your personal data in order to fulfil contractual and fiscal obligations and also to send you information regarding our services and events. Your personal data are processed with and without electronic means and by respecting data subjects' rights, fundamental freedoms and dignity, particularly with regard to confidentiality, personal identity and the right to personal data protection. At any time and without formalities you can write an e-mail to privacy@tis.bz.it in order to object the processing of your personal data for the purpose of sending advertising materials and also to exercise the right to access personal data and other rights referred to in Section 7 of Decree 196/2003. The data controller is TIS Techno Innovation Alto Adige, Siemens Street n. 19, Bolzano. You can find the complete information on the web site www.tis.bz.it.
Re: Hangup of fetcher threads
Posted by Max Lynch <ih...@gmail.com>.
This also happens to me quite a bit. I cut down the thread count to a
smaller size and that seems to help, but it's random (I'm using trunk)
On Wed, Jun 30, 2010 at 3:17 PM, reinhard schwab <re...@aon.at>wrote:
> connect with jconsole to the java vm of nutch and look at the stack
> traces of the threads.
> you will get more info there.
>
> Claudio Martella schrieb:
> > Hello,
> >
> > I'm using nutch 1.1 (with crawl command) to crawl an intranet document
> > archive via webdav. At the end of each fetch phase the fetcher hungs
> > like this:
> >
> > -activeThreads=5, spinWaiting=0, fetchQueues.totalSize=250
> >
> > from my analysis of network traffic, nothing is passing by. The logs
> show:
> >
> > 2010-06-30 13:38:35,335 INFO fetcher.Fetcher - fetching
> >
> https://192.168.10.10/data/public/50.90_In_Bearbeitung/Stefano%20P/normen2010/normen2010.indd
> > 2010-06-30 13:38:35,381 INFO auth.AuthChallengeProcessor - basic
> > authentication scheme selected
> > 2010-06-30 13:38:35,819 INFO fetcher.Fetcher - -activeThreads=5,
> > spinWaiting=0, fetchQueues.totalSize=249
> > 2010-06-30 13:38:36,824 INFO fetcher.Fetcher - -activeThreads=5,
> > spinWaiting=0, fetchQueues.totalSize=250
> >
> > which i guess means i finish downloading the specified file and then it
> > hungs until:
> >
> > 2010-06-30 13:43:35,963 INFO fetcher.Fetcher - -activeThreads=5,
> > spinWaiting=0, fetchQueues.totalSize=250
> > 2010-06-30 13:43:35,963 WARN fetcher.Fetcher - Aborting with 5 hung
> > threads.
> >
> > so basically 5 minutes without doing anything.
> >
> > this is my configuration in nutch-site.xml related to fetcher:
> >
> > <property>
> > <name>fetcher.server.delay</name>
> > <value>0.0</value>
> > </property>
> >
> > <property>
> > <name>fetcher.server.min.delay</name>
> > <value>0.0</value>
> > </property>
> >
> > <property>
> > <name>fetcher.threads.fetch</name>
> > <value>5</value>
> > </property>
> >
> > <property>
> > <name>fetcher.threads.per.host</name>
> > <value>5</value>
> > </property>
> >
> > <property>
> > <name>fetcher.threads.per.host.by.ip</name>
> > <value>false</value>
> > </property>
> >
> > Any idea why this is happening?
> >
> >
> > Thanks
> >
> >
> > Claudio
> >
> >
>
>
Re: Hangup of fetcher threads
Posted by Julien Nioche <li...@gmail.com>.
well spotted! Should have checked the name indeed. Anyway, Claudio let us
know how you are getting on.
Julien
On 6 July 2010 17:23, Andrzej Bialecki <ab...@getopt.org> wrote:
> On 2010-07-06 16:22, Julien Nioche wrote:
>
>> i'm trying to reproduce the problem outside of the "crawl" command,
>>> through multi-step script approach.
>>> the problem happens again before the parse command.
>>>
>>
>>
>> you specified -noparse on the fetch command line, didn't you?
>>
>>
>> i guess the problem
>>> is indeed in the protocol-httpclient. Though i can't understand what's
>>> happening. Why, in the fetching phase, the tika parser is called for
>>> TXT? The parser is called on the content in the Fetcher output() method.
>>>
>>>
>> the parser should not be called at all if you specify -noparse for the
>> fetch
>>
>> as for TXT the parser is used to find outlinks
>>
>>
> Careful here - the option is called -noParsing. -noparse won't work, in
> such case Fetcher will default to whatever was set in
> nutch-site/nutch-default.xml (which often is set to parsing).
>
>
> --
> Best regards,
> Andrzej Bialecki <><
> ___. ___ ___ ___ _ _ __________________________________
> [__ || __|__/|__||\/| Information Retrieval, Semantic Web
> ___|||__|| \| || | Embedded Unix, System Integration
> http://www.sigram.com Contact: info at sigram dot com
>
>
--
DigitalPebble Ltd
Open Source Solutions for Text Engineering
http://www.digitalpebble.com
Re: Hangup of fetcher threads
Posted by Andrzej Bialecki <ab...@getopt.org>.
On 2010-07-06 16:22, Julien Nioche wrote:
>> i'm trying to reproduce the problem outside of the "crawl" command,
>> through multi-step script approach.
>> the problem happens again before the parse command.
>
>
> you specified -noparse on the fetch command line, didn't you?
>
>
>> i guess the problem
>> is indeed in the protocol-httpclient. Though i can't understand what's
>> happening. Why, in the fetching phase, the tika parser is called for
>> TXT? The parser is called on the content in the Fetcher output() method.
>>
>
> the parser should not be called at all if you specify -noparse for the fetch
>
> as for TXT the parser is used to find outlinks
>
Careful here - the option is called -noParsing. -noparse won't work, in
such case Fetcher will default to whatever was set in
nutch-site/nutch-default.xml (which often is set to parsing).
--
Best regards,
Andrzej Bialecki <><
___. ___ ___ ___ _ _ __________________________________
[__ || __|__/|__||\/| Information Retrieval, Semantic Web
___|||__|| \| || | Embedded Unix, System Integration
http://www.sigram.com Contact: info at sigram dot com
Re: Hangup of fetcher threads
Posted by Julien Nioche <li...@gmail.com>.
Hi Claudio
By decoupling fetching and parsing, as you advised me, i could see that
> the tika parser is actually looping on some files (which the file
> command sees as "data" files) that apache is declaring with a mime type
> plain/text, fooling tika. I guess tika should be able to handle this
> error which is not.
>
The parameter 'mime.type.magic' specify whether the detection of the
mimetype by Tika has to be used or not. The default value is true so
assuming that this is what you are using then Tika would simply use the mime
type advertised by the server as a hint only.
Try Tika directly with
***curl URL | java -jar tika-app-0.8-SNAPSHOT.jar*
to see how it is behaving without being given a hint. Are the URLs you
mentioned publicly available? If so please file a JIRA in Tika to describe
the issue
Thanks
J.
--
DigitalPebble Ltd
Open Source Solutions for Text Engineering
http://www.digitalpebble.com
Re: Hangup of fetcher threads
Posted by Claudio Martella <cl...@tis.bz.it>.
Julien Nioche wrote:
>> i'm trying to reproduce the problem outside of the "crawl" command,
>> through multi-step script approach.
>> the problem happens again before the parse command.
>>
>
>
> you specified -noparse on the fetch command line, didn't you?
>
>
>
no, i was fooled by the wiki
http://wiki.apache.org/nutch/Nutch_0.9_Crawl_Script_Tutorial where the
command fetch isn't using the -noParsing option and is followed by the
parse command.
So it didn't make much sense to me to parse twice and it didn't look
like the right way to spot my problem.
By decoupling fetching and parsing, as you advised me, i could see that
the tika parser is actually looping on some files (which the file
command sees as "data" files) that apache is declaring with a mime type
plain/text, fooling tika. I guess tika should be able to handle this
error which is not.
By applying Andrej's patch to 1.1 i could solve this dead threads issues
that were eating all my memory and finish the crawling.
Thanks
>> i guess the problem
>> is indeed in the protocol-httpclient. Though i can't understand what's
>> happening. Why, in the fetching phase, the tika parser is called for
>> TXT? The parser is called on the content in the Fetcher output() method.
>>
>>
>
> the parser should not be called at all if you specify -noparse for the fetch
>
> as for TXT the parser is used to find outlinks
>
>
--
Claudio Martella
Digital Technologies
Unit Research & Development - Analyst
TIS innovation park
Via Siemens 19 | Siemensstr. 19
39100 Bolzano | 39100 Bozen
Tel. +39 0471 068 123
Fax +39 0471 068 129
claudio.martella@tis.bz.it http://www.tis.bz.it
Short information regarding use of personal data. According to Section 13 of Italian Legislative Decree no. 196 of 30 June 2003, we inform you that we process your personal data in order to fulfil contractual and fiscal obligations and also to send you information regarding our services and events. Your personal data are processed with and without electronic means and by respecting data subjects' rights, fundamental freedoms and dignity, particularly with regard to confidentiality, personal identity and the right to personal data protection. At any time and without formalities you can write an e-mail to privacy@tis.bz.it in order to object the processing of your personal data for the purpose of sending advertising materials and also to exercise the right to access personal data and other rights referred to in Section 7 of Decree 196/2003. The data controller is TIS Techno Innovation Alto Adige, Siemens Street n. 19, Bolzano. You can find the complete information on the web site www.tis.bz.it.
Re: Hangup of fetcher threads
Posted by Julien Nioche <li...@gmail.com>.
> i'm trying to reproduce the problem outside of the "crawl" command,
> through multi-step script approach.
> the problem happens again before the parse command.
you specified -noparse on the fetch command line, didn't you?
> i guess the problem
> is indeed in the protocol-httpclient. Though i can't understand what's
> happening. Why, in the fetching phase, the tika parser is called for
> TXT? The parser is called on the content in the Fetcher output() method.
>
the parser should not be called at all if you specify -noparse for the fetch
as for TXT the parser is used to find outlinks
Re: Hangup of fetcher threads
Posted by Claudio Martella <cl...@tis.bz.it>.
Julien Nioche wrote:
> Hi
>
>
>
>> Anyway, from the logs, i see that it ended up trying to parse Thumb.db
>> files and some .pyd files which looked to it like plain-text.
>> By ignoring .db and .pyd files in craw-urlfilter i managed to get the
>> number of hanging threads down to a lower number. This is good to
>> understand what's happening but i can't predict all the extensions the
>> crawler is going to meet during the filesystem crawl.
>>
>> my parsing configuration is :
>>
>>
>> <name>plugin.includes</name>
>>
>> <value>protocol-httpclient|parse-(rss|text|html|tika)|language-identifier|urlfilter-regex|index-(basic|anchor)|response-(json|xml)|summary-basic|scoring-opic|urlnormalizer-(pass|regex|basic)</value>
>>
>>
>> Do you have any suggestions? Should i file an issue?
>>
>>
>
> First I'd do the parsing separately from the fetching. If the parsing fails
> you can always retry with different params without having to refetch.
>
> I think there are some issues with protocol-httpclient so if you don't need
> identification use protocol-http instead.
>
>
i start to believe that the problem is here.
i'm trying to reproduce the problem outside of the "crawl" command,
through multi-step script approach.
the problem happens again before the parse command. i guess the problem
is indeed in the protocol-httpclient. Though i can't understand what's
happening. Why, in the fetching phase, the tika parser is called for
TXT? The parser is called on the content in the Fetcher output() method.
I'll try to switch back to protocol-http and ask the sysadmins to put my
ip in the webserver's whitelist.
> See https://issues.apache.org/jira/browse/NUTCH-696 - Andrzej has provided a
> patch which would be the solution to your problem
>
>
that could be a nice idea, actually
> Finally if you are able to identify the URLs which are problematic in the
> logs try using Tika directly to see whether the problem comes from there
> (e.g. parsing loop, wrong identification of mime-type etc...) and if so file
> an issue on the Tika JIRA.
>
> HTH
>
> Julien
>
--
Claudio Martella
Digital Technologies
Unit Research & Development - Analyst
TIS innovation park
Via Siemens 19 | Siemensstr. 19
39100 Bolzano | 39100 Bozen
Tel. +39 0471 068 123
Fax +39 0471 068 129
claudio.martella@tis.bz.it http://www.tis.bz.it
Short information regarding use of personal data. According to Section 13 of Italian Legislative Decree no. 196 of 30 June 2003, we inform you that we process your personal data in order to fulfil contractual and fiscal obligations and also to send you information regarding our services and events. Your personal data are processed with and without electronic means and by respecting data subjects' rights, fundamental freedoms and dignity, particularly with regard to confidentiality, personal identity and the right to personal data protection. At any time and without formalities you can write an e-mail to privacy@tis.bz.it in order to object the processing of your personal data for the purpose of sending advertising materials and also to exercise the right to access personal data and other rights referred to in Section 7 of Decree 196/2003. The data controller is TIS Techno Innovation Alto Adige, Siemens Street n. 19, Bolzano. You can find the complete information on the web site www.tis.bz.it.
Re: Hangup of fetcher threads
Posted by Julien Nioche <li...@gmail.com>.
Hi
>
> Anyway, from the logs, i see that it ended up trying to parse Thumb.db
> files and some .pyd files which looked to it like plain-text.
> By ignoring .db and .pyd files in craw-urlfilter i managed to get the
> number of hanging threads down to a lower number. This is good to
> understand what's happening but i can't predict all the extensions the
> crawler is going to meet during the filesystem crawl.
>
> my parsing configuration is :
>
>
> <name>plugin.includes</name>
>
> <value>protocol-httpclient|parse-(rss|text|html|tika)|language-identifier|urlfilter-regex|index-(basic|anchor)|response-(json|xml)|summary-basic|scoring-opic|urlnormalizer-(pass|regex|basic)</value>
>
>
> Do you have any suggestions? Should i file an issue?
>
First I'd do the parsing separately from the fetching. If the parsing fails
you can always retry with different params without having to refetch.
I think there are some issues with protocol-httpclient so if you don't need
identification use protocol-http instead.
See https://issues.apache.org/jira/browse/NUTCH-696 - Andrzej has provided a
patch which would be the solution to your problem
Finally if you are able to identify the URLs which are problematic in the
logs try using Tika directly to see whether the problem comes from there
(e.g. parsing loop, wrong identification of mime-type etc...) and if so file
an issue on the Tika JIRA.
HTH
Julien
--
DigitalPebble Ltd
Open Source Solutions for Text Engineering
http://www.digitalpebble.com
Re: Hangup of fetcher threads
Posted by Claudio Martella <cl...@tis.bz.it>.
Hi Julien,
the problem wasn't solved by ignoring flv. (it was solved for flv files,
yes!).
Now i'm having some problems with tika TXT parser. It looks like it's
hanging up there. I usually get about 5 threads hanging with this
stacktrace:
java.lang.Thread.State: RUNNABLE
at java.lang.StringBuffer.append(StringBuffer.java:224)
- locked <0xad1aed40> (a java.lang.StringBuffer)
at org.apache.xerces.dom.CharacterDataImpl.appendData(Unknown Source)
at
org.apache.nutch.parse.tika.DOMBuilder.characters(DOMBuilder.java:405)
at
org.apache.tika.sax.ContentHandlerDecorator.characters(ContentHandlerDecorator.java:124)
at
org.apache.tika.sax.SafeContentHandler.access$001(SafeContentHandler.java:39)
at
org.apache.tika.sax.SafeContentHandler$1.write(SafeContentHandler.java:61)
at
org.apache.tika.sax.SafeContentHandler.writeReplacement(SafeContentHandler.java:143)
at
org.apache.tika.sax.SafeContentHandler.filter(SafeContentHandler.java:105)
at
org.apache.tika.sax.SafeContentHandler.characters(SafeContentHandler.java:151)
at
org.apache.tika.sax.XHTMLContentHandler.characters(XHTMLContentHandler.java:175)
at org.apache.tika.parser.txt.TXTParser.parse(TXTParser.java:144)
at org.apache.nutch.parse.tika.TikaParser.getParse(TikaParser.java:95)
at org.apache.nutch.parse.ParseUtil.parse(ParseUtil.java:82)
at
org.apache.nutch.fetcher.Fetcher$FetcherThread.output(Fetcher.java:878)
at org.apache.nutch.fetcher.Fetcher$FetcherThread.run(Fetcher.java:646)
but could be also
java.lang.Thread.State: RUNNABLE
at org.apache.xerces.dom.CharacterDataImpl.appendData(Unknown Source)
at
org.apache.nutch.parse.tika.DOMBuilder.characters(DOMBuilder.java:405)
at
org.apache.tika.sax.ContentHandlerDecorator.characters(ContentHandlerDecorator.java:124)
at
org.apache.tika.sax.SafeContentHandler.access$001(SafeContentHandler.java:39)
at
org.apache.tika.sax.SafeContentHandler$1.write(SafeContentHandler.java:61)
at
org.apache.tika.sax.SafeContentHandler.filter(SafeContentHandler.java:101)
at
org.apache.tika.sax.SafeContentHandler.characters(SafeContentHandler.java:151)
at
org.apache.tika.sax.XHTMLContentHandler.characters(XHTMLContentHandler.java:175)
at org.apache.tika.parser.txt.TXTParser.parse(TXTParser.java:144)
at org.apache.nutch.parse.tika.TikaParser.getParse(TikaParser.java:95)
at org.apache.nutch.parse.ParseUtil.parse(ParseUtil.java:82)
at
org.apache.nutch.fetcher.Fetcher$FetcherThread.output(Fetcher.java:878)
at org.apache.nutch.fetcher.Fetcher$FetcherThread.run(Fetcher.java:646)
or
java.lang.Thread.State: RUNNABLE
at java.util.Arrays.copyOf(Arrays.java:2882)
at
java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100)
at
java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:390)
at java.lang.StringBuffer.append(StringBuffer.java:224)
- locked <0xb2fec818> (a java.lang.StringBuffer)
at org.apache.xerces.dom.CharacterDataImpl.appendData(Unknown Source)
at
org.apache.nutch.parse.tika.DOMBuilder.characters(DOMBuilder.java:405)
at
org.apache.tika.sax.ContentHandlerDecorator.characters(ContentHandlerDecorator.java:124)
at
org.apache.tika.sax.SafeContentHandler.access$001(SafeContentHandler.java:39)
at
org.apache.tika.sax.SafeContentHandler$1.write(SafeContentHandler.java:61)
at
org.apache.tika.sax.SafeContentHandler.writeReplacement(SafeContentHandler.java:143)
at
org.apache.tika.sax.SafeContentHandler.filter(SafeContentHandler.java:105)
at
org.apache.tika.sax.SafeContentHandler.characters(SafeContentHandler.java:151)
at
org.apache.tika.sax.XHTMLContentHandler.characters(XHTMLContentHandler.java:175)
at org.apache.tika.parser.txt.TXTParser.parse(TXTParser.java:144)
at org.apache.nutch.parse.tika.TikaParser.getParse(TikaParser.java:95)
at org.apache.nutch.parse.ParseUtil.parse(ParseUtil.java:82)
at
org.apache.nutch.fetcher.Fetcher$FetcherThread.output(Fetcher.java:878)
at org.apache.nutch.fetcher.Fetcher$FetcherThread.run(Fetcher.java:646)
basically the threads keeps running parsing the data.
I tried to activate the DEBUG in log4j properties but can't manage to
understand on what exact file the threads is hanging (any suggestion
about that?)
Anyway, from the logs, i see that it ended up trying to parse Thumb.db
files and some .pyd files which looked to it like plain-text.
By ignoring .db and .pyd files in craw-urlfilter i managed to get the
number of hanging threads down to a lower number. This is good to
understand what's happening but i can't predict all the extensions the
crawler is going to meet during the filesystem crawl.
my parsing configuration is :
<name>plugin.includes</name>
<value>protocol-httpclient|parse-(rss|text|html|tika)|language-identifier|urlfilter-regex|index-(basic|anchor)|response-(json|xml)|summary-basic|scoring-opic|urlnormalizer-(pass|regex|basic)</value>
Do you have any suggestions? Should i file an issue?
Julien Nioche wrote:
> Hi Claudio
>
> On 2 July 2010 12:10, Claudio Martella <cl...@tis.bz.it> wrote:
>
>
>> Thanks for the info. i didn't have this problem before nutch 1.1 where
>> my biggest change was the introduction of parse-tika.
>>
>> 4 out of 5 threads are RUNNABLE in this situation:
>>
>> Stack trace:
>> org.apache.tika.parser.video.FLVParser.parse(FLVParser.java:246)
>> org.apache.nutch.parse.tika.TikaParser.getParse(TikaParser.java:95)
>> org.apache.nutch.parse.ParseUtil.parse(ParseUtil.java:82)
>> org.apache.nutch.fetcher.Fetcher$FetcherThread.output(Fetcher.java:878)
>> org.apache.nutch.fetcher.Fetcher$FetcherThread.run(Fetcher.java:646)
>>
>> which is actually pretty weird and difficult to understand for me. after
>> the fetcher aborts with N hung threads, they just stay there hunging. In
>> the jconsole i can still see the same stracktrace of these threads on
>> FLVParser.parse(). They are not downloading (i can see the from the
>> traffic on the network) and they should stop at a certain time (i have
>> content limit at 50MB).
>> Maybe the problem is that FLVParser.parse() doesn't like trunkated
>> content for FLV streams. I'll try to craw-urlfilter-ignore the FLV files.
>>
>>
>
> It is likely to be the source of the problem indeed see
>
> https://issues.apache.org/jira/browse/TIKA-448
>
> I gave a workaround for this issue but adding .flv to the URL filter is
> likely to do the trick
>
>
>
>> Another possiiblity i thought of is that the threads were dead
>> garbage-collecting until hadoop recalls them as dead tasks. That would
>> make sense because that "zombie" situation lasts precisely 5 minutes all
>> the time.
>>
>>
>> does it make sense to you?
>>
>>
>> reinhard schwab wrote:
>>
>>> connect with jconsole to the java vm of nutch and look at the stack
>>> traces of the threads.
>>> you will get more info there.
>>>
>>> Claudio Martella schrieb:
>>>
>>>
>>>> Hello,
>>>>
>>>> I'm using nutch 1.1 (with crawl command) to crawl an intranet document
>>>> archive via webdav. At the end of each fetch phase the fetcher hungs
>>>> like this:
>>>>
>>>> -activeThreads=5, spinWaiting=0, fetchQueues.totalSize=250
>>>>
>>>> from my analysis of network traffic, nothing is passing by. The logs
>>>>
>> show:
>>
>>>> 2010-06-30 13:38:35,335 INFO fetcher.Fetcher - fetching
>>>>
>>>>
>> https://192.168.10.10/data/public/50.90_In_Bearbeitung/Stefano%20P/normen2010/normen2010.indd
>>
>>>> 2010-06-30 13:38:35,381 INFO auth.AuthChallengeProcessor - basic
>>>> authentication scheme selected
>>>> 2010-06-30 13:38:35,819 INFO fetcher.Fetcher - -activeThreads=5,
>>>> spinWaiting=0, fetchQueues.totalSize=249
>>>> 2010-06-30 13:38:36,824 INFO fetcher.Fetcher - -activeThreads=5,
>>>> spinWaiting=0, fetchQueues.totalSize=250
>>>>
>>>> which i guess means i finish downloading the specified file and then it
>>>> hungs until:
>>>>
>>>> 2010-06-30 13:43:35,963 INFO fetcher.Fetcher - -activeThreads=5,
>>>> spinWaiting=0, fetchQueues.totalSize=250
>>>> 2010-06-30 13:43:35,963 WARN fetcher.Fetcher - Aborting with 5 hung
>>>> threads.
>>>>
>>>> so basically 5 minutes without doing anything.
>>>>
>>>> this is my configuration in nutch-site.xml related to fetcher:
>>>>
>>>> <property>
>>>> <name>fetcher.server.delay</name>
>>>> <value>0.0</value>
>>>> </property>
>>>>
>>>> <property>
>>>> <name>fetcher.server.min.delay</name>
>>>> <value>0.0</value>
>>>> </property>
>>>>
>>>> <property>
>>>> <name>fetcher.threads.fetch</name>
>>>> <value>5</value>
>>>> </property>
>>>>
>>>> <property>
>>>> <name>fetcher.threads.per.host</name>
>>>> <value>5</value>
>>>> </property>
>>>>
>>>> <property>
>>>> <name>fetcher.threads.per.host.by.ip</name>
>>>> <value>false</value>
>>>> </property>
>>>>
>>>> Any idea why this is happening?
>>>>
>>>>
>>>> Thanks
>>>>
>>>>
>>>> Claudio
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>> --
>> Claudio Martella
>> Digital Technologies
>> Unit Research & Development - Analyst
>>
>> TIS innovation park
>> Via Siemens 19 | Siemensstr. 19
>> 39100 Bolzano | 39100 Bozen
>> Tel. +39 0471 068 123
>> Fax +39 0471 068 129
>> claudio.martella@tis.bz.it http://www.tis.bz.it
>>
>> Short information regarding use of personal data. According to Section 13
>> of Italian Legislative Decree no. 196 of 30 June 2003, we inform you that we
>> process your personal data in order to fulfil contractual and fiscal
>> obligations and also to send you information regarding our services and
>> events. Your personal data are processed with and without electronic means
>> and by respecting data subjects' rights, fundamental freedoms and dignity,
>> particularly with regard to confidentiality, personal identity and the right
>> to personal data protection. At any time and without formalities you can
>> write an e-mail to privacy@tis.bz.it in order to object the processing of
>> your personal data for the purpose of sending advertising materials and also
>> to exercise the right to access personal data and other rights referred to
>> in Section 7 of Decree 196/2003. The data controller is TIS Techno
>> Innovation Alto Adige, Siemens Street n. 19, Bolzano. You can find the
>> complete information on the web site www.tis.bz.it.
>>
>>
>>
>>
>
>
>
--
Claudio Martella
Digital Technologies
Unit Research & Development - Analyst
TIS innovation park
Via Siemens 19 | Siemensstr. 19
39100 Bolzano | 39100 Bozen
Tel. +39 0471 068 123
Fax +39 0471 068 129
claudio.martella@tis.bz.it http://www.tis.bz.it
Short information regarding use of personal data. According to Section 13 of Italian Legislative Decree no. 196 of 30 June 2003, we inform you that we process your personal data in order to fulfil contractual and fiscal obligations and also to send you information regarding our services and events. Your personal data are processed with and without electronic means and by respecting data subjects' rights, fundamental freedoms and dignity, particularly with regard to confidentiality, personal identity and the right to personal data protection. At any time and without formalities you can write an e-mail to privacy@tis.bz.it in order to object the processing of your personal data for the purpose of sending advertising materials and also to exercise the right to access personal data and other rights referred to in Section 7 of Decree 196/2003. The data controller is TIS Techno Innovation Alto Adige, Siemens Street n. 19, Bolzano. You can find the complete information on the web site www.tis.bz.it.
Re: Hangup of fetcher threads
Posted by Julien Nioche <li...@gmail.com>.
Hi Claudio
On 2 July 2010 12:10, Claudio Martella <cl...@tis.bz.it> wrote:
> Thanks for the info. i didn't have this problem before nutch 1.1 where
> my biggest change was the introduction of parse-tika.
>
> 4 out of 5 threads are RUNNABLE in this situation:
>
> Stack trace:
> org.apache.tika.parser.video.FLVParser.parse(FLVParser.java:246)
> org.apache.nutch.parse.tika.TikaParser.getParse(TikaParser.java:95)
> org.apache.nutch.parse.ParseUtil.parse(ParseUtil.java:82)
> org.apache.nutch.fetcher.Fetcher$FetcherThread.output(Fetcher.java:878)
> org.apache.nutch.fetcher.Fetcher$FetcherThread.run(Fetcher.java:646)
>
> which is actually pretty weird and difficult to understand for me. after
> the fetcher aborts with N hung threads, they just stay there hunging. In
> the jconsole i can still see the same stracktrace of these threads on
> FLVParser.parse(). They are not downloading (i can see the from the
> traffic on the network) and they should stop at a certain time (i have
> content limit at 50MB).
> Maybe the problem is that FLVParser.parse() doesn't like trunkated
> content for FLV streams. I'll try to craw-urlfilter-ignore the FLV files.
>
It is likely to be the source of the problem indeed see
https://issues.apache.org/jira/browse/TIKA-448
I gave a workaround for this issue but adding .flv to the URL filter is
likely to do the trick
>
> Another possiiblity i thought of is that the threads were dead
> garbage-collecting until hadoop recalls them as dead tasks. That would
> make sense because that "zombie" situation lasts precisely 5 minutes all
> the time.
>
>
> does it make sense to you?
>
>
> reinhard schwab wrote:
> > connect with jconsole to the java vm of nutch and look at the stack
> > traces of the threads.
> > you will get more info there.
> >
> > Claudio Martella schrieb:
> >
> >> Hello,
> >>
> >> I'm using nutch 1.1 (with crawl command) to crawl an intranet document
> >> archive via webdav. At the end of each fetch phase the fetcher hungs
> >> like this:
> >>
> >> -activeThreads=5, spinWaiting=0, fetchQueues.totalSize=250
> >>
> >> from my analysis of network traffic, nothing is passing by. The logs
> show:
> >>
> >> 2010-06-30 13:38:35,335 INFO fetcher.Fetcher - fetching
> >>
> https://192.168.10.10/data/public/50.90_In_Bearbeitung/Stefano%20P/normen2010/normen2010.indd
> >> 2010-06-30 13:38:35,381 INFO auth.AuthChallengeProcessor - basic
> >> authentication scheme selected
> >> 2010-06-30 13:38:35,819 INFO fetcher.Fetcher - -activeThreads=5,
> >> spinWaiting=0, fetchQueues.totalSize=249
> >> 2010-06-30 13:38:36,824 INFO fetcher.Fetcher - -activeThreads=5,
> >> spinWaiting=0, fetchQueues.totalSize=250
> >>
> >> which i guess means i finish downloading the specified file and then it
> >> hungs until:
> >>
> >> 2010-06-30 13:43:35,963 INFO fetcher.Fetcher - -activeThreads=5,
> >> spinWaiting=0, fetchQueues.totalSize=250
> >> 2010-06-30 13:43:35,963 WARN fetcher.Fetcher - Aborting with 5 hung
> >> threads.
> >>
> >> so basically 5 minutes without doing anything.
> >>
> >> this is my configuration in nutch-site.xml related to fetcher:
> >>
> >> <property>
> >> <name>fetcher.server.delay</name>
> >> <value>0.0</value>
> >> </property>
> >>
> >> <property>
> >> <name>fetcher.server.min.delay</name>
> >> <value>0.0</value>
> >> </property>
> >>
> >> <property>
> >> <name>fetcher.threads.fetch</name>
> >> <value>5</value>
> >> </property>
> >>
> >> <property>
> >> <name>fetcher.threads.per.host</name>
> >> <value>5</value>
> >> </property>
> >>
> >> <property>
> >> <name>fetcher.threads.per.host.by.ip</name>
> >> <value>false</value>
> >> </property>
> >>
> >> Any idea why this is happening?
> >>
> >>
> >> Thanks
> >>
> >>
> >> Claudio
> >>
> >>
> >>
> >
> >
> >
>
>
> --
> Claudio Martella
> Digital Technologies
> Unit Research & Development - Analyst
>
> TIS innovation park
> Via Siemens 19 | Siemensstr. 19
> 39100 Bolzano | 39100 Bozen
> Tel. +39 0471 068 123
> Fax +39 0471 068 129
> claudio.martella@tis.bz.it http://www.tis.bz.it
>
> Short information regarding use of personal data. According to Section 13
> of Italian Legislative Decree no. 196 of 30 June 2003, we inform you that we
> process your personal data in order to fulfil contractual and fiscal
> obligations and also to send you information regarding our services and
> events. Your personal data are processed with and without electronic means
> and by respecting data subjects' rights, fundamental freedoms and dignity,
> particularly with regard to confidentiality, personal identity and the right
> to personal data protection. At any time and without formalities you can
> write an e-mail to privacy@tis.bz.it in order to object the processing of
> your personal data for the purpose of sending advertising materials and also
> to exercise the right to access personal data and other rights referred to
> in Section 7 of Decree 196/2003. The data controller is TIS Techno
> Innovation Alto Adige, Siemens Street n. 19, Bolzano. You can find the
> complete information on the web site www.tis.bz.it.
>
>
>
--
DigitalPebble Ltd
Open Source Solutions for Text Engineering
http://www.digitalpebble.com
Re: Hangup of fetcher threads
Posted by Claudio Martella <cl...@tis.bz.it>.
Thanks for the info. i didn't have this problem before nutch 1.1 where
my biggest change was the introduction of parse-tika.
4 out of 5 threads are RUNNABLE in this situation:
Stack trace:
org.apache.tika.parser.video.FLVParser.parse(FLVParser.java:246)
org.apache.nutch.parse.tika.TikaParser.getParse(TikaParser.java:95)
org.apache.nutch.parse.ParseUtil.parse(ParseUtil.java:82)
org.apache.nutch.fetcher.Fetcher$FetcherThread.output(Fetcher.java:878)
org.apache.nutch.fetcher.Fetcher$FetcherThread.run(Fetcher.java:646)
which is actually pretty weird and difficult to understand for me. after
the fetcher aborts with N hung threads, they just stay there hunging. In
the jconsole i can still see the same stracktrace of these threads on
FLVParser.parse(). They are not downloading (i can see the from the
traffic on the network) and they should stop at a certain time (i have
content limit at 50MB).
Maybe the problem is that FLVParser.parse() doesn't like trunkated
content for FLV streams. I'll try to craw-urlfilter-ignore the FLV files.
Another possiiblity i thought of is that the threads were dead
garbage-collecting until hadoop recalls them as dead tasks. That would
make sense because that "zombie" situation lasts precisely 5 minutes all
the time.
does it make sense to you?
reinhard schwab wrote:
> connect with jconsole to the java vm of nutch and look at the stack
> traces of the threads.
> you will get more info there.
>
> Claudio Martella schrieb:
>
>> Hello,
>>
>> I'm using nutch 1.1 (with crawl command) to crawl an intranet document
>> archive via webdav. At the end of each fetch phase the fetcher hungs
>> like this:
>>
>> -activeThreads=5, spinWaiting=0, fetchQueues.totalSize=250
>>
>> from my analysis of network traffic, nothing is passing by. The logs show:
>>
>> 2010-06-30 13:38:35,335 INFO fetcher.Fetcher - fetching
>> https://192.168.10.10/data/public/50.90_In_Bearbeitung/Stefano%20P/normen2010/normen2010.indd
>> 2010-06-30 13:38:35,381 INFO auth.AuthChallengeProcessor - basic
>> authentication scheme selected
>> 2010-06-30 13:38:35,819 INFO fetcher.Fetcher - -activeThreads=5,
>> spinWaiting=0, fetchQueues.totalSize=249
>> 2010-06-30 13:38:36,824 INFO fetcher.Fetcher - -activeThreads=5,
>> spinWaiting=0, fetchQueues.totalSize=250
>>
>> which i guess means i finish downloading the specified file and then it
>> hungs until:
>>
>> 2010-06-30 13:43:35,963 INFO fetcher.Fetcher - -activeThreads=5,
>> spinWaiting=0, fetchQueues.totalSize=250
>> 2010-06-30 13:43:35,963 WARN fetcher.Fetcher - Aborting with 5 hung
>> threads.
>>
>> so basically 5 minutes without doing anything.
>>
>> this is my configuration in nutch-site.xml related to fetcher:
>>
>> <property>
>> <name>fetcher.server.delay</name>
>> <value>0.0</value>
>> </property>
>>
>> <property>
>> <name>fetcher.server.min.delay</name>
>> <value>0.0</value>
>> </property>
>>
>> <property>
>> <name>fetcher.threads.fetch</name>
>> <value>5</value>
>> </property>
>>
>> <property>
>> <name>fetcher.threads.per.host</name>
>> <value>5</value>
>> </property>
>>
>> <property>
>> <name>fetcher.threads.per.host.by.ip</name>
>> <value>false</value>
>> </property>
>>
>> Any idea why this is happening?
>>
>>
>> Thanks
>>
>>
>> Claudio
>>
>>
>>
>
>
>
--
Claudio Martella
Digital Technologies
Unit Research & Development - Analyst
TIS innovation park
Via Siemens 19 | Siemensstr. 19
39100 Bolzano | 39100 Bozen
Tel. +39 0471 068 123
Fax +39 0471 068 129
claudio.martella@tis.bz.it http://www.tis.bz.it
Short information regarding use of personal data. According to Section 13 of Italian Legislative Decree no. 196 of 30 June 2003, we inform you that we process your personal data in order to fulfil contractual and fiscal obligations and also to send you information regarding our services and events. Your personal data are processed with and without electronic means and by respecting data subjects' rights, fundamental freedoms and dignity, particularly with regard to confidentiality, personal identity and the right to personal data protection. At any time and without formalities you can write an e-mail to privacy@tis.bz.it in order to object the processing of your personal data for the purpose of sending advertising materials and also to exercise the right to access personal data and other rights referred to in Section 7 of Decree 196/2003. The data controller is TIS Techno Innovation Alto Adige, Siemens Street n. 19, Bolzano. You can find the complete information on the web site www.tis.bz.it.
Re: Hangup of fetcher threads
Posted by reinhard schwab <re...@aon.at>.
connect with jconsole to the java vm of nutch and look at the stack
traces of the threads.
you will get more info there.
Claudio Martella schrieb:
> Hello,
>
> I'm using nutch 1.1 (with crawl command) to crawl an intranet document
> archive via webdav. At the end of each fetch phase the fetcher hungs
> like this:
>
> -activeThreads=5, spinWaiting=0, fetchQueues.totalSize=250
>
> from my analysis of network traffic, nothing is passing by. The logs show:
>
> 2010-06-30 13:38:35,335 INFO fetcher.Fetcher - fetching
> https://192.168.10.10/data/public/50.90_In_Bearbeitung/Stefano%20P/normen2010/normen2010.indd
> 2010-06-30 13:38:35,381 INFO auth.AuthChallengeProcessor - basic
> authentication scheme selected
> 2010-06-30 13:38:35,819 INFO fetcher.Fetcher - -activeThreads=5,
> spinWaiting=0, fetchQueues.totalSize=249
> 2010-06-30 13:38:36,824 INFO fetcher.Fetcher - -activeThreads=5,
> spinWaiting=0, fetchQueues.totalSize=250
>
> which i guess means i finish downloading the specified file and then it
> hungs until:
>
> 2010-06-30 13:43:35,963 INFO fetcher.Fetcher - -activeThreads=5,
> spinWaiting=0, fetchQueues.totalSize=250
> 2010-06-30 13:43:35,963 WARN fetcher.Fetcher - Aborting with 5 hung
> threads.
>
> so basically 5 minutes without doing anything.
>
> this is my configuration in nutch-site.xml related to fetcher:
>
> <property>
> <name>fetcher.server.delay</name>
> <value>0.0</value>
> </property>
>
> <property>
> <name>fetcher.server.min.delay</name>
> <value>0.0</value>
> </property>
>
> <property>
> <name>fetcher.threads.fetch</name>
> <value>5</value>
> </property>
>
> <property>
> <name>fetcher.threads.per.host</name>
> <value>5</value>
> </property>
>
> <property>
> <name>fetcher.threads.per.host.by.ip</name>
> <value>false</value>
> </property>
>
> Any idea why this is happening?
>
>
> Thanks
>
>
> Claudio
>
>