Jruby (1.7.5) + MSSQL-2012 + torquebox 2.2.0 DB issue

39 Views Asked by At

I have Jruby on rails Jruby (1.7.5) + MSSQL-2012 + torquebox 2.2.0 + Rails-2.3.18. The application got connected to the database without any problem.

I am installed active-recorder-jdbc (1.2.8) * active-record-mssql-jdbc (2.8.1)

The issue is If i made any DB hit even to fetch Single row . It would take to finish the request around Completed in 938504ms (View: 4, DB: 938497) | 200 OK The request took nearly 15 min to complete .

But in the front end UI . I got the apache Timeout error . How can i detect the problem and fix this.

I took the Thread dump and all. It shows like below

  • parking to wait for <0x00000000fc85dbe8> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireInterruptibly(AbstractQueuedSynchronizer.java:894) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1221) at java.util.concurrent.locks.ReentrantLock.lockInterruptibly(ReentrantLock.java:340) at org.jruby.RubyThread.lockInterruptibly(RubyThread.java:1461) at org.jruby.ext.thread.Mutex.lock(Mutex.java:91) at org.jruby.ext.thread.Mutex.synchronize(Mutex.java:147) at org.jruby.ext.thread.Mutex$INVOKER$i$0$0$synchronize.call(Mutex$INVOKER$i$0$0$synchronize.gen) at org.jruby.runtime.callsite.CachingCallSite.callBlock(CachingCallSite.java:143) at org.jruby.runtime.callsite.CachingCallSite.callIter(CachingCallSite.java:154) at org.jruby.ast.CallNoArgBlockNode.interpret(CallNoArgBlockNode.java:64) at org.jruby.ast.NewlineNode.interpret(NewlineNode.java:105)
1

There are 1 best solutions below

0
On

seems like there might be a dead-lock or more likely some heavy contention (on newer JRuby 1.7.x you might see more useful traces in the dump) ... esp. AR's pool in 2.3 is not performing well concurrently. consider back-porting the pool from a newer versions, also be aware if using AR sessions that there's a nasty bug with the pool and the session-store being involved.