Skip to content

Uninitialized constant error (ruby-kafka) w/ v4.7.0 #134

Description

@brandonhsieh

Hi, following the release of v4.7.0, an error results when using ruby-kafka v0.7.1
"uninitialized constant Datadog::Statsd::Connection::DEFAULT_PORT\nDid you mean? Datadog::Statsd::DEFAULT_BUFFER_SIZE"

ruby-kafka/lib/kafka/datadog.rb: line 80

def default_host
  ::Datadog::Statsd.const_defined?(:Connection) ? ::Datadog::Statsd::Connection::DEFAULT_HOST : ::Datadog::Statsd::DEFAULT_HOST
end

Following is the listener error backtrace

[2020-02-17T20:05:44:328+0000Z] ERROR -- Phobos : {:message=>"Listener crashed, waiting 16.14s (uninitialized constant Datadog::Statsd::Connection::DEFAULT_PORT\nDid you mean? Datadog::Statsd::DEFAULT_BUFFER_SIZE)", :listener_id=>"51366e", :retry_count=>4, :waiting_time=>16.14, :exception_class=>"NameError", :exception_message=>"uninitialized constant Datadog::Statsd::Connection::DEFAULT_PORT\nDid you mean? Datadog::Statsd::DEFAULT_BUFFER_SIZE", :backtrace=>["/usr/local/bundle/gems/ruby-kafka-0.7.10/lib/kafka/datadog.rb:85:in default_port'", "/usr/local/bundle/gems/ruby-kafka-0.7.10/lib/kafka/datadog.rb:52:in port'", "/usr/local/bundle/gems/ruby-kafka-0.7.10/lib/kafka/datadog.rb:34:in statsd'", "/usr/local/bundle/gems/ruby-kafka-0.7.10/lib/kafka/datadog.rb:106:in emit'", "/usr/local/bundle/gems/ruby-kafka-0.7.10/lib/kafka/datadog.rb:99:in block (2 levels) in <class:StatsdSubscriber>'", "/usr/local/bundle/gems/ruby-kafka-0.7.10/lib/kafka/datadog.rb:124:in request'", "/usr/local/bundle/gems/activesupport-6.0.2.1/lib/active_support/subscriber.rb:145:in finish'", "/usr/local/bundle/gems/activesupport-6.0.2.1/lib/active_support/notifications/fanout.rb:160:in finish'", "/usr/local/bundle/gems/activesupport-6.0.2.1/lib/active_support/notifications/fanout.rb:62:in block in finish'", "/usr/local/bundle/gems/activesupport-6.0.2.1/lib/active_support/notifications/fanout.rb:62:in each'", "/usr/local/bundle/gems/activesupport-6.0.2.1/lib/active_support/notifications/fanout.rb:62:in finish'", "/usr/local/bundle/gems/activesupport-6.0.2.1/lib/active_support/notifications/instrumenter.rb:45:in finish_with_state'", "/usr/local/bundle/gems/activesupport-6.0.2.1/lib/active_support/notifications/instrumenter.rb:30:in instrument'", "/usr/local/bundle/gems/activesupport-6.0.2.1/lib/active_support/notifications.rb:180:in instrument'", "/usr/local/bundle/gems/ruby-kafka-0.7.10/lib/kafka/instrumenter.rb:21:in instrument'", "/usr/local/bundle/gems/ruby-kafka-0.7.10/lib/kafka/connection.rb:97:in send_request'", "/usr/local/bundle/gems/ruby-kafka-0.7.10/lib/kafka/broker.rb:200:in send_request'", "/usr/local/bundle/gems/ruby-kafka-0.7.10/lib/kafka/broker.rb:44:in fetch_metadata'", "/usr/local/bundle/gems/ruby-kafka-0.7.10/lib/kafka/cluster.rb:375:in block in fetch_cluster_info'", "/usr/local/bundle/gems/ruby-kafka-0.7.10/lib/kafka/cluster.rb:370:in each'", "/usr/local/bundle/gems/ruby-kafka-0.7.10/lib/kafka/cluster.rb:370:in fetch_cluster_info'", "/usr/local/bundle/gems/ruby-kafka-0.7.10/lib/kafka/cluster.rb:350:in cluster_info'", "/usr/local/bundle/gems/ruby-kafka-0.7.10/lib/kafka/cluster.rb:98:in refresh_metadata!'", "/usr/local/bundle/gems/ruby-kafka-0.7.10/lib/kafka/cluster.rb:52:in add_target_topics'", "/usr/local/bundle/gems/ruby-kafka-0.7.10/lib/kafka/consumer_group.rb:27:in subscribe'", "/usr/local/bundle/gems/ruby-kafka-0.7.10/lib/kafka/consumer.rb:575:in subscribe_to_topic'", "/usr/local/bundle/gems/ruby-kafka-0.7.10/lib/kafka/consumer.rb:105:in subscribe'", "/usr/local/bundle/gems/phobos-1.8.2/lib/phobos/listener.rb:96:in block in start_listener'", "/usr/local/bundle/gems/phobos-1.8.2/lib/phobos/instrumentation.rb:21:in block in instrument'", "/usr/local/bundle/gems/activesupport-6.0.2.1/lib/active_support/notifications.rb:182:in instrument'", "/usr/local/bundle/gems/phobos-1.8.2/lib/phobos/instrumentation.rb:20:in instrument'", "/usr/local/bundle/gems/phobos-1.8.2/lib/phobos/listener.rb:94:in start_listener'", "/usr/local/bundle/gems/phobos-1.8.2/lib/phobos/listener.rb:46:in start'", "/usr/local/bundle/gems/phobos-1.8.2/lib/phobos/executor.rb:72:in run_listener'", "/usr/local/bundle/gems/phobos-1.8.2/lib/phobos/executor.rb:31:in block (2 levels) in start'", "/usr/local/bundle/gems/concurrent-ruby-1.1.6/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:353:in run_task'", "/usr/local/bundle/gems/concurrent-ruby-1.1.6/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:342:in block (3 levels) in create_worker'", "/usr/local/bundle/gems/concurrent-ruby-1.1.6/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:325:in loop'", "/usr/local/bundle/gems/concurrent-ruby-1.1.6/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:325:in block (2 levels) in create_worker'", "/usr/local/bundle/gems/concurrent-ruby-1.1.6/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:324:in catch'", "/usr/local/bundle/gems/concurrent-ruby-1.1.6/lib/concurrent-ruby/concurrent/executor/ruby_thread_pool_executor.rb:324:in block in create_worker'", "/usr/local/bundle/gems/logging-2.2.2/lib/logging/diagnostic_context.rb:474:in block in create_with_logging_context'"]}

Thank you

Activity

  1. tjallingvanderwal commented on Feb 19, 2020

    @tjallingvanderwal

    Datadog::Statsd::Connection::DEFAULT_PORT has been moved in this commit: fc849ea

    Either that constant was not part of the public API, or they should have bumped the version to 5.0 because moving the constant is a breaking change.

    Projects I work on also used that constant and broke. Because both apps and internal gems included in those apps each create their own Statsd instance, we had to update them in in one sweep. To avoid that in the future, we chose to not longer use those constants and trust the gem to use default host+port when not configured.

    In your case, you'll have to report this to ruby-kafka, so they can stop using this constant.

  2. dnstevenson1 commented on Mar 4, 2020

    @dnstevenson1

    We ran into this today as well and had to back off the gem update.

  3. kbogtob commented on Mar 4, 2020

    @kbogtob
    Contributor

    Hi !
    In relation to the big code refactor that it is happening on the project, I moved this constant in a subclass. I don't think it was part of the public API so I'm quite surprised you are using it. Could you explain why do you need it or what dependency use it? (except than ruby-kafka that I'll analyze)

    I can publish a fix to that change if needed linking the constant in the sub classe.

  4. tjallingvanderwal commented on Mar 4, 2020

    @tjallingvanderwal

    Could you explain why do you need it or what dependency use it?

    The reason I used it was that I liked the explicitness of saying "we're using the defaults".
    We updated everything without problems, so no need to publish a fix for me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions