Which server option is widely used with JRuby on Rails? - jruby

I am experimenting JRuby on Rails and need some guidance/tips in choosing the server. I have used nginx (and passenger) for my RoR in the past. JRuby wiki page Servers provide a lot of options and I have no experience in any of them.
What I am looking for is a simple to install, easy to scale server or the one widely used (so that I can find solutions if I am stuck)
I do realize this might be a broad question and the answer would be "it depends..." but would appreciate some pointers.

I might be biased being on the Trinidad team, but I still think it's top ... esp. as it handles high concurrency well while still being much lighter than TorqueBox (which I would also recommend if you do want something beyond just a web server e.g. built-in jobs but be aware that some of it is TB/JRuby specific). Most other options mentioned are Java web servers, which you can rule out if you do not want to install a Java server, warbling your application and deploying it as a .war file.
p.s. for the (next) version 1.5.0 re-deploys are to be revisited and one should be able to do some (memory leak-free) zero-down time deployments.

Related

Most Efficient ERPNext Installation Method

I'm taking on the challenge of trying to test and develop with ERPNext. I'm new to ERPNext, Docker, Compose, Git, etc. I'm going to need to learn these from scratch.
What is the general most efficient way to install ERPNext (for testing purposes for now) on either a Mac or Windows computer?
Below are my criteria:
I need to be able to create backups and transfer them and implement
them to a different computer if necessary.
I'm also attempting to do this in as budget-friendly way as
possible. I'm probably not going to be spending money on hosting or
anything of the sort (completely free is the goal).
ERPNext needs to be easily upgradeable/downgradeable to different versions
The implementation of ERPNext will eventually need custom code/integrations
I've read that there are different methods of using ERPNext, depending on the OS, including VirtualBox, and Windows Subsystem for Linux. I'm looking for the fastest, least resource-hungry, and most versatile solution
I will check out the official ERPNext documentation, but I would also like to know other people's personal experiences and methods.
This is a big task to take on, so I'm looking for some advice before delving into this.
You can use frappe_docker setup to quickly get the environment up and running.
https://github.com/frappe/frappe_docker
If you want least resource hungry option, you can setup a site using bench.
https://github.com/frappe/bench

Turn-key docker-compose solution to start developing with Node.js?

I am looking for a simple, no frills, docker-compose based solution so I can start playing with some common tools, without having to devote lots of time into learning to configure the infrastructure. It should pull from the official images of the included projects, to make things super standardized and easy to move forward.
Ideally, I can have local directories mounted, so I can just edit my code directly, and have it served up through the container. Even better is to have the database stored similarly, in case I wind up liking it and want to port it into a project.
Edit:
Since it seems nobody gets it. The reasons for wanting this are:
No local installation of tools to pollute my development environment.
No rebuilding of containers as I change my code, learn, and test out features.
Not using any exotic features or special configuration, so official containers from the distributions should be sufficient.
Clean roadmap to scaling up to a real project. Acts as a template going forward.
Not spending time on tasks that are not relevant to the final goal (configuring a platform that may never be used).
It seems clear to me that a significant portion of development should use containerized runtimes for building/testing, without installing things on the real host. That would avoid a lot of hassles and conflicts, and allows easy revisiting of old development environments.
This seems like an obvious thing that should be readily available, just like the standard images that many projects provide.
As I am just looking to evaluate things, I'm not that picky about tools. A development language/framework (Node.js), a database (MySQL), and web server capability (anything). If it's PostgreSQL, MongoDB, whatever. I just don't want to spend days wrestling with setting things up, before I actually get to start evaluating the platform.
I tried asking this over on DevOps a few days ago. All I got was one snarky and unhelpful comment, which has since been deleted.
I have tried following a bunch of different tutorials around the web and answers given here, but they all fail, and I really don't want to get sidetracked debugging them.
It seems like this would be a common template for starting many projects, regardless of complexity or expertise. So, I'm really surprised I can't find it. It also seems like a good way to lure in new users, which should incentivize project maintainers to have these.

WIX InstallUtil/InstallUtilLib and Configuration File Deployment why is InstallUtil bad?

I often find the quote "InstallUtil.exe" is an ugly pattern or "Don't use InstallUtil.exe" and that I should use native WIX or Installation package patterns and I still don't understood why.
I stepped away from using InstallUtil to install a .NET service as I finally learnt that writing registry keys for such an action should be an un-install-able action - and I've come to terms with this as correct.
As I've been working through my WIX installer for a relatively complex product, I have found myself in need of creating or updating SQL Server databases, creating or updating IIS Applications and finally updating or creating configuration files.
Each of my components (features) are optional, but they all share the same configuration file. As my product uses unity, its important to note that this library contains strong support for reading/updating/removing components from the Unity Configuration block, therefore it seems fairly smart to me that I should take advantages of these blocks via Installation Components (i.e. InstallUtil) to create or update my configuration file at installation time.
Just to be clear here, my installer does not natively contain a configuration file for my application: at installation time, the installer has no idea as to the shape of it as its based on the features selected. Surely I should be embedding this knowledge into each of the modules that are to be deployed and not in the remit of the installer which is now a completely independent project? Wouldn't this break O-O principals even if we are talking about installation?
I'd really appreciate some guidance as to whether this is good practise or not? Am I reading 'InstallUtil' is bad for installing services, or is it that using 'InstallUtil' is bad full-stop? If so, what are my options for smart updating of configuration files?
The main reason for avoiding InstallUtil is that it runs outside of the installation transaction, so Windows Installer cannot keep track of what it's done.
I have used InstallUtil on a few occasions, when I just couldn't get Wix to do what I needed and didn't have time to write a custom action. In this case I called the InstallUtilLib version as I feel this is a cleaner approach.
I used the this blog as a guide as to how to achieve this.

jruby on rails scheduling options

I'm using JRuby 1.5.6 on Rails to build myself an application that will periodically go away and retrieve any RSS podcasts that I have subscribed too.
I've chosen JRuby primarily because I'm familiar with Java, wish to utilise the Rails framework and most importantly I'm able to perform the "heavy lifting" tasks in Java when Ruby falls short of my requirements. Up to now (and I'm still in the early stages of development) this hybrid approach has been working extremely well.
I'm now at a point where I'm needed to implement scheduling of periodic and long running tasks to a background process. My requirements are to have a database backed scheduling system that is, ideally, well documented, currently maintained and clean.
My problem now is that after many days of researching suitable off the self gem packaged solutions, I appear to be left with very few options because of my use of JRuby.
Some of the gems I've tried...
rufus scheduler
Having used this before I'm happy with it's interface and documentation, however there is a lack of database persistence, hence a deal breaker for my requirements.
delayed_job
My ideal solution would be delayed_job. Good documentation, still being maintained and database backed, however, breaks under JRuby due to ObjectSpace being turn off (we can however fix this by re-enabling) but more fatally the dependence on the daemons gem which throws a "fork is unsafe and disabled by default on JRuby" error due to limitations within the JRuby implementation.
There is a fork on github that doesn't have a dependence on daemons, however I'm not happy switching to a fork off the main development branch and I'm still left with the ObjectSpace issue which I'm unsure as to it's performance impact.
quartz-jruby
While there have been various quartz based gems before, this very recent offering is another attempt at providing a slick ruby-like interface. There is however minimal documentation and I'm unsure as to if this can be database backed, my gut feeling is that it is not.
The problem
While I've only highlighted 3 options here, I'm aware that there are others available. I've however not been able to find a solution to tick all 3 requirement boxes (docs, maintained, database backed).
So the questions are...
Has anyone else been in this situation and come up with a solution?
Has anyone managed to get delayed_job working in whatever form?
Are there any better solutions out there that I've overlooked and will satisfy my needs?
We have been using delayed_job (collectiveidea/v1.8.4) under JRuby in production for over an year now.
We have not enabled ObjectSpace and also we do not use daemons gem.
Created a simple rake task
namespace :product do
desc "Start Delayed Job Worker"
task :dw => :environment do
Delayed::Worker.new.start
end
end
and daemonize it in the OS dependent way. On linux,
nohup jruby -S rake product:dw > $log_dir/delayed_job_console.log 2>&1 &
I would recommend resque as the queueing system. Resque is similar to DelayedJob, but in my opinion much better. It was developed at GitHub and is used as their queueing system. I've also been using it in production for almost a year and I've been very happy with it.
Resque definitely has JRuby support, and all you have to do to get scheduled jobs is have a simple scheduler. Some recommend resque-scheduler, though I like to keep it simple and use clockwork which has a nice DSL for writing simple cron-like tasks to queue up schedulers (see: clockwork README). With that, you can just schedule things like so:
every(1.hour, 'tasks.alert') { Resque.push(:cron, :class => 'TaskAlert', :args => []) }
Check https://github.com/kares/jruby-rack-worker
This allows delayed_job solution under jruby environment.
Still work in progress.
At the time of writing, my experience is that it works fine with a single worker.
Though I have difficulties at making additional workers run.
I originally asked this question in Dec '10 and have since developed a solution that I thought would be worth posting back for others to reference.
As others have pointed out, it is possible to get libraries like delayed_job working with JRuby and for some this might be an acceptable solution. I however didn't want a solution that required an additional process running and with that in mind I have developed a gem that utilises Java's Executor framework and integrates it with ActiveRecord.
The result is acts_as_executor which allows a Rails 3.x application to interact with executors and tasks (which will run in a proper Java thread) just as it would any other ActiveRecord model.
I've recently moved the gem to release candidate 1. Take a look at GitHub and Rubygems.
N.B. RubyGems default page still shows beta2 for some reason. rc1 is still the latest release however.

Defining a runtime environment

I need to define a runtime environment for my development. The first idea is of course not to reinvent the wheel. I downloaded macports, used easy_install, tried fink. I always had problems. Right now, for example, I am not able to compile scipy because the MacPorts installer wants to download and install gcc43, but this does not compile on Snow Leopard. A bug is open for this issue, but I am basically tied to them for my runtime to be usable.
A technique I learned some time ago, was to write a makefile to download and build the runtime/libs with clearly specified versions of libraries and utilities. This predates the MacPorts/fink/apt approach, but you have much more control on it, although you have to do everything by hand. Of course, this can become a nightmare on its own if the runtime grows, but if you find a problem, you can use patch and fix the issue on the downloaded package, then build it.
I have multiple questions:
What is your technique to prepare a well-defined runtime/library collection for your development?
Does MacPorts/fink/whatever allows me the same flexibility of rehacking if something goes wrong ?
Considering my makefile solution, when my software is finally out for download, what are your suggestions about solving the potential troubles between my development environment and the actual platform on my user's machines ?
Edit: What I don't understand in particular is that other projects don't give me hints. For example, I just downloaded scipy, a complex library with lots of dependencies. Developers must have all the deps setup before working on it. Despite this, there's nothing in the svn that creates this environment.
Edit: Added a bounty to the question. I think this is an important issue and it deserves to get more answers. I will consider best those answers with real world examples with particular attention towards any arisen issues and their solution.
Additional questions to inspire for the Bounty:
Do you perform testing on your environment (to check proper installation, e.g. on an integration machine) ?
How do you include your environment at shipping time ? If it's C, do you statically link it, or ship the dynamic library, tinkering the LD_LIBRARY_PATH before running the executable? What about the same issue for python, perl, and other ?
Do you stick to the runtime, or update it as time passes? Do you download "trunk" packages of your dependency libraries or a fixed version?
How do you deal with situations like: library foo needs python 2.5, but you need to develop in python 2.4 because library bar does not work with python 2.5 ?
We use a CMake script that generates Makefiles that download (mainly through SVN)/configure/build all our dependencies. Why CMake? Multiplatform. This works quite well, and we support invocation of scons/autopain/cmake. As we build on several platforms (Windows, MacOSX, a bunch of Linux variants) we also support different compile flags etc based on the operating system. Typically a library has a default configuration, and if we encounter a system that needs special configuration the configuration is replaced with a specialized configuration. This works quite well. We did not really find any ready solution that would fit our purpose.
That being said, it is a PITA to get it up and running - there's a lot of knobs to turn when you need to support several operating systems. I don't think it will become a maintainance-nightmare as the dependencies are quite fixed (libraries are upgraded regularly, but we rarely introduce new one).
virtualenv is good, but it can't do magic - e.g. if you want use a library that just MUST have Python 2.4 and another one that absolutely NEEDS 2.5 instead, you're out of luck. Nor can virtualenv (or any other tool) help when there's a brand new release of an OS and half the tools &c just don't support it yet, as you mentioned for Snow Leopard: some problems are just impossible to solve (two libraries with absolutely conflicting needs within the same build), others just require patience (until all tools you need are ported to the new OS's release, you just need to stick with the previous OS release).