1.0 Todos

[dmke]

(incomplete, needed a place to dump some notes/ideas)

The 1.0 release will require Ruby 2.2.

• remove alias_method_chain altogether (see Use Module#prepend instead of alias_chaining for rails exceptions #31), as Module#prepend is always available
  • the ActionDispatch::DebugExceptions lookup shenanigans in lib/influxdb/rails/railtie.rb can be simplified: AD::DE was introduced in Rails 4, and is always present
  • no need for InfluxDB::Rails::Middleware::OldHijackRenderException anymore
  • InfluxDB::Rails.safely_prepend can be inlined into the Railtie
• integrate Feature/load config from file #22, extend defaults from InfluxDB::Config::DEFAULT_CONFIG_OPTIONS
• create "stable" branch for 0.5.x releases
  • add deprecation warnings
  • release a last 0.5.x version with a post-install message

[kaspergrubbe]

Hi @dmke , thanks for this gem.

Can I come with a suggestion?

It would be cool to mention the different error scenarios somewhere. When I checked out the gem the first thing I tried to figure out was:

• Does errors affect my running Rails service?
• What happens in case of a connection interruption (retries, connect problems, interruptions)? Does it run in the background, or does it blow up and create 500 errors on my website?

And one thing is how it works today, do you have some expectations on how it should work in the future, e.g. is it tested?

[dmke]

This is a great point. Here's a first draft around the error scenarios:

By default (i.e. when not otherwise configured in a InfluxDB::Rails.configure block), this integration will use an asynchronous connection (config.async = true), i.e. data points are enqueued in the request-response cycle, but written to the database in a seperate thread. If the database is currently not reachable, it will try indefinitely (config.retry = nil), thus consuming memory.

If your InfluxDB server does not recover until the Rails process is restarted (e.g. you have memory constraints enforced via cgroups), these data points will be lost.

If you use a synchronous client (config.async = false), your controller action will need to process the data point inline, i.e. the response might finish later. The implementation actually uses the controller instrumentation, running after the response method call has finished, so I'm not actually sure whether this affects the response at all. At least the thread processing incoming HTTP requests is blocked until the data point is written to the database.

Will continue later, when I'm back home.

[kaspergrubbe]

That is great! You don't happen to have a Patreon or maybe just a Paypal I can send a small "thanks for your contribution" towards?

[dmke]

I don't want any money for this, a simple "thank you" (or better a code contribution :-)) is fine.

[dmke]

@kaspergrubbe I've added an FAQ section to the README. Did I miss something?

[kaspergrubbe]

I think it is written in a really clear and concise way, and it would have answered all my questions. Thanks for adding it, @dmke ! 👍