Listen gem setup for production Rails app

[dwayne purper]

Github said to come here for questions on the Listen gem as well as Guard, so ..

I have a workflow where my users submit PDFs from an iPad to a temporary directory on my server. I need my Rails app to watch that directory and move the files to their permanent location on the same machine. The Listen gem looks like the perfect solution, but I want to make sure this is the correct setup:

----

# config/initializers/listen.rb

callback = Proc.new do |modified, added, removed|

DocManager.new.move_all_to_destination

end

listener = Listen.to(Settings.fetch_directory).change(&callback)

listener.start(false)

----

This is working for test files, but is it running on the same thread as my Rails app? If I have to do a big file move, is that going to halt the app? Should I wrap it inside a Thread block, or are there other ways of handling this?

Thanks for any feedback!

[Thibaud Guillaume-Gentil]

Wouldn't be easier to handle this PDFs uploads in a Rails action (or with a little async server) and process these files asynchronously with some workers?

Listen is a very useful tool for development purpose, but I wouldn't use it in production code.

> --
> You received this message because you are subscribed to the Google Groups "guard-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to guard-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[dwayne purper]

The upload doesn't happen in a browser.

We're uploading the files via iPad because we need to get digital signatures on the PDFs. We do this through an app called PDF Expert, which allows us to submit the final documents via FTP, but we can't trigger a separate HTTP request to communicate with the Rails app. So I need a way to know when a file has been uploaded. I assume it's either this or polling, but -- at least to start -- the volume is going to be very low, maybe 1 or 2 documents per week. Eventually, it might grow to 10-20 per day.

I lean toward starting the Listen instance inside the Rails app because I can make sure it gets started when the Rails app is started. (Seems like it would be harder to manage if the Listen action is in a separate thread ... if I restart the Rails app, does it spawn a new, duplicate Listen instance? What if the Listen instance goes down?)

--
Dwayne Purper

[Thibaud Guillaume-Gentil]

In that case, I think it would better to develop an another app/script (outside of rails) that simply poll this folder (every minute?) and trig an action to yours Rails app.

[dwayne purper]

Thanks. That's definitely easier to implement and manage. (Only downside is that I'll have to train staff that the server might not be updated for up to 60 seconds ... but that's probably not a big deal. There's no urgency other than a sanity check for staff.)

I guess my thought was that polling every minute for a change that will only occur maybe once every 2000 to 5000 times is unnecessary overhead.

But ... it might be that continuously monitoring a directory is also overhead (maybe more?) that's just hidden from me.