<commit_before>TorqueBox Sidekiq Service
=========================

This library provides a TorqueBox service for running Sidekiq inside the TorqueBox application server.  It replaces the
Sidekiq CLI client typically used to start up TorqueBox.

Rationale
---------

The TorqueBox application server has a lot of features that are only accessible by running within the container.  E.g.,
if your application uses the TorqueBox cache provider you cannot access that cache from an external process, like a
traditional Sidekiq setup.  This can be confusing as something as benign as `Rails.cache` can have different values in
the same environment depending on how the code was invoked.

There are several other reasons why a TorqueBox service may make sense for you:

* Reduced memory consumption, as you'll only be using one JVM
* High availability, as TorqueBox can move a singleton service to any other node in a cluster
* Simpler process management, as Sidekiq will start as part of your normal application deploy
** No need for monit or similar tools in production
** No need for foreman or similar tools in development
* Easier to debug & profile by way of TorqueBox's debugging and profiling capabilities<commit_msg>Added a Travis CI status badge.<commit_after>TorqueBox Sidekiq Service
=========================

This library provides a TorqueBox service for running Sidekiq inside the TorqueBox application server.  It replaces the
Sidekiq CLI client typically used to start up TorqueBox.

[![Build Status](https://secure.travis-ci.org/mogotest/torquebox-sidekiq-service.png)](http://travis-ci.org/mogotest/torquebox-sidekiq-service)

Rationale
---------

The TorqueBox application server has a lot of features that are only accessible by running within the container.  E.g.,
if your application uses the TorqueBox cache provider you cannot access that cache from an external process, like a
traditional Sidekiq setup.  This can be confusing as something as benign as `Rails.cache` can have different values in
the same environment depending on how the code was invoked.

There are several other reasons why a TorqueBox service may make sense for you:

* Reduced memory consumption, as you'll only be using one JVM
* High availability, as TorqueBox can move a singleton service to any other node in a cluster
* Simpler process management, as Sidekiq will start as part of your normal application deploy
** No need for monit or similar tools in production
** No need for foreman or similar tools in development
* Easier to debug & profile by way of TorqueBox's debugging and profiling capabilities
{'fraction_non_alphanumeric': 0.06074586697424068, 'fraction_numerical': 0.0, 'mean_word_length': 4.7312775330396475, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 1, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5461806', 'n_tokens_mistral': 647, 'n_tokens_neox': 620, 'n_words': 368}