QoQ Thread Lock

[Andy Jackson]

I responded to this on the railo google groups but thought I'd revie this thread over here:

https://groups.google.com/forum/#!msg/railo/Fsh-uuwE2ic/qtwdydxunaoJ

Here's a quick summary of the issue:

"I'm experiencing a locking issue under load with query of queries that I'm hoping someone may have some insight on. I am able to reproduce the lock on queries that contain a group by or a count clause (there may be other scenarios, but these I can reliably reproduce). Below are two thread dump excerpts, the first from the thread doing the locking, and the second from the locked thread. I'm running 3.3.4.003 final. I'm not quite sure where to go from here. This is hard to reproduce but while under production load. Thank you for your help!"

We're seeing the same problem. When observing the railo server using Fusion Reactor, on occasion we see one request blocking a number of other requests. When looking at each request's stack trace, all open requests are blocking on executeQoQ. Each request thread appears to be attempting to access a lock that is still being held by the first request thread. In our case, the first offending request is running a large QoQ that takes a significant amount of time to complete and therefore creates a backup in any further request threads that attempt to perform a QoQ.

I believe Rory is right that the issue stems from the synchronization lock call on line 324 of HSQLDBHandler.java. Would the code function properly without this lock? What shared resource is being acquired here that requires the lock? Would it be possible to implement this function in a non-blocking way?

Thank you so much for your time!

[Jon Clausen]

Andy,

Looking at your code on the Railo list thread, I see you’re querying an object “request.AppStoreReference.storeProducts”.  Is that, by any chance, being scoped in to REQUEST from a query in the application scope?   If so, it could be that the aggregate function applied to a reference object in the app scope, is causing your severe locking issues under load - especially if numerous references to that app scope object are being created and destroyed simultaneously while the aggregate function is attempting to lock the reference object in the app scope to perform it’s operation.  Just a thought...

Either way, it seems very strange that the aggregate function would require a lock at all, but perhaps there’s an under-the-hood reason for it.

Jon

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/f7c21126-b8be-4002-826d-e86385709a15%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jon Clausen]

Oops. Didn’t look at the names on the thread. It looks like your issue is different than the OP, Rory.  My bad, though I’m still curious as to whether there is scoped reference that is holding up the lock on the subsequent QoQ's.  

The synchronized lock you reference is now on 343 of /lucee-java/lucee-core/src/lucee/runtime/db/HSQLDBHandler.java   I can’t see any reason for that lock to exist, but this issue, for sure, would be worthy of raising an issue or submitting a pull request to remove it.