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