-
Notifications
You must be signed in to change notification settings - Fork 137
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.
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
Perform a VM-wide thread stack trace dump on USR2 #263
Perform a VM-wide thread stack trace dump on USR2 #263
Conversation
|
||
sig = sig_read.gets.strip.downcase | ||
if USER_SIGNALS.include?(sig.upcase) | ||
logger.info "FUN TIME! #{sig}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I appreciate the humour but perhaps we should make this log message a bit more descriptive :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I should have written "This is a handler for signal SIGUSR1, the behavior of which we will define as a community".
The current implementation is only a skeleton logging "proof" that it works.
Some common signals are If you don't have any specific ideas about what Hutch would do when sent a |
It might be useful to allow pausing/resuming of the consumers. I see that Bunny could support pausing the work pool, but I didn't see anything in March Hare after a 2 minute glance. |
The only way to pause a consumer is to stop deliveries to it by tweaking QoS prefetch. Otherwise you will run out of memory quickly. This sounds like a dangerous, hard to get right idea to me. |
Ah okay sorry, I was looking at Bunny's edit Looking closer I now see that things would still be pushed on to the queue, they just wouldn't be processed. |
- to have a user-facing feature signal, we pick one that can be used on JVM
dbc1efd
to
4611615
Compare
I rebased. |
So |
end | ||
|
||
private | ||
|
||
def handle_usr2 | ||
Thread.list.each do |thread| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest that we log a header such as "requested a VM-wide thread stack trace dump…"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed!
end | ||
|
||
private | ||
|
||
def handle_usr2 | ||
Thread.list.each do |thread| | ||
logger.warn "Thread TID-#{thread.object_id.to_s(36)} #{thread['label']}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why warn
and not info
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should be info
!
This is a PR inspired by another project which had a neat section of signals to send to the worker, to have to do things, like "shed current work item, never to requeue it" or "print a debug backtrace".
Inspiration
Questions
Proposed changes