Hey all, fairly new to Rails and definitely new to BackgrounDRB, thanks for
your hard work.
However, I''m curious about incompatibilities between the latest stable
release of bdrb (from the svn mirror) and mac os x. I''ve got (nearly)
identical setups on a Debian Etch and Mac OS X 10.5.3 system running rails
2.1.0, ruby 1.8.6 (2008-03-03 patchlevel 114), latest stable versions of
packet and chronic. The attached (mirrored at
http://www.sendspace.com/file/ulw9o2) rails project, which has a simple demo
ProgressWorker, demonstrates my concerns.
Running ./script/backgroundrb, and then in the console typing
MiddleMan.worker(:progress_worker).ask_result(:worker) produces different
results. On the debian system it produces the expected result, while mac
reports:
NoMethodError: You have a nil object when you didn''t expect it!
You might have expected an instance of ActiveRecord::Base.
The error occurred while evaluating nil.[]
from.../vendor/plugins/backgroundrb/lib/backgroundrb/bdrb_connection.rb:151:in
`ask_result''
from
.../vendor/plugins/backgroundrb/lib/backgroundrb/rails_worker_proxy.rb:78:in
`ask_result''
from
.../vendor/plugins/backgroundrb/lib/backgroundrb/rails_worker_proxy.rb:78:in
`map''
from
.../vendor/plugins/backgroundrb/lib/backgroundrb/rails_worker_proxy.rb:78:in
`ask_result''
from (irb):1
Has anyone else experienced this? Is this a known bug? Are there other
differences in threading between OSs? I develop on a mac and the production
server is Debian, so I''m curious as to what to expect...Any guidance
would
be appreciated.
Thanks -pbaker
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080731/bc13d2ad/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bdrb_test.tgz
Type: application/x-gzip
Size: 141564 bytes
Desc: not available
URL:
<http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080731/bc13d2ad/attachment-0001.tgz>
I was hoping to avoid introducing another dependency with memcached, but I''ll consider it. I guess my question should be more pointed. The test case seems to evaluate basic functionality, which appears not to work. Have others experienced this bug (on mac os)? Or is it likely that this is a configuration dependent bug? Has this been addressed in the git version of bdrb? Is a stable version of bdrb that works on mac os forthcoming? -pbaker On 7/31/08, hemant <gethemant at gmail.com> wrote:> > On Thu, Jul 31, 2008 at 1:52 PM, hemant <gethemant at gmail.com> wrote: > > On Thu, Jul 31, 2008 at 10:53 AM, P Baker <me at retrodict.com> wrote: > >> Hey all, fairly new to Rails and definitely new to BackgrounDRB, thanks > for > >> your hard work. > >> > >> However, I''m curious about incompatibilities between the latest stable > >> release of bdrb (from the svn mirror) and mac os x. I''ve got (nearly) > >> identical setups on a Debian Etch and Mac OS X 10.5.3 system running > rails > >> 2.1.0, ruby 1.8.6 (2008-03-03 patchlevel 114), latest stable versions of > >> packet and chronic. The attached (mirrored at > >> http://www.sendspace.com/file/ulw9o2) rails project, which has a simple > demo > >> ProgressWorker, demonstrates my concerns. > >> > >> Running ./script/backgroundrb, and then in the console typing > >> MiddleMan.worker(:progress_worker).ask_result(:worker) produces > different > >> results. On the debian system it produces the expected result, while mac > >> reports: > >> > >> NoMethodError: You have a nil object when you didn''t expect it! > >> You might have expected an instance of ActiveRecord::Base. > >> The error occurred while evaluating nil.[] > >> > >> > from.../vendor/plugins/backgroundrb/lib/backgroundrb/bdrb_connection.rb:151:in > >> `ask_result'' > >> from > >> > .../vendor/plugins/backgroundrb/lib/backgroundrb/rails_worker_proxy.rb:78:in > >> `ask_result'' > >> from > >> > .../vendor/plugins/backgroundrb/lib/backgroundrb/rails_worker_proxy.rb:78:in > >> `map'' > >> from > >> > .../vendor/plugins/backgroundrb/lib/backgroundrb/rails_worker_proxy.rb:78:in > >> `ask_result'' > >> from (irb):1 > >> > >> Has anyone else experienced this? Is this a known bug? Are there other > >> differences in threading between OSs? I develop on a mac and the > production > >> server is Debian, so I''m curious as to what to expect...Any guidance > would > >> be appreciated. > >> > > > > Well, there are some issues if you are dynamically starting workers > > using MiddleMan.new_worker on OSX, but your code should work without > > any problems on OSX. > > > Also, use memcache for result storage, configuration is rather simple: > > http://backgroundrb.rubyforge.org/workers/ > > It will give you much better stability and results. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080731/5ef946f9/attachment.html>
On Thu, Jul 31, 2008 at 4:59 PM, P Baker <me at retrodict.com> wrote:> I was hoping to avoid introducing another dependency with memcached, but > I''ll consider it. > > I guess my question should be more pointed. The test case seems to evaluate > basic functionality, which appears not to work. Have others experienced this > bug (on mac os)? Or is it likely that this is a configuration dependent bug? > Has this been addressed in the git version of bdrb? Is a stable version of > bdrb that works on mac os forthcoming? >Oh, please run git version. I am bad at syncing code with svn (And yes there has been fixes that went into git, but aren''t there in svn).
On Thu, Jul 31, 2008 at 4:59 PM, P Baker <me at retrodict.com> wrote:> I was hoping to avoid introducing another dependency with memcached, but > I''ll consider it. >Well, think in long run, assuming your workers store hundreds of thousands of objects in worker cache. How will Ruby take that? I bet, half the time will be spent in trying to garbage collect the shit. So, if you are planning to cache results at all, memcache is certainly far better solution. Of course, you can keep using inbuilt cache, but it will scale only so such.
Ok. So I upgraded to the git version of backgroundrb and now experience the same results on mac 10.5.3 and debian. The problem is that ask_result doesn''t seem to work at all. Hemant, is the move towards using memcached for passing results/status queries a sign that native ruby handling of that will be (is?) deprecated? -pbaker On 7/31/08, hemant <gethemant at gmail.com> wrote:> > On Thu, Jul 31, 2008 at 6:26 PM, P Baker <me at retrodict.com> wrote: > > Granted there is inherent scalability problems in Ruby. I''m not really > > planning on storing more than status markers in the cache. I''m so > reluctant > > to implement memcached on our stack because I don''t see the need for it > at > > this point. I can see the argument for large scale websites and the need > to > > pass such large numbers of objects, but I don''t think I fit into either > of > > those categories. > > > > I''ve read your hints on debugging backgroundrb, which suggested running > the > > git version, although I''m also looking for stability. What is the > stability > > like of the master git branch? Since that requires the git version of > > packet, what''s the stability of ''edge'' packet? > > > For running git version of backgroundrb you don''t need git version of > packet. Latest gem will do. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080731/b8317e31/attachment.html>
Or...I need to spell things correctly. My mistake. ask_result definitely works. Thanks for your comments hemant. -pbaker On 7/31/08, P Baker <me at retrodict.com> wrote:> > Ok. So I upgraded to the git version of backgroundrb and now experience the > same results on mac 10.5.3 and debian. The problem is that ask_result > doesn''t seem to work at all. Hemant, is the move towards using memcached for > passing results/status queries a sign that native ruby handling of that will > be (is?) deprecated? > > -pbaker > > On 7/31/08, hemant <gethemant at gmail.com> wrote: >> >> On Thu, Jul 31, 2008 at 6:26 PM, P Baker <me at retrodict.com> wrote: >> > Granted there is inherent scalability problems in Ruby. I''m not really >> > planning on storing more than status markers in the cache. I''m so >> reluctant >> > to implement memcached on our stack because I don''t see the need for it >> at >> > this point. I can see the argument for large scale websites and the need >> to >> > pass such large numbers of objects, but I don''t think I fit into either >> of >> > those categories. >> > >> > I''ve read your hints on debugging backgroundrb, which suggested running >> the >> > git version, although I''m also looking for stability. What is the >> stability >> > like of the master git branch? Since that requires the git version of >> > packet, what''s the stability of ''edge'' packet? >> >> >> For running git version of backgroundrb you don''t need git version of >> packet. Latest gem will do. >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/backgroundrb-devel/attachments/20080731/e2c6bd9f/attachment.html>