[jira] Created: (NUTCH-551) performance for generate is often really bad

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

[jira] Created: (NUTCH-551) performance for generate is often really bad

JIRA jira@apache.org
performance for generate is often really bad
--------------------------------------------

                 Key: NUTCH-551
                 URL: https://issues.apache.org/jira/browse/NUTCH-551
             Project: Nutch
          Issue Type: Bug
          Components: generator
    Affects Versions: 0.9.0
         Environment: Ubuntu, Core duo 2.4GhZ, 1 gig ram, 750GB hard drive.
 The ethernet connection has a dedicated 1gb connection to the web, so certainly that isn't a problem.
I have tested on nutch 0.9 and the newest daily build from 2007-08-28.

            Reporter: Jim



        Generate often takes many hours to finish (6+), where I would expect it to be done in minutes.

        This behavior has been observed for topN of small (~100) and large (~1000000) values.  Other configuration values are

generate.max.per.host: -1

generate.max.per.host.by.ip: false

        I added debug code to Generator->Selector.map to see when map is called and returns, and observed interesting behavior, described here:

        1. Most of the time, when generate is run urls are processed in chunky batches, usually about 40 at a time, followed by a 1 second delay.  I timed the delay, and it really is a 1 second delay (ie- 30 batches was 30 seconds.)  When this happens it takes hours to complete.

        2. Sometimes (randomly as far as I can tell) when I run nutch, the urls are processed without delays.  It is an all or nothing event, either I run and all urls process quickly without delay (in minutes), or more likely I get the chunky processing with many 1 second delays and the program takes hours to end.  The one exception is....

        3. When the processing runs quickly I've seen the main thread end (I have some profiling going, so I know when a thread ends), and then more likely than not a second thread begins where the first starts, chunky like usual.  Although I sometimes can get fast processing in one thread, it is almost impossible for me te get it in all threads and therefore general processing is very slow (hours).

        4. I tried to put in more debug code to find the line where the delays occured, but the last line printed to the log at a delay seemed random, leading me to believe that the log is not being flushed uniformly.  The timestamps in the log always indicate that the delay is wither right before or after the first log item in the map function.

        5. The profiler I used seemed to imply that about 100% of the time was spent in javallang.Thread.sleep.  I am not completely familiar with the profiler I used so I am not completely sure I inturpreted this correctly.


--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (NUTCH-551) performance for generate is often really bad

JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/NUTCH-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12525882 ]

Jim commented on NUTCH-551:
---------------------------


It is really maddening, but I can not reproduce the bug with the jdb debugger attached.  Whenever I run with jdb generate just finishes immediately (in minutes).  On the bright side I am now certain that there *is* a bug, because I can see from start to finish how long generate should take (minutes as opposed to hours).

Also, I've been watching the map/reduce log progress, and also the output log at the same time and have verified that the chunkyness has something to do with the slowdown.  The logs show a progression of the map in a steady fashion until the logs start pausing every second for a second.  Then the percentage only goes very slowly.



> performance for generate is often really bad
> --------------------------------------------
>
>                 Key: NUTCH-551
>                 URL: https://issues.apache.org/jira/browse/NUTCH-551
>             Project: Nutch
>          Issue Type: Bug
>          Components: generator
>    Affects Versions: 0.9.0
>         Environment: Ubuntu, Core duo 2.4GhZ, 1 gig ram, 750GB hard drive.
>  The ethernet connection has a dedicated 1gb connection to the web, so certainly that isn't a problem.
> I have tested on nutch 0.9 and the newest daily build from 2007-08-28.
>            Reporter: Jim
>
>         Generate often takes many hours to finish (6+), where I would expect it to be done in minutes.
>         This behavior has been observed for topN of small (~100) and large (~1000000) values.  Other configuration values are
> generate.max.per.host: -1
> generate.max.per.host.by.ip: false
>         I added debug code to Generator->Selector.map to see when map is called and returns, and observed interesting behavior, described here:
>         1. Most of the time, when generate is run urls are processed in chunky batches, usually about 40 at a time, followed by a 1 second delay.  I timed the delay, and it really is a 1 second delay (ie- 30 batches was 30 seconds.)  When this happens it takes hours to complete.
>         2. Sometimes (randomly as far as I can tell) when I run nutch, the urls are processed without delays.  It is an all or nothing event, either I run and all urls process quickly without delay (in minutes), or more likely I get the chunky processing with many 1 second delays and the program takes hours to end.  The one exception is....
>         3. When the processing runs quickly I've seen the main thread end (I have some profiling going, so I know when a thread ends), and then more likely than not a second thread begins where the first starts, chunky like usual.  Although I sometimes can get fast processing in one thread, it is almost impossible for me te get it in all threads and therefore general processing is very slow (hours).
>         4. I tried to put in more debug code to find the line where the delays occured, but the last line printed to the log at a delay seemed random, leading me to believe that the log is not being flushed uniformly.  The timestamps in the log always indicate that the delay is wither right before or after the first log item in the map function.
>         5. The profiler I used seemed to imply that about 100% of the time was spent in javallang.Thread.sleep.  I am not completely familiar with the profiler I used so I am not completely sure I inturpreted this correctly.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (NUTCH-551) performance for generate is often really bad

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/NUTCH-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526247 ]

Doğacan Güney commented on NUTCH-551:
-------------------------------------

Thank you for the detailed analysis of the problem. This is indeed very weird, but I was wondering something. Do you run into this problem even if you don't pass "-topN" option?

> performance for generate is often really bad
> --------------------------------------------
>
>                 Key: NUTCH-551
>                 URL: https://issues.apache.org/jira/browse/NUTCH-551
>             Project: Nutch
>          Issue Type: Bug
>          Components: generator
>    Affects Versions: 0.9.0
>         Environment: Ubuntu, Core duo 2.4GhZ, 1 gig ram, 750GB hard drive.
>  The ethernet connection has a dedicated 1gb connection to the web, so certainly that isn't a problem.
> I have tested on nutch 0.9 and the newest daily build from 2007-08-28.
>            Reporter: Jim
>
>         Generate often takes many hours to finish (6+), where I would expect it to be done in minutes.
>         This behavior has been observed for topN of small (~100) and large (~1000000) values.  Other configuration values are
> generate.max.per.host: -1
> generate.max.per.host.by.ip: false
>         I added debug code to Generator->Selector.map to see when map is called and returns, and observed interesting behavior, described here:
>         1. Most of the time, when generate is run urls are processed in chunky batches, usually about 40 at a time, followed by a 1 second delay.  I timed the delay, and it really is a 1 second delay (ie- 30 batches was 30 seconds.)  When this happens it takes hours to complete.
>         2. Sometimes (randomly as far as I can tell) when I run nutch, the urls are processed without delays.  It is an all or nothing event, either I run and all urls process quickly without delay (in minutes), or more likely I get the chunky processing with many 1 second delays and the program takes hours to end.  The one exception is....
>         3. When the processing runs quickly I've seen the main thread end (I have some profiling going, so I know when a thread ends), and then more likely than not a second thread begins where the first starts, chunky like usual.  Although I sometimes can get fast processing in one thread, it is almost impossible for me te get it in all threads and therefore general processing is very slow (hours).
>         4. I tried to put in more debug code to find the line where the delays occured, but the last line printed to the log at a delay seemed random, leading me to believe that the log is not being flushed uniformly.  The timestamps in the log always indicate that the delay is wither right before or after the first log item in the map function.
>         5. The profiler I used seemed to imply that about 100% of the time was spent in javallang.Thread.sleep.  I am not completely familiar with the profiler I used so I am not completely sure I inturpreted this correctly.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (NUTCH-551) performance for generate is often really bad

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/NUTCH-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526328 ]

Jim commented on NUTCH-551:
---------------------------

In the madness that is this bug, I can not even reproduct the problem today (generate is always fast, no matter what I do).  Once I figure out what to do to get the bug again, I will test without topN and get back to you.


> performance for generate is often really bad
> --------------------------------------------
>
>                 Key: NUTCH-551
>                 URL: https://issues.apache.org/jira/browse/NUTCH-551
>             Project: Nutch
>          Issue Type: Bug
>          Components: generator
>    Affects Versions: 0.9.0
>         Environment: Ubuntu, Core duo 2.4GhZ, 1 gig ram, 750GB hard drive.
>  The ethernet connection has a dedicated 1gb connection to the web, so certainly that isn't a problem.
> I have tested on nutch 0.9 and the newest daily build from 2007-08-28.
>            Reporter: Jim
>
>         Generate often takes many hours to finish (6+), where I would expect it to be done in minutes.
>         This behavior has been observed for topN of small (~100) and large (~1000000) values.  Other configuration values are
> generate.max.per.host: -1
> generate.max.per.host.by.ip: false
>         I added debug code to Generator->Selector.map to see when map is called and returns, and observed interesting behavior, described here:
>         1. Most of the time, when generate is run urls are processed in chunky batches, usually about 40 at a time, followed by a 1 second delay.  I timed the delay, and it really is a 1 second delay (ie- 30 batches was 30 seconds.)  When this happens it takes hours to complete.
>         2. Sometimes (randomly as far as I can tell) when I run nutch, the urls are processed without delays.  It is an all or nothing event, either I run and all urls process quickly without delay (in minutes), or more likely I get the chunky processing with many 1 second delays and the program takes hours to end.  The one exception is....
>         3. When the processing runs quickly I've seen the main thread end (I have some profiling going, so I know when a thread ends), and then more likely than not a second thread begins where the first starts, chunky like usual.  Although I sometimes can get fast processing in one thread, it is almost impossible for me te get it in all threads and therefore general processing is very slow (hours).
>         4. I tried to put in more debug code to find the line where the delays occured, but the last line printed to the log at a delay seemed random, leading me to believe that the log is not being flushed uniformly.  The timestamps in the log always indicate that the delay is wither right before or after the first log item in the map function.
>         5. The profiler I used seemed to imply that about 100% of the time was spent in javallang.Thread.sleep.  I am not completely familiar with the profiler I used so I am not completely sure I inturpreted this correctly.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (NUTCH-551) performance for generate is often really bad

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/NUTCH-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526620 ]

Jim commented on NUTCH-551:
---------------------------

Just to reaffirm, it is a day later and I can no longer reproduce this bug.  I don't know what is different, in fact I copied my crawldb earlier when the bug was happening all the time and a diff now shows them to be the same.

A few days ago I could not ever run generate without this problem occurring (almost never), and now whatever I do I can not get it to happen.  I will keep my eyes on this issue, and let you know if anything changes.


> performance for generate is often really bad
> --------------------------------------------
>
>                 Key: NUTCH-551
>                 URL: https://issues.apache.org/jira/browse/NUTCH-551
>             Project: Nutch
>          Issue Type: Bug
>          Components: generator
>    Affects Versions: 0.9.0
>         Environment: Ubuntu, Core duo 2.4GhZ, 1 gig ram, 750GB hard drive.
>  The ethernet connection has a dedicated 1gb connection to the web, so certainly that isn't a problem.
> I have tested on nutch 0.9 and the newest daily build from 2007-08-28.
>            Reporter: Jim
>
>         Generate often takes many hours to finish (6+), where I would expect it to be done in minutes.
>         This behavior has been observed for topN of small (~100) and large (~1000000) values.  Other configuration values are
> generate.max.per.host: -1
> generate.max.per.host.by.ip: false
>         I added debug code to Generator->Selector.map to see when map is called and returns, and observed interesting behavior, described here:
>         1. Most of the time, when generate is run urls are processed in chunky batches, usually about 40 at a time, followed by a 1 second delay.  I timed the delay, and it really is a 1 second delay (ie- 30 batches was 30 seconds.)  When this happens it takes hours to complete.
>         2. Sometimes (randomly as far as I can tell) when I run nutch, the urls are processed without delays.  It is an all or nothing event, either I run and all urls process quickly without delay (in minutes), or more likely I get the chunky processing with many 1 second delays and the program takes hours to end.  The one exception is....
>         3. When the processing runs quickly I've seen the main thread end (I have some profiling going, so I know when a thread ends), and then more likely than not a second thread begins where the first starts, chunky like usual.  Although I sometimes can get fast processing in one thread, it is almost impossible for me te get it in all threads and therefore general processing is very slow (hours).
>         4. I tried to put in more debug code to find the line where the delays occured, but the last line printed to the log at a delay seemed random, leading me to believe that the log is not being flushed uniformly.  The timestamps in the log always indicate that the delay is wither right before or after the first log item in the map function.
>         5. The profiler I used seemed to imply that about 100% of the time was spent in javallang.Thread.sleep.  I am not completely familiar with the profiler I used so I am not completely sure I inturpreted this correctly.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (NUTCH-551) performance for generate is often really bad

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/NUTCH-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12526685 ]

Doğacan Güney commented on NUTCH-551:
-------------------------------------

Perhaps, it is a low-memory problem? Did you get a chance to check generator's memory usage (both when slow and fast)?

> performance for generate is often really bad
> --------------------------------------------
>
>                 Key: NUTCH-551
>                 URL: https://issues.apache.org/jira/browse/NUTCH-551
>             Project: Nutch
>          Issue Type: Bug
>          Components: generator
>    Affects Versions: 0.9.0
>         Environment: Ubuntu, Core duo 2.4GhZ, 1 gig ram, 750GB hard drive.
>  The ethernet connection has a dedicated 1gb connection to the web, so certainly that isn't a problem.
> I have tested on nutch 0.9 and the newest daily build from 2007-08-28.
>            Reporter: Jim
>
>         Generate often takes many hours to finish (6+), where I would expect it to be done in minutes.
>         This behavior has been observed for topN of small (~100) and large (~1000000) values.  Other configuration values are
> generate.max.per.host: -1
> generate.max.per.host.by.ip: false
>         I added debug code to Generator->Selector.map to see when map is called and returns, and observed interesting behavior, described here:
>         1. Most of the time, when generate is run urls are processed in chunky batches, usually about 40 at a time, followed by a 1 second delay.  I timed the delay, and it really is a 1 second delay (ie- 30 batches was 30 seconds.)  When this happens it takes hours to complete.
>         2. Sometimes (randomly as far as I can tell) when I run nutch, the urls are processed without delays.  It is an all or nothing event, either I run and all urls process quickly without delay (in minutes), or more likely I get the chunky processing with many 1 second delays and the program takes hours to end.  The one exception is....
>         3. When the processing runs quickly I've seen the main thread end (I have some profiling going, so I know when a thread ends), and then more likely than not a second thread begins where the first starts, chunky like usual.  Although I sometimes can get fast processing in one thread, it is almost impossible for me te get it in all threads and therefore general processing is very slow (hours).
>         4. I tried to put in more debug code to find the line where the delays occured, but the last line printed to the log at a delay seemed random, leading me to believe that the log is not being flushed uniformly.  The timestamps in the log always indicate that the delay is wither right before or after the first log item in the map function.
>         5. The profiler I used seemed to imply that about 100% of the time was spent in javallang.Thread.sleep.  I am not completely familiar with the profiler I used so I am not completely sure I inturpreted this correctly.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (NUTCH-551) performance for generate is often really bad

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/NUTCH-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527620 ]

Jim commented on NUTCH-551:
---------------------------


Just to update, it has been a few days and the performance issue seems to really be gone, like someone turned off a lightswitch.  This makes me unhappy, since I wanted to squash this thing once and for all.

I doubt that it was a memory issue (but can not say with certainty that it was not) because this is a dedicated crawler server, nothing else was running on it (it has 1 gig).  Often the bug showed up as soon as I started generate, so it would have had to have used up all of memory quickly.  Also, I saw the problem kick in suddenly when one thread ended and another began.  I will check if the bug comes up again however.

If I see the problem again, I will add a comment here.


> performance for generate is often really bad
> --------------------------------------------
>
>                 Key: NUTCH-551
>                 URL: https://issues.apache.org/jira/browse/NUTCH-551
>             Project: Nutch
>          Issue Type: Bug
>          Components: generator
>    Affects Versions: 0.9.0
>         Environment: Ubuntu, Core duo 2.4GhZ, 1 gig ram, 750GB hard drive.
>  The ethernet connection has a dedicated 1gb connection to the web, so certainly that isn't a problem.
> I have tested on nutch 0.9 and the newest daily build from 2007-08-28.
>            Reporter: Jim
>
>         Generate often takes many hours to finish (6+), where I would expect it to be done in minutes.
>         This behavior has been observed for topN of small (~100) and large (~1000000) values.  Other configuration values are
> generate.max.per.host: -1
> generate.max.per.host.by.ip: false
>         I added debug code to Generator->Selector.map to see when map is called and returns, and observed interesting behavior, described here:
>         1. Most of the time, when generate is run urls are processed in chunky batches, usually about 40 at a time, followed by a 1 second delay.  I timed the delay, and it really is a 1 second delay (ie- 30 batches was 30 seconds.)  When this happens it takes hours to complete.
>         2. Sometimes (randomly as far as I can tell) when I run nutch, the urls are processed without delays.  It is an all or nothing event, either I run and all urls process quickly without delay (in minutes), or more likely I get the chunky processing with many 1 second delays and the program takes hours to end.  The one exception is....
>         3. When the processing runs quickly I've seen the main thread end (I have some profiling going, so I know when a thread ends), and then more likely than not a second thread begins where the first starts, chunky like usual.  Although I sometimes can get fast processing in one thread, it is almost impossible for me te get it in all threads and therefore general processing is very slow (hours).
>         4. I tried to put in more debug code to find the line where the delays occured, but the last line printed to the log at a delay seemed random, leading me to believe that the log is not being flushed uniformly.  The timestamps in the log always indicate that the delay is wither right before or after the first log item in the map function.
>         5. The profiler I used seemed to imply that about 100% of the time was spent in javallang.Thread.sleep.  I am not completely familiar with the profiler I used so I am not completely sure I inturpreted this correctly.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Closed: (NUTCH-551) performance for generate is often really bad

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

     [ https://issues.apache.org/jira/browse/NUTCH-551?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andrzej Bialecki  closed NUTCH-551.
-----------------------------------

    Resolution: Cannot Reproduce

> performance for generate is often really bad
> --------------------------------------------
>
>                 Key: NUTCH-551
>                 URL: https://issues.apache.org/jira/browse/NUTCH-551
>             Project: Nutch
>          Issue Type: Bug
>          Components: generator
>    Affects Versions: 0.9.0
>         Environment: Ubuntu, Core duo 2.4GhZ, 1 gig ram, 750GB hard drive.
>  The ethernet connection has a dedicated 1gb connection to the web, so certainly that isn't a problem.
> I have tested on nutch 0.9 and the newest daily build from 2007-08-28.
>            Reporter: Jim
>
>         Generate often takes many hours to finish (6+), where I would expect it to be done in minutes.
>         This behavior has been observed for topN of small (~100) and large (~1000000) values.  Other configuration values are
> generate.max.per.host: -1
> generate.max.per.host.by.ip: false
>         I added debug code to Generator->Selector.map to see when map is called and returns, and observed interesting behavior, described here:
>         1. Most of the time, when generate is run urls are processed in chunky batches, usually about 40 at a time, followed by a 1 second delay.  I timed the delay, and it really is a 1 second delay (ie- 30 batches was 30 seconds.)  When this happens it takes hours to complete.
>         2. Sometimes (randomly as far as I can tell) when I run nutch, the urls are processed without delays.  It is an all or nothing event, either I run and all urls process quickly without delay (in minutes), or more likely I get the chunky processing with many 1 second delays and the program takes hours to end.  The one exception is....
>         3. When the processing runs quickly I've seen the main thread end (I have some profiling going, so I know when a thread ends), and then more likely than not a second thread begins where the first starts, chunky like usual.  Although I sometimes can get fast processing in one thread, it is almost impossible for me te get it in all threads and therefore general processing is very slow (hours).
>         4. I tried to put in more debug code to find the line where the delays occured, but the last line printed to the log at a delay seemed random, leading me to believe that the log is not being flushed uniformly.  The timestamps in the log always indicate that the delay is wither right before or after the first log item in the map function.
>         5. The profiler I used seemed to imply that about 100% of the time was spent in javallang.Thread.sleep.  I am not completely familiar with the profiler I used so I am not completely sure I inturpreted this correctly.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply | Threaded
Open this post in threaded view
|

[jira] Commented: (NUTCH-551) performance for generate is often really bad

JIRA jira@apache.org
In reply to this post by JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/NUTCH-551?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566185#action_12566185 ]

Andrzej Bialecki  commented on NUTCH-551:
-----------------------------------------

No further information on this isue, so closing it.

> performance for generate is often really bad
> --------------------------------------------
>
>                 Key: NUTCH-551
>                 URL: https://issues.apache.org/jira/browse/NUTCH-551
>             Project: Nutch
>          Issue Type: Bug
>          Components: generator
>    Affects Versions: 0.9.0
>         Environment: Ubuntu, Core duo 2.4GhZ, 1 gig ram, 750GB hard drive.
>  The ethernet connection has a dedicated 1gb connection to the web, so certainly that isn't a problem.
> I have tested on nutch 0.9 and the newest daily build from 2007-08-28.
>            Reporter: Jim
>
>         Generate often takes many hours to finish (6+), where I would expect it to be done in minutes.
>         This behavior has been observed for topN of small (~100) and large (~1000000) values.  Other configuration values are
> generate.max.per.host: -1
> generate.max.per.host.by.ip: false
>         I added debug code to Generator->Selector.map to see when map is called and returns, and observed interesting behavior, described here:
>         1. Most of the time, when generate is run urls are processed in chunky batches, usually about 40 at a time, followed by a 1 second delay.  I timed the delay, and it really is a 1 second delay (ie- 30 batches was 30 seconds.)  When this happens it takes hours to complete.
>         2. Sometimes (randomly as far as I can tell) when I run nutch, the urls are processed without delays.  It is an all or nothing event, either I run and all urls process quickly without delay (in minutes), or more likely I get the chunky processing with many 1 second delays and the program takes hours to end.  The one exception is....
>         3. When the processing runs quickly I've seen the main thread end (I have some profiling going, so I know when a thread ends), and then more likely than not a second thread begins where the first starts, chunky like usual.  Although I sometimes can get fast processing in one thread, it is almost impossible for me te get it in all threads and therefore general processing is very slow (hours).
>         4. I tried to put in more debug code to find the line where the delays occured, but the last line printed to the log at a delay seemed random, leading me to believe that the log is not being flushed uniformly.  The timestamps in the log always indicate that the delay is wither right before or after the first log item in the map function.
>         5. The profiler I used seemed to imply that about 100% of the time was spent in javallang.Thread.sleep.  I am not completely familiar with the profiler I used so I am not completely sure I inturpreted this correctly.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.