Production ready? about active-elastic-job HOT 12 CLOSED

Hi @ruuts

Thanks for your interest.

To answer your questions:

Are you using this in production?

It's not used in production by me atm, and I don't know if anyone is using it for production. I made this gem, because I'm working on a rails app for a client which is deployed on EB. I was looking for a way to use DelayedJob and finally I came to the same conclusion as you.

So why don't we use it in production? To be honest: The additional worker environment almost doubles the fees, since it runs its own EC2 instance. But the application is in an early stage and the load on the web servers is quite low (not so much traffic). We use Sucker Punch atm, because it does not require to start an additional process next to the web server (no post deploy script hacks required), it simply reuses the web server process. And since this process is idle most of the time, it can as well process jobs from a queue. Active Elastic Job is deferred for cost optimisation so to say 😁 . Maybe Sucker Punch might fullfill your needs as well. However, we are aware that this approach will not scale, and once the load increases we will probably switch to this gem.

and is it stable?

I can't say of it's stable, but I can assure you that it has a high test coverage. The test suite also contains a fully integrated test scenario. It deploys a test application directly to an EB web and worker environment, creates a job via a web request and polls the application in a given time window, to check whether the job was performed or not. Right now the build is green 😁

If the whole approach is stable, depends whether Amazon delivers what it's promises. The specs for SQS are impressive and if they hold, than I will use SQS for many projects to come.
In fact I'm currently also busy with benchmarking the whole approach. I want to compare it with Resque from an economical perspective. What is cheaper and easier to maintain, when both approaches are deployed on AWS infrastructure? I will publish my results and a git repo for reproduction.

If you want to go on and try this gem, I will be happy to help and troubleshoot if problems occur 👍 .
I think the most problems might have their origin in the configuration and setup, which has to be done carefully (see README).

• The queue name has to match,
• environment variables have to be set,
• the AWS user has to have enough privileges
• the secrect base also has to match. See the Caveats section

Hope that clears up some of your question.

Cheers,
tawan

from active-elastic-job.

Hi @tawan,

Thanks for your extensive response 😄.

We have checked the code. It looks really good, nice test suite!
I have some comments:

1. Send message is not checking if sending of the message is actually successful. Is this on purpose?
2. When enqueuing a job it makes two requests to get the queue url and to actually send the message. I can imagine this is a performance penalty. We could cache the queue_url and when the send_message fails due to a invalid queue_url we could retry to get the url. Or am I missing something?

I think we are going to give this a try and when needed contribute to the project. Good job man!

from active-elastic-job.

Hi @ruuts

You are welcome and thx for the feedback.

Send message is not checking if sending of the message is actually successful. Is this on purpose?

Normally the Aws::SQS::Client should scream and raise an error if sth. goes wrong. Atm. I do not catch these errors and I just let them escalate (I want to change that -> issue 5). Your question also reminded me that I wanted to verify the MD5 hashes of the response, I created an issue.

When enqueuing a job it makes two requests to get the queue url and to actually send the message

You are totally right, the queue url should be cached (shoryuken does it already).
I created an issue which I want to include in the next release.

I think we are going to give this a try and when needed contribute to the project.

Happy to hear that. PRs are of course welcome any time.

from active-elastic-job.

Hi @tawan

Thanks for the answer. We're going to integrate this next week.
And of course.. if we can contribute we will!

from active-elastic-job.

I am afraid it is not that simple. @tawan, with which version of beanstalk did you run your tests on?

The one I am using is the latest platform (ruby 2.2/phusion standalone). According to logs the daemon is trying to post the sqs msg to my localhost url (as it should), but it is getting 404.

It might be related to the middleware.

The daemon string: aws-sqsd/2.0
I think some header might not being sent.. I confirmed the secrets are setup correctly. I plan to investigate further tomorrow.

from active-elastic-job.

Hi @zaaroth

Thanks for your comment. May I ask which Rails version you are using? I will try to reproduce the issue.
I'm using ruby 2.2/phusion standalone with Rails 4.2.5.

from active-elastic-job.

That's my config. I'm using rails 4.2.5

from active-elastic-job.

@zaaroth Please try to run locally in the root dir of your rails app this command:

bundle exec rake middleware | grep -e "ActiveElastic"

What is the output?

It should look like this

use ActiveElasticJob::Rack::SqsMessageConsumer

from active-elastic-job.

@tawan: It is using the middleware.

Full output before my own routing middleware:

use Rack::Sendfile
use ActionDispatch::Static
use Rack::Lock
use #ActiveSupport::Cache::Strategy::LocalCache::Middleware:0x00560702787ad0
use Rack::Runtime
use Rack::MethodOverride
use ActionDispatch::RequestId
use Rails::Rack::Logger
use ActionDispatch::ShowExceptions
use ActionDispatch::DebugExceptions
use ActionDispatch::RemoteIp
use ActionDispatch::Callbacks
use ActiveRecord::ConnectionAdapters::ConnectionManagement
use ActiveRecord::QueryCache
use ActionDispatch::Cookies
use ActionDispatch::Session::CookieStore
use ActionDispatch::Flash
use ActionDispatch::ParamsParser
use Rack::Head
use Rack::ConditionalGet
use Rack::ETag
use ExceptionNotification::Rack
use ActiveElasticJob::Rack::SqsMessageConsumer

from active-elastic-job.

Server logs show the request is passing through and a route cannot be found, which leads me to believe some of the checks in the middleware are not triggering a request interception.

from active-elastic-job.

@zaaroth I think I found a potential source for this behavior.
Version 1.3.0 also checks for an additional message attribute that identifies the gem as the origin for the message. Unfortunately, this breaks backwards compatibility and message which have been queued by a previous version will not be processed.

I fixed this problem and released Version 1.3.1 which I just released.

from active-elastic-job.

Closed in favor of #10

from active-elastic-job.