jruby-rack-worker 0.3-jruby → 0.4-jruby

Sign up to get free protection for your applications and to get access to all the features.
data/LICENSE CHANGED
@@ -186,7 +186,7 @@
186
186
  same "printed page" as the copyright notice for easier
187
187
  identification within third-party archives.
188
188
 
189
- Copyright (c) 2010 Karol Bucek
189
+ Copyright (c) 2010-2012 Karol Bucek
190
190
 
191
191
  Licensed under the Apache License, Version 2.0 (the "License");
192
192
  you may not use this file except in compliance with the License.
data/README.md CHANGED
@@ -1,48 +1,47 @@
1
- JRuby Rack Worker
2
- =================
1
+ # JRuby Rack Worker
3
2
 
4
- Java based thread worker implementation over [jruby-rack](http://github.com/nicksieger/jruby-rack).
3
+ Thread based workers on top of [jruby-rack](http://github.com/jruby/jruby-rack).
5
4
 
6
- Natively supports [Delayed::Job](http://github.com/collectiveidea/delayed_job) and
7
- [Navvy](http://github.com/jeffkreeftmeijer/navvy) but one can easily write his own
8
- worker loop.
5
+ With out of the box [JRuby](http://jruby.org) "adapters" for:
9
6
 
7
+ * [Resque](http://github.com/defunkt/resque) (**COMING SOON**)
8
+ * [Delayed::Job](http://github.com/collectiveidea/delayed_job)
9
+ * [Navvy](http://github.com/jeffkreeftmeijer/navvy)
10
10
 
11
- Motivation
12
- ----------
11
+ ... but one can easily write/adapt his own worker loop.
13
12
 
14
- While migrating a rails application to [JRuby](http://jruby.org) I found myself
15
- stuck with [Delayed::Job](http://github.com/collectiveidea/delayed_job). I wanted
16
- to deploy the application without having to spawn a separate daemon process in
17
- another *Ruby* (as *JRuby* is not daemonizable the [daemons](http://daemons.rubyforge.org)
18
- way).
19
13
 
20
- Well, why not spawn a "daemon" thread looping over the jobs from the servlet
21
- container ... after all the java world is inherently thread-oriented !
14
+ ## Motivation
22
15
 
23
- This does have the advantage of keeping the deployment simple and saving some
24
- precious memory (most notably with `threadsafe!` mode) that would have been
25
- eaten by the separate process. Besides Your daemons start benefiting from
26
- JRuby's (as well as Java's) runtime optimalizations ...
16
+ Ruby attempts to stay pretty close to UNIX and most popular workers have been
17
+ modeled the spawn a background process way. [JRuby](http://jruby.org) brings
18
+ Java to the table, where "Young Java Knights" are thought to use threads
19
+ whenever in a need to compute something parallel while serving requests.
20
+
21
+ There's no right or wrong way of doing this. If you do expect chaos like Resque
22
+ proclaims - have long running jobs that consume a lot of memory they have trouble
23
+ releasing (e.g. due C extensions) run a separate process for sure.
24
+ But otherwise (after all C exts usually have a native Java alternative on JRuby)
25
+ having predictable thread-safely written workers, one should be fine with
26
+ running them concurrently as part of the application in a daemon thread.
27
27
 
28
- On the other hand Your jobs should be simple and complete "fast" (in a rate of
29
- seconds rather than several minutes or hours) as they will restart and live with
30
- the lifecycle of the deployed application and/or application server.
28
+ This does have the advantage of keeping the deployment simple and saving some
29
+ precious memory (most notably with `threadsafe!` mode) that would have been
30
+ eaten by the separate process. Besides, your application might warm up faster
31
+ and start benefiting from JRuby's runtime optimalizations slightly sooner ...
31
32
 
32
- Java purist might objects the servlet specification does not advise spawning
33
- daemon threads in a servlet container, objection noted. Whether this style of
34
- asynchronous processing suits Your limits, needs and taste is entirely up to
35
- You.
33
+ On the other hand your jobs should be fairly simple and complete "fast" (in a
34
+ rate of seconds rather than several minutes or hours) as they will live and
35
+ restart with the lifecycle of the deployed application and application server.
36
36
 
37
37
 
38
- Setup
39
- =====
38
+ ## Setup
40
39
 
41
40
  Copy the `jruby-rack-worker.jar` into the `lib` folder or the directory being
42
41
  mapped to `WEB-INF/lib` e.g. `lib/java`.
43
42
 
44
- Configure the worker in `web.xml`, You'll need to add a servlet context listener
45
- that will start threads when You application boots and a script to be executed
43
+ Configure the worker in `web.xml`, you'll need to add a servlet context listener
44
+ that will start threads when your application boots and a script to be executed
46
45
  (should be an "endless" loop-ing script). Sample configuration :
47
46
 
48
47
  <context-param>
@@ -57,55 +56,81 @@ that will start threads when You application boots and a script to be executed
57
56
  <listener-class>org.kares.jruby.rack.WorkerContextListener</listener-class>
58
57
  </listener>
59
58
 
60
- **NOTE**: The `WorkerContextListener` needs to be executed (and thus configured)
61
- after the `RailsServletContextListener`/`RackServletContextListener` as it expects
62
- the *jruby-rack* environment to be available.
59
+ The `WorkerContextListener` needs to be executed (and thus configured) after the
60
+ `RailsServletContextListener`/`RackServletContextListener` as it expects the
61
+ *jruby-rack* environment to be available.
63
62
 
64
- **NOTE**: If You're not using `threadsafe!` than You really **should** ...
63
+ Sample deployment descriptor including optional parameters:
64
+ [web.xml](/kares/jruby-rack-worker/blob/master/src/test/resources/sample.web.xml).
65
65
 
66
- **NOTE**: If You're still not using `threadsafe!` mode than You're polling several
67
- (non-thread-safe) JRuby runtimes instances while serving requests, the *workers
68
- are nor running as a part of the application* thus each worker thread will remove
69
- and use (block) an application runtime from the instance pool (consider it while
70
- setting the `jruby.min.runtimes`/`jruby.max.runtimes` parameters) !
66
+ ### Warbler
71
67
 
72
- Sample Rails `web.xml` usable with [Warbler](http://caldersphere.rubyforge.org/warbler)
73
- including optional configuration parameters
74
- [web.xml](/kares/jruby-rack-worker/blob/master/src/test/resources/warbler.web.xml).
68
+ If you're using [Warbler](http://caldersphere.rubyforge.org/warbler) to assemble
69
+ your application you might simply declare a gem dependency with Bundler as your
70
+ gems will be scanned for jars and packaged correctly:
75
71
 
76
- A simpler configuration using the built-in `Delayed::Job` / `Navvy` support :
72
+ gem 'jruby-rack-worker', :platform => :jruby, :require => nil
77
73
 
78
- <context-param>
79
- <param-name>jruby.worker</param-name>
80
- <param-value>delayed_job</param-value> <!-- or navvy -->
81
- </context-param>
74
+ Otherwise copy the jar into your *warble.rb* configured `config.java_libs`.
82
75
 
83
- <listener>
84
- <listener-class>org.kares.jruby.rack.WorkerContextListener</listener-class>
85
- </listener>
76
+ Warbler checks for a *config/web.xml.erb* thus configure the worker there, e.g. :
86
77
 
78
+ <!DOCTYPE web-app PUBLIC
79
+ "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
80
+ "http://java.sun.com/dtd/web-app_2_3.dtd">
81
+ <web-app>
82
+ <% webxml.context_params.each do |k,v| %>
83
+ <context-param>
84
+ <param-name><%= k %></param-name>
85
+ <param-value><%= v %></param-value>
86
+ </context-param>
87
+ <% end %>
87
88
 
88
- Build
89
- =====
89
+ <filter>
90
+ <filter-name>RackFilter</filter-name>
91
+ <filter-class>org.jruby.rack.RackFilter</filter-class>
92
+ </filter>
93
+ <filter-mapping>
94
+ <filter-name>RackFilter</filter-name>
95
+ <url-pattern>/*</url-pattern>
96
+ </filter-mapping>
90
97
 
91
- [JRuby](http://jruby.org) 1.5+ is required to build the project.
92
- The build is performed by [rake](http://rake.rubyforge.org) which should be part
93
- of the JRuby installation, if You're experiencing conflicts with another Ruby and
94
- it's rake executable use `jruby -S rake` instead of the bare `rake` command.
98
+ <listener>
99
+ <listener-class><%= webxml.servlet_context_listener %></listener-class>
100
+ </listener>
95
101
 
96
- Build the `jruby-rack-worker.jar` using :
102
+ <% if webxml.jndi then [webxml.jndi].flatten.each do |jndi| %>
103
+ <resource-ref>
104
+ <res-ref-name><%= jndi %></res-ref-name>
105
+ <res-type>javax.sql.DataSource</res-type>
106
+ <res-auth>Container</res-auth>
107
+ </resource-ref>
108
+ <% end; end %>
97
109
 
98
- rake jar
110
+ <!-- jruby-rack-worker setup using the built-in libraries support : -->
99
111
 
100
- Build the gem (includes the jar) :
112
+ <context-param>
113
+ <param-name>jruby.worker</param-name>
114
+ <param-value>delayed_job</param-value> <!-- or resque or navvy -->
115
+ </context-param>
101
116
 
102
- rake gem
117
+ <listener>
118
+ <listener-class>org.kares.jruby.rack.WorkerContextListener</listener-class>
119
+ </listener>
120
+
121
+ </web-app>
103
122
 
104
- Run the tests with :
105
123
 
106
- rake test
124
+ If you're deploying a Rails application on JRuby it's highly **recommended** to
125
+ uncomment `config.threadsafe!`. Otherwise, if unsure or you're code is not
126
+ thread-safe yet you'll end up polling several JRuby runtimes in a single process,
127
+ in this case however each worker thread will use (block) an application runtime
128
+ from the pool (consider it while setting
129
+ `jruby.min.runtimes` and `jruby.max.runtimes` parameters).
107
130
 
108
131
 
132
+ ### Custom Workers
133
+
109
134
  Worker Migration
110
135
  ================
111
136
 
@@ -117,17 +142,35 @@ most probably need to start by looking at the current worker spawning script
117
142
  * avoid native gems such as daemons (in DJ's case this means avoiding the whole
118
143
  `Delayed::Command` implementation)
119
144
 
120
- * remove command line processing - all Your configuration should happen in an
145
+ * remove command line processing - all your configuration should happen in an
121
146
  application initializer or the `web.xml`
122
147
 
123
- * make sure the worker code is thread-safe in case Your application is running
148
+ * make sure the worker code is thread-safe in case your application is running
124
149
  in `threadsafe!` mode (make sure no global state is changing by the worker or
125
150
  class variables are not being used to store worker state)
126
151
 
127
- * refactor Your worker's exit code from a (process oriented) signal based `trap`
128
- to `at_exit` - which respects better the JRuby environment Your workers are
152
+ * refactor your worker's exit code from a (process oriented) signal based `trap`
153
+ to `at_exit` - which respects better the JRuby environment your workers are
129
154
  going to run in
130
155
 
131
156
 
132
157
  See the [Delayed::Job](/kares/jruby-rack-worker/tree/master/src/main/ruby/delayed)
133
158
  JRuby "adapted" worker code for inspiration.
159
+
160
+
161
+ ## Build
162
+
163
+ [JRuby](http://jruby.org) 1.5+ is required to build the project.
164
+ The build is performed by [rake](http://rake.rubyforge.org) which should be part
165
+ of your JRuby installation, if you're experiencing conflicts with another Ruby and
166
+ it's rake executable use `jruby -S rake` instead of the bare `rake` command.
167
+ Besides you'll to need [ant](http://ant.apache.org/) installed for the Java part.
168
+
169
+ Build the `jruby-rack-worker.jar` using :
170
+
171
+ rake jar
172
+
173
+ Build the gem (with the jar packaged) :
174
+
175
+ rake gem
176
+
Binary file
@@ -1,7 +1,7 @@
1
1
  module JRuby
2
2
  module Rack
3
3
  module Worker
4
- VERSION = '0.3'
4
+ VERSION = '0.4'
5
5
  end
6
6
  end
7
7
  end
metadata CHANGED
@@ -2,7 +2,7 @@
2
2
  name: jruby-rack-worker
3
3
  version: !ruby/object:Gem::Version
4
4
  prerelease:
5
- version: "0.3"
5
+ version: "0.4"
6
6
  platform: jruby
7
7
  authors:
8
8
  - Karol Bucek
@@ -10,8 +10,7 @@ autorequire:
10
10
  bindir: bin
11
11
  cert_chain: []
12
12
 
13
- date: 2011-04-24 00:00:00 +02:00
14
- default_executable:
13
+ date: 2012-07-05 00:00:00 Z
15
14
  dependencies:
16
15
  - !ruby/object:Gem::Dependency
17
16
  name: jruby-rack
@@ -21,10 +20,10 @@ dependencies:
21
20
  requirements:
22
21
  - - ">="
23
22
  - !ruby/object:Gem::Version
24
- version: 1.0.1
23
+ version: 1.1.1
25
24
  type: :runtime
26
25
  version_requirements: *id001
27
- description: Implements a thread based worker using JRuby-Rack (a.k.a. Delayed Job for Java). Usable in servlet containers.
26
+ description: Implements a thread based worker pattern on top of JRuby-Rack. Useful if you'd like to run a worker loop (such as Delayed::Job or Resque) as part of your web-application (concurrently in a separate thread) instead of using a separate process. To be used with a servlet containers.
28
27
  email:
29
28
  - self@kares.org
30
29
  executables: []
@@ -36,10 +35,9 @@ extra_rdoc_files: []
36
35
  files:
37
36
  - README.md
38
37
  - LICENSE
38
+ - lib/jruby-rack-worker_0.4.jar
39
39
  - lib/jruby_rack_worker.rb
40
- - lib/jruby-rack-worker_0.3.jar
41
40
  - lib/jruby/rack/worker/version.rb
42
- has_rdoc: true
43
41
  homepage: http://github.com/kares/jruby-rack-worker
44
42
  licenses: []
45
43
 
@@ -62,10 +60,10 @@ required_rubygems_version: !ruby/object:Gem::Requirement
62
60
  version: "0"
63
61
  requirements: []
64
62
 
65
- rubyforge_project:
66
- rubygems_version: 1.5.1
63
+ rubyforge_project: "[none]"
64
+ rubygems_version: 1.8.15
67
65
  signing_key:
68
66
  specification_version: 3
69
- summary: Simple Worker for JRuby-Rack
67
+ summary: Simple Worker with JRuby-Rack
70
68
  test_files: []
71
69
 
Binary file