[LRUG] Ruby on Rail 4.2 networking breakfast (Graeme McCubbin) (Andrew White)

[Rory Sinclair]

I missed the first part of the discussion, but I think I get what you’re saying from context.

The main pain in the ass i’ve experienced with using http as a transport for stuff like this is if it takes more than, say, 30s to execute, and Unicorn master kills the worker.  Background jobs can run longer, and aren’t subject to the same responsiveness constraints.  We used to use a message queue that triggered an HTTP call back into our app to actually do stuff, and hit the unicorn timing thing.  We extended the timeout, but really the better approach is to go properly async with something like sidekiq or resque.

Just my tuppenceworth.  

--  
Rory Sinclair
Head of Technology
ASMALLWORLD


On Tuesday, 8 July 2014 at 10:12, Andrew White wrote:

> > Fascinating. One mans simple is another mans complicated.
>  
>  
> It's true that what's complicated is a matter of perspective but here I was trying to point out the fact that a simple HTTP call back into your app will have a lot of complicated side effects even though its implementation is simple.
>  
>  
> > Backgound processing libraries introduce another level of abstraction and indirection.
> > You have to write another adaptor to call the logic, we already have that, its called a controller.
> >  
>  
>  
> Isn't the whole point of things like Hexagonal Rails the idea that it's easy to use elsewhere? Saying that it's difficult to use from outside the controller sounds like close coupling.
>  
>  
> > This doesn't test the stack of the app the way a client does.
>  
> So is this just a problem in testing? If so it could be a race condition where Ruby is waiting on a response from the HTTP request but that can't be processed because of the GIL. Something definitely doesn't sound right - whenever I'm struggling to get something working in a framework (Rails or whatever) my default assumption is that I'm doing something wrong because lots of other people have will have got it working.
>  
> If you can reproduce it inside a simple script or push a simple app to GitHub that reproduces the problem then I'm prepared to have a look at it to see if there's a bug in Rails.
>  
>  
> > If I use a controller to call a method on my object and that same method is called via Sidekq
> > then I have two tests to write, one for it being called by the controller and one for it being  
> > called by Sidekq. Using a http request is saving code and tests and the overhead is not proven
> > to be higher than Sidekq or some other background processing library.
> >  
>  
>  
> That doesn't make sense - you write a unit test that calls the shared code directly and you write integration tests to test the effects of the shared code in the various places it's used. That goes for wether it's called via HTTP or as a background task.
>  
>  
> Andrew White
> Rails Core Team Member
> _______________________________________________
> Chat mailing list
> Chat at lists.lrug.org (mailto:Chat at lists.lrug.org)
> Archives: http://lists.lrug.org/pipermail/chat-lrug.org
> Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
> List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>  
>  


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20140708/608a4ae3/attachment.html>