puzzled by Mutex lock call ..

I have some code that uses and instance of Mutex and calls
@mutex.lock, executes some code and then does
unlock(). When I call lock() I get some ActiveRecord error which seems
unrelated.

Couldn't find ActiveJob with ID=3
["/home/LGuild/.gem/ruby/1.8/gems/activerecord-2.3.5/lib/active_record/
base.rb:1586:in `find_one'", "script/jobmgr.rb:107:in `lock'",

This is on Fedora 12, I haven't a good idea on how to troubleshoot
this ..

I have some code that uses and instance of Mutex and calls
@mutex.lock, executes some code and then does
unlock(). When I call lock() I get some ActiveRecord error which seems
unrelated.

What are you calling lock on / how are you calling it ? There's an
active record method called lock and it looks like you're somehow
ending up calling that

Fred

I do

@mutex = Mutex.new

and then

@mutex.lock
..

@mutex.unlock

Not sure what the purpose of your use of such a mutex lock is in your
app, but if it's something other than restricting access to some
resource amongst some threads handled within a given instance of your
rails app running in some process, .... but in terms of rails, I don't
think a mutex lock will do what you're thinking it will do if your
rails app is running / can run in more than one process (ie via
passenger or via a mongrel cluster or ...).

Assuming you aren't talking about dealing with threads within a given
process, and you really are trying to restrict access to some resource
from potentially multiple process instances of your rails app, then
you'll need to use a locking strategy that can be used in a multi
process context (ie like via your app's db, or potentially via files,
or ...).

Note however that if you are only running one instance or rails, ie a
single instance of webrick or mongrel, then your rails app is
essentially single-threaded (running in a single process) in terms of
requests handling. In such a single-instance setup, you likely
wouldn't need the use of mutex (unless your dealing with threads in
that single process) since your app would only be able to handle one
request at a time anyway.

Jeff

I basically have a job manager that runs with script/runner and is
independent of the webserver. It allows DRB connections, TCP
connections,
and has a scheduling loop. Inside the scheduling loop is where the
error sometimes happens which doesn't seem related to anything I did.

  I haven't worked on this code for awhile, but had not seen these
types of errors when I was running on Centos, I just moved the code to
Fedora ..

jobmgr = JobMgr.new

DRb.start_service('druby://' + jobmgr.ipaddr, jobmgr)

if jobmgr.tcp_port
  Thread.start do
    jobmgr.get_tcp_reqs
  end
end

puts 'run'

jobmgr.run_scheduler

DRb.thread.join

I basically have a job manager that runs with script/runner and is
independent of the webserver. It allows DRB connections, TCP
connections,
and has a scheduling loop. Inside the scheduling loop is where the
error sometimes happens which doesn't seem related to anything I did.

  I haven't worked on this code for awhile, but had not seen these
types of errors when I was running on Centos, I just moved the code to
Fedora ..

jobmgr = JobMgr.new

DRb.start_service('druby://' + jobmgr.ipaddr, jobmgr)

if jobmgr.tcp_port
  Thread.start do
    jobmgr.get_tcp_reqs
  end
end

puts 'run'

jobmgr.run_scheduler

DRb.thread.join

There's clearly something else going on. Can you reduce the code with
the problem to a small sample you can post in its entirety ? What is
the ActiveJob model and does the code exhibiting the problem also
manipulate instances of it ?

Fred