[GH-ISSUE #182] Timeout issues #178

New issue

Closed

opened 2026-02-27 15:55:30 +03:00 by kerem · 5 comments

kerem commented

2026-02-27 15:55:30 +03:00

Owner

Originally created by @TomKirby on GitHub (Aug 15, 2018).
Original GitHub issue: https://github.com/RD17/ambar/issues/182

Hi,

I am seeing a lot of timeout issues in the logs, which seems to be delaying the pipeline by 30 seconds each time preventing it from reducing my queue by a considerable amount.

2018-08-15 10:25:18.481: [webapi] [error] Request Timeout after 30000ms Error: Request Timeout after 30000ms at /node_modules/elasticsearch/src/lib/transport.js:336:15 at Timeout.<anonymous> (/node_modules/elasticsearch/src/lib/transport.js:365:7) at ontimeout (timers.js:482:11) at tryOnTimeout (timers.js:317:5) at Timer.listOnTimeout (timers.js:277:5)

2018-08-15 10:25:18.483: [pipeline] [error] [0] error processing task UnboundLocalError("local variable 'fileMeta' referenced before assignment",)

Any feedback on what might be causing this?

Originally created by @TomKirby on GitHub (Aug 15, 2018). Original GitHub issue: https://github.com/RD17/ambar/issues/182 Hi, I am seeing a lot of timeout issues in the logs, which seems to be delaying the pipeline by 30 seconds each time preventing it from reducing my queue by a considerable amount. ``` 2018-08-15 10:25:18.481: [webapi] [error] Request Timeout after 30000ms Error: Request Timeout after 30000ms at /node_modules/elasticsearch/src/lib/transport.js:336:15 at Timeout.<anonymous> (/node_modules/elasticsearch/src/lib/transport.js:365:7) at ontimeout (timers.js:482:11) at tryOnTimeout (timers.js:317:5) at Timer.listOnTimeout (timers.js:277:5) 2018-08-15 10:25:18.483: [pipeline] [error] [0] error processing task UnboundLocalError("local variable 'fileMeta' referenced before assignment",) ``` Any feedback on what might be causing this?

kerem

2026-02-27 15:55:30 +03:00

closed this issue
added the
wontfix
label

kerem commented

2026-02-27 15:55:30 +03:00

Author

Owner

@sochix commented on GitHub (Aug 15, 2018):

On what hardware running your Ambar instance?

@sochix commented on GitHub (Aug 15, 2018): On what hardware running your Ambar instance?

kerem commented

2026-02-27 15:55:31 +03:00

Author

Owner

@TomKirby commented on GitHub (Aug 16, 2018):

virtual machine, 2 cores, 6GB of ram.... I have requested out Operations team to increase to 18GB to see if that will resolve the issue.

@TomKirby commented on GitHub (Aug 16, 2018): virtual machine, 2 cores, 6GB of ram.... I have requested out Operations team to increase to 18GB to see if that will resolve the issue.

kerem commented

2026-02-27 15:55:31 +03:00

Author

Owner

@sochix commented on GitHub (Aug 16, 2018):

Play with size of ES heap, it should help

@sochix commented on GitHub (Aug 16, 2018): Play with size of ES heap, it should help

kerem commented

2026-02-27 15:55:31 +03:00

Author

Owner

@steve-boyle commented on GitHub (Aug 25, 2018):

I'm running Ambar in a VM with 4 cores and 32GB of ram. I was also seeing timeouts like this, I found that I was seeing various types of out of memory (OOM) conditions, in the applications and in the operating system. I had played with the heap size, that helped but did not eliminate the problem and after a few hours of runtime I would start to see long GCs. I lowered the maxFileSize on my crawlers to 100mb. It seems that the default of 300mb was too much for my system. At a 100mb maxFileSize the system is running smoothly without any crashes.

@steve-boyle commented on GitHub (Aug 25, 2018): I'm running Ambar in a VM with 4 cores and 32GB of ram. I was also seeing timeouts like this, I found that I was seeing various types of out of memory (OOM) conditions, in the applications and in the operating system. I had played with the heap size, that helped but did not eliminate the problem and after a few hours of runtime I would start to see long GCs. I lowered the maxFileSize on my crawlers to 100mb. It seems that the default of 300mb was too much for my system. At a 100mb maxFileSize the system is running smoothly without any crashes.

kerem commented

2026-02-27 15:55:31 +03:00

Author

Owner

@stale[bot] commented on GitHub (Sep 10, 2018):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale[bot] commented on GitHub (Sep 10, 2018): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.