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.

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

in_monitor_agent: get_monitor_info: fix NoMethodError #1365

Merged
merged 1 commit into from
Jan 4, 2017
Merged

in_monitor_agent: get_monitor_info: fix NoMethodError #1365

merged 1 commit into from
Jan 4, 2017

Conversation

shuji-koike
Copy link
Contributor

@shuji-koike shuji-koike commented Dec 12, 2016

NoMethodError when using in_monitor_agent with out_null plugin #1364

This is my fix for #1364.


I thought it may be better to add a resuce e: NoMethodError around here -> https://github.com/shuji-koike/fluentd/blob/be7ffb2/lib/fluent/plugin/in_monitor_agent.rb#L344-L346
If so, I will fix my commit.

@tagomoris
Copy link
Member

Code looks good to me.
Adding rescue NoMethodError is good idea. That should have log.error_backtrace to show where the bug is clearly.

@tagomoris tagomoris added bug Something isn't working v0.14 labels Dec 13, 2016
@repeatedly
Copy link
Member

Good catch :)
And additional commits are welcome.

@shuji-koike
Copy link
Contributor Author

shuji-koike commented Dec 13, 2016

@tagomoris san

Adding rescue NoMethodError with log.error_backtrace would rather increase logs.
I may want to reduce (suppress) logs for this occasion, because @buffer may be nil in some plugins and (I believe) it is not a bug or an error.

So, may I leave my fix as is?

@tagomoris
Copy link
Member

@shuji-koike it makes sense. But it's worth to provide information to make it easy to debug such problems.
So, how about to show warnings at the only first time of rescue such exception? It's a kind of a bit messy code, but it satisfies requirements both of users and developers.

# initialize @first_warn = false # in #initialize
 rescue => e
  log.error # brabrabra
  if !@first_warn
    @first_warn = true
    log.error_stacktrace
  end

@shuji-koike
Copy link
Contributor Author

@tagomoris san

I've updated my fix -> b38a791

I didn't notice there was a similar issue -> #1335, sorry!

@tagomoris
Copy link
Member

Hmm, This fix still have some problems:

  • Including the whole logging in unless @first_warn makes that it warns NoMethodError only once (maybe just after Fluentd startup)
  • Users may miss just only one warning... we should warn it everytime (without backtrace)
  • this patch uses warn about NoMethodError itself, but uses error_backtrace (it shows backtrace in ERROR level)

We should show error level log everytime (out of unless @first_warn clause), and use error_backtrace in unless @first_warn.

@tagomoris
Copy link
Member

@shuji-koike ping?

@shuji-koike
Copy link
Contributor Author

@tagomoris san
Sorry for my late reply, and a Happy New Year!
I updated my fix -> 625752c
Since fluentd will suppress duplicate stacktraces, I removed the @first_warn flag.

@shuji-koike
Copy link
Contributor Author

shuji-koike commented Jan 4, 2017

I would have to say that I am not really convinced with this fix.

I understand that logging is important.
But users have nothing to do with this error.

I think the real problem is...

In 0.12.x, @buffer is defined only in BufferedOutput plugins.
https://github.com/shuji-koike/fluentd/blob/v0.12.30/lib/fluent/output.rb#L213

in_monitor_agent checks whether @buffer is defined to avoid (suppress) errors.
https://github.com/shuji-koike/fluentd/blob/v0.14.9/lib/fluent/plugin/in_monitor_agent.rb#L253-L254

In 0.14.x, @buffer will be defined in all Output plugins.
https://github.com/shuji-koike/fluentd/blob/v0.14.9/lib/fluent/plugin/output.rb#L185

Therefore, checking instance_variable_defined?(:@buffer) may have become pointless.

I removed the @buffer.nil? check from my fix (when I added the rescue clause), but may I put them back?

@tagomoris
Copy link
Member

"suppress repeated stacktrace" option will suppress the stacktraces which is just equal to the previous one. If any error occurs in other place of code, the same stacktrace will be shown in log.
Otherwise, "suppressed same stacktrace" log messages are shown always. It looks a bit messy for me.
So, IMO it's better not to call log.error_backtrace twice and more.

@tagomoris
Copy link
Member

Basically, checking @buffer.nil? is good idea, in addition to instance_variable_defined?(:@buffer), because there are still some plugins without @buffer instance variables (in match sections), like Fluent::Plugin::BareOutput.
But it's not the main issue about this pull-request.

This pull-request is to show where the NoMethodError occurs and where the bug hits. This requires stacktrace for further investigation, so we need to handle NoMethodError in special way.

@shuji-koike
Copy link
Contributor Author

@tagomoris san

Thanks for your advice 😸
I added nil? check "in addition to instance_variable_defined", and brought back the @first_warn flag. -> 919ebb2

@tagomoris
Copy link
Member

LGTM

@tagomoris tagomoris merged commit c121222 into fluent:master Jan 4, 2017
@tagomoris
Copy link
Member

@shuji-koike Merged. Thank you for contribution!

@shuji-koike shuji-koike deleted the fix-in-monitor-agent-npe branch January 4, 2017 15:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working v0.14
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants