Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Shutting down the Disruptor with pending events in the buffer causes high CPU usage #566

Closed
brenuart opened this issue Jul 9, 2021 · 0 comments · Fixed by #565
Closed

Shutting down the Disruptor with pending events in the buffer causes high CPU usage #566

brenuart opened this issue Jul 9, 2021 · 0 comments · Fixed by #565
Milestone
7.0

Comments

@brenuart
Copy link
Collaborator

brenuart commented Jul 9, 2021

Calling Disruptor#shutdown() waits until all enqueued events are processed by all registered processors. This happens in a busy spin which causes a high CPU load (see https://github.com/LMAX-Exchange/disruptor/blob/3.4.4/src/main/java/com/lmax/disruptor/dsl/Disruptor.java#L451-L463).

Instead the AsyncDisruptorAppender should implement its own graceful shutdown of the Disruptor with its own wait strategy then ask for an immediate shutdown of the Disruptor when the grace period is over.
brenuart added a commit to brenuart/logstash-logback-encoder that referenced this issue Jul 10, 2021
@brenuart
Wait for the buffer to drain before calling Disruptor#shutdown
d80f1e9 
Calling Disruptor#shutdown(timeout) while the buffer is not empty causes the disruptor to wait in a busy-loop consommuing a lot of CPU. Instead, wait during the grace period before asking the disruptor to shutdown immediately.

Related issue: logfellow#566
brenuart added a commit to brenuart/logstash-logback-encoder that referenced this issue Jul 10, 2021
@brenuart
Wait for the buffer to drain before calling Disruptor#shutdown
0010ef4 
Calling Disruptor#shutdown(timeout) while the buffer is not empty causes the disruptor to wait in a busy-loop consommuing a lot of CPU. Instead, wait during the grace period before asking the disruptor to shutdown immediately.

Related issue: logfellow#566
brenuart added a commit to brenuart/logstash-logback-encoder that referenced this issue Jul 10, 2021
@brenuart
Wait for the buffer to drain before calling Disruptor#shutdown
f15373d 
Calling Disruptor#shutdown(timeout) while the buffer is not empty causes the disruptor to wait in a busy-loop consommuing a lot of CPU. Instead, wait during the grace period before asking the disruptor to shutdown immediately.

Related issue: logfellow#566
brenuart added a commit to brenuart/logstash-logback-encoder that referenced this issue Jul 10, 2021
@brenuart
Wait for the buffer to drain before calling Disruptor#shutdown
64901f5 
Calling Disruptor#shutdown(timeout) while the buffer is not empty causes the disruptor to wait in a busy-loop consommuing a lot of CPU. Instead, wait during the grace period before asking the disruptor to shutdown immediately.

Related issue: logfellow#566
brenuart added a commit to brenuart/logstash-logback-encoder that referenced this issue Jul 10, 2021
@brenuart
Wait for the buffer to drain before calling Disruptor#shutdown
c3db6af 
Calling Disruptor#shutdown(timeout) while the buffer is not empty causes the disruptor to wait in a busy-loop consommuing a lot of CPU. Instead, wait during the grace period before asking the disruptor to shutdown immediately.

Related issue: logfellow#566
@philsttr philsttr mentioned this issue Jul 10, 2021
Merged
@brenuart brenuart added this to the 7.0 milestone Jul 14, 2021
@philsttr philsttr linked a pull request Jul 14, 2021 that will close this issue
Async append blocking with timeout #565
Merged
philsttr pushed a commit that referenced this issue Jul 14, 2021
@brenuart
First implementation of Async append blocking until an optional timeo…
c7d9781 
…ut (#565)

* Add ability block with optional timeout when appending to async appenders
* Wait for the buffer to drain before calling Disruptor#shutdown

Calling Disruptor#shutdown(timeout) while the buffer is not empty causes the disruptor to wait in a busy-loop consumuing a lot of CPU. Instead, wait during the grace period before asking the disruptor to shutdown immediately.

Fixes #559 
Fixes #566 
Fixes #569
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
7.0
Development

Successfully merging a pull request may close this issue.

Async append blocking with timeout brenuart/logstash-logback-encoder
1 participant
@brenuart