send errors asynchronously about airbrake-grails

[jonspalmer]

both of those are good options and it might make sense to include those examples in the docs. However, I don't think it is the job of this plugin to pick an implementation. In particular some apps might have a queuing solution already. You might prefer to use a queue instead of just starting threads so that you can control how many threads are working on sending Airbrake errors, and you probably get better failure handling etc.

Maybe we could provide some configuration option to pick Thread Starting or the ExecutorService but I'm not convinced its worth it and users of the plugin should feel free to pick the implementation that they want/need.

However, I don't think it is the job of this plugin to pick an implementation.

But the plugin does already choose a default implementation - sending each notice in the same thread as the request. Most people will use this default and IMO it's the worst of the 3 options (same request, new thread, thread pool).

I think a better solution would be to send each notice in a separate thread by default, but the user can choose to configure a thread pool instead (with max threads specified by the user). I really can't imagine why anyone would want the notice sent in the same thread as the request.

[jonspalmer]

That might be true but the simple Thread start is IMO a really terrible option too and not one I'd want to include as the default, it just has too many failure modes at any scale. Picking anything more realistic introduces some external dependency that would be unnecessary if you don't want that.

For context the Ruby gem does not do async by default. I'm ok with that. Maybe we should just word the documentation more strongly to pick a sensible async option for you app.

Picking anything more realistic introduces some external dependency that would be unnecessary if you don't want that.

Using a thread-pool doesn't introduce any external dependencies. If we use this as the only supported asynchronous strategy we could remove the current dependency on Quartz.

Maybe we should just word the documentation more strongly to pick a sensible async option for you app.

I think it would be preferable for the out-of-the-box behaviour to be a sensible async strategy e.g. thread pool with 5 threads, but the user can customise the number of threads if necessary.

[jonspalmer]

There is no production dependency on quartz, only in test of the plugin

But you can't compile the plugin without Quartz on your classpath, because both of these classes (which are not in src/test) have a dependency on Quartz:

https://github.com/cavneb/airbrake-grails/blob/master/grails-app/jobs/grails/plugins/airbrake/test/AirbrakeNotifyJob.groovy

Also, there is a compile-scoped (not test-scoped) Quartz dependency in BuildConfig.groovy

https://github.com/cavneb/airbrake-grails/blob/master/grails-app/conf/BuildConfig.groovy

So while the intention might have been to only require for testing, that's not in fact the case in the current version

[jonspalmer]

If there is a lightweight thread pooling solution with minimal dependencies then a pull request would be great.

[jonspalmer]

Wrt the quartz plugin. Grails should pull in the plugin for you. You shouldn't need to do anything to add it to the classpath. I didn't think it was a big deal for developers of the plugin to deal with that. Consumers of the plugin don't notice the difference. That said if there is a simpler solution for proving the async feature for testing I'm all for removing the quartz stuff altogether.

The Java standard libraries (classes in java.util.concurrent and specifically the ExecutorService class) provide thread pooling, so there's a solution that doesn't require any external dependencies.

I'll submit a pull request that replaces Quartz with this if we're agreed on that?

[jonspalmer]

Sounds good.

[jonspalmer]

fixed as part of pull request 22