This is my very first question in stack overflow and I am quite excited. Liked a lot the interface of this site and the buoyant community!
I am building a rails app that receives text as an email and creates a post.
I ask or your expert opinion on which is the best option to receive the mail message and process it?
To send the mail to the application:
A1: X accesses a POP/IMAP account periodically (30s cronjob?) and processes the message
A2: the message is piped from the mailserver to the application X
To process the application
B1: rails with MMS2R
B2: PHP that processes the message and sends a POST in rails
B3: PERL that processes the message and sends a POST to rails
Which combination A+B would you recommend for a big volume of mails?
Any other A or B option?
Thank you very much and good luck with all your scripting!
Any of them that doesn't then perform an HTTP POST to the web app, it's an unnecessary middle man and will only slow you down under volume. Having said that, the upside is one location for any business logic if necessary. So, weigh those two points before making a decision.
Now, for this personally, I'd probably go Perl over the others, though PHP would be a closer option. That, of course, is because I don't know Ruby. For you, though, I'd probably suggest Ruby so that your language is consistent across the application. That makes maintenance a lot easier in the long run and it probably allows for sharing of business logic with the web app without needing to specific use the web app.
if you are concerned about volume, I would just use perl + db (bypass rail app).
Related
we are currently developing a chat (like facebook, with stored messages).
at the moment, theres a minimum of 500 online users (its a dating website) and at the peak there is a max of 3000 users simultanously online.
switching to websockets is "the thing" for us, but while using the gem "websocket-rails" we fear a little the performance.reading articles like https://www.igvita.com/2008/11/13/concurrency-is-a-myth-in-ruby/ is causing some doubts.
so our question is:
does websocket-rails is killing our application or not? the other choice would be running a jsnode server and switch to faye which shouldnt be a problem in our scalabitliy. does somebody is having any expereince with the scalability of websocket-rails?
The GIL is still here, but should not be the main issue. The main problem is that the Rails approach does not fit well in a massive chat approach.
My suggestion is to switch to event machine for this specific part, and still use websocket (or others push mechanism, like pusher), and use this kind of WebSocket EventMachine Client.
You will be then event driven, with a single ruby thread and you still can use all the others rails existing libraries (that's the node.js model)
Our rails app acts as a go-between for the UI and a java-powered API at the back. Basically, rails takes requests from the browser, tells the API what it needs, does some normalization and formatting, then hands it back to the browser. Our app is ALSO an installed app, often without internet access. Oh, and it all gets compiled into a JRuby war.
Currently, to get statuses of various things over time, we're running some javascript intervals every X seconds. We've started discussing a better solution to this, but given the requirements above, AND required support for IE9, I'm not sure what the best course of action is, or how to go about implementing it. Basically, I'm looking for some solid examples of either long polling in rails 3, or some kind of sockets implementation that will work for IE9 + our wonky installation/compiling requirement.
I'd appreciate any thoughts or feedback.
The IE 9 requirement rules out a WebSockets implementation.
Basically, I'm looking for some solid examples of either long polling in rails 3
An example for a long polling/polling solution is the MessageBus the Discourse forum software uses. It is a Rails app but they're not on Rails 3 any longer.
https://meta.discourse.org/t/why-does-discourse-not-use-web-sockets/18302
The "message bus" is component that allows us to easily publish information to our clients and between the rails processes in the farm.
https://meta.discourse.org/t/how-discourse-stays-online-message-bus-faye-long-polling/3238/7
Message Bus is opinionated, it only supports the protocol it needs to drive Discourse. It only supports redis for storage. Message Bus does not support web sockets. It only supports polling and long polling.
I'm writing a Rails web service that interacts with various pieces of hardware scattered throughout the country.
When a call is made to the web service, the Rails app then attempts to contact the appropriate piece of hardware, get the needed information, and reply to the web client. The time between the client's call and the reply may be up to 10 seconds, depending upon lots of factors.
I do not want to split the web service call in two (ask for information, answer immediately with a pending reply, then force another api call to get the actual results).
I basically see two options. Either run JRuby and use multithreading or else run several regular Ruby instances and hope that not many people try to use the service at a time. JRuby seems like the much better solution, but it still doesn't seem to be mainstream and have out of the box support at Heroku and EngineYard. The multiple instance solution seems like a total kludge.
1) Am I right about my two options? Is there a better one I'm missing?
2) Is there an easy deployment option for JRuby?
I do not want to split the web service call in two (ask for information, answer immediately with a pending reply, then force another api call to get the actual results).
From an engineering perspective, this seems like it would be the best alternative.
Why don't you want to do it?
There's a third option: If you host your Rails app with Passenger and enable global queueing, you can do this transparently. I have some actions that take several minutes, with no issues (caveat: some browsers may time out, but that may not be a concern for you).
If you're worried about browser timeout, or you cannot control the deployment environment, you may want to process it in the background:
User requests data
You enter request into a queue
Your web service returns a "ticket" identifier to check the progress
A background process processes the jobs in the queue
The user polls back, referencing the "ticket" id
As far as hosting in JRuby, I've deployed a couple of small internal applications using the glassfish gem, but I'm not sure how much I would trust it for customer-facing apps. Just make sure you run config.threadsafe! in production.rb. I've heard good things about Trinidad, too.
You can also run the web service call in a delayed background job so that it's not hogging up a web-server and can even be run on a separate physical box. This is also a much more scaleable approach. If you make the web call using AJAX then you can ping the server every second or two to see if your results are ready, that way your client is not held in limbo while the results are being calculated and the request does not time out.
I've found plenty of articles showing me what EventMachine is and how to set up endless "Hello World!" examples, but I'm still at a loss as to how this integrates with my Rails application.
As a example, I have an existing Rails app that has many concurrent users who may be editing the same row in my database simultaneously. I was thinking that I would allow the record to be loaded by two (or more) different people, but notify those users if the record was updated and force the latter users to reconcile any conflicting changes before saving it back to the database. I was thinking I could handle the notifications and reconciliations using Javascript on the client side and websockets (or flashsockets) to communicate with the browser (on the event that another user updates the record--like a push notification, or something).
The last part led me to EventMachine, but--as my lead-off question indicates--I'm at a loss about how to integrate this into my Rails app.
Can anyone give me some insight to this (like, a good macro-level viewpoint) or point me towards some good resources? (Apart from EventMachine's wiki, as I've already been there).
I spent a considerable amount of time looking into this. EventMachine needs to run as a thread in your rails install (unless you are using Thin,) and there are some special considerations for Passenger. I wrote our implementation up here: http://www.hiringthing.com/2011/11/04/eventmachine-with-rails.html
I think this example of some async Rails setup could also help you in your investigation of EventMachine like features usage in the applications. It is not fully related to EventMachine itself, though.
I need to display logfiles in real time to user webpage using ruby/rails. Users should be able to see logfile steaming without refreshing the page.
Logfiles may not always be in the same machine which runs rails.
Is it possible in ruby/rails ?.
You could do this with automatically refreshing page, using AJAX when JavaScript is available (this avoids page flicker and extra bandwidth usage caused by a page reload).
The other approach (actually incrementally updating page) consists of two separate issues: (1) reading the file as it grows, and (2) sending the answer without closing the connection. I have seen some solutions doing this (not in Rails, though), but unfortunately they tend not to be very reliable (browsers and other parts of the system will timeout) and the users get confused when the page loading never finishes.
Ruby and Rails can read files, but the issue is going to be accessing from different machines. Are the logfiles on the same network?
What you're asking for is not necessarily Rails-specific. It's more a question of technology, IMO.
Because the classic web model is client/server and pushing data asynchronously is not standard, you'll need to figure out how to do it either by:
1) faking it by polling on the client.
2) use a different technology. For Rails, you may want to look into something like comet or websockets.