NameError: uninitialized constant Aws::Client::Errors

[pmorton]

Hi All - I am trying to diagnse what seems to be a very hairy error. At verying intervals, our application will trap an exception to our error service. The exception is NameError: uninitialized constant Aws::Client::Errors. The partial stack trace can be found here https://gist.github.com/pmorton/c229ef2506d7328efacd0ca0750f702b.

kinesis_base.rb:49 calls client.put_record with the required arguments to put a record to kinesis. Note that this call is run on a different thread than the main application logic. The vast majority of the calls succeed, but at intermittent intervals we received these exceptions.

This happens on our app the runs jruby-1.7.19, however other applications that run MRI doe not seem to exhibit this same behavior.

---

What I know so far:

1. Aws::Client::Errors is not defined anywhere in the gem (dynamically or otherwise).
2. The error handling logic parses the class name of the client to determine where the error should be rooted. https://github.com/aws/aws-sdk-ruby/blob/master/aws-sdk-core/lib/aws-sdk-core/xml/error_handler.rb#L25 . This allows common HTTP errors to be call specific. E.g errors that are raised from Aws::Kinesis::Client will use Aws::Kinesis::Errors:: to raise the proper exception for that service.

My theory, which I cannot seem to easily prove, is that when https://github.com/aws/aws-sdk-ruby/blob/master/aws-sdk-core/lib/aws-sdk-core/xml/error_handler.rb#L24 is executed the client class name is actually being reported as 'Seahorse::Client' which would explain when the error handler is trying root the errors in Client.

Some random thoughts about where the problem might be:

1. Thread Safety - Since we only see this in JRuby, it is possible that there is code that is not thread safe. Such corruption could lead to partially loaded or defined classes:

• https://route.github.io/2013/11/13/rails-autoloading.html
• https://bugs.ruby-lang.org/issues/12688
• https://bugs.ruby-lang.org/issues/8570
  1. Not sure. Most everything else passes the smell test and given that the code works the vast majority of the time.... 🍺

[awood45]

Thanks for the investigation here - will dive in to this.

I suspect that your guess around thread safety is the right one. In which case, calling Aws.eager_autoload! (which accepts individual services as parameters if you do not want to autoload the entire SDK) should fix the symptoms.

If you try this workaround and continue to see this error, please do let me know.

[awood45]

Thanks for the investigation here - will dive in to this.

I suspect that your guess around thread safety is the right one. In which case, calling Aws.eager_autoload! (which accepts individual services as parameters if you do not want to autoload the entire SDK) should fix the symptoms.

If you try this workaround and continue to see this error, please do let me know.

[pmorton]

Hey - We did the work around many months ago by adding Aws.eager_autoload! as a rails initializer. Unfortunately the issue persists.

[pmorton]

Hey - We did the work around many months ago by adding Aws.eager_autoload! as a rails initializer. Unfortunately the issue persists.

[pmorton]

@awood45 look like this is a Jruby bug. :( jruby/jruby#3920

[pmorton]

@awood45 look like this is a Jruby bug. :( jruby/jruby#3920

[awood45]

Interesting - thanks for spotting that!

[awood45]

Interesting - thanks for spotting that!

[trevorrowe]

I'm going to close this issue, as it is currently non-actionable by the SDK. That said, we will be pushing out a preview release shortly of the SDK where the services are modularized into individual gems. With this refactor, we have removed the use of Ruby's autoload which should also side-step this issue entirely.

[trevorrowe]

I'm going to close this issue, as it is currently non-actionable by the SDK. That said, we will be pushing out a preview release shortly of the SDK where the services are modularized into individual gems. With this refactor, we have removed the use of Ruby's autoload which should also side-step this issue entirely.