Does anyone know where such a setting might be stored (maximum number of
threads the job queue can use at a time)?
Thanks!
On Tue, Feb 3, 2015 at 4:11 AM, Jeff Hair wrote:
> Hi,
>
> I've tried this and from our testing thus far it appears to do the
> job. In fact the synchronization code I wrot
Hi,
I've tried this and from our testing thus far it appears to do the
job. In fact the synchronization code I wrote didn't really do the job
(was storing a bunch of single-threaded ExecutorServices, one per
user--but still noticed conflicts at the end).
One concern I have though is the managemen
Hi,
That looks like it will work for my purposes. When I have the time to
continue the task I was working on yesterday I will try this way.
Jeff
On Thu, Jan 29, 2015 at 2:34 PM, Mike Tutkowski
wrote:
> Like this:
>
> GlobalLock lock = GlobalLock.getInternLock(
> someStringYouMadeUpT
Like this:
GlobalLock lock = GlobalLock.getInternLock(
someStringYouMadeUpThatIsUniqueForThisPurpose);
if (!lock.lock(timeoutInSeconds)) {
s_logger.debug("Couldn't lock the db on the string " +
someStringYouMadeUpThatIsUniqueForThisPurpose);
I wrote that example code from memory, but now that I think about it, you
wouldn't call the lock method in the try block.
Call lock and if you're successful, entry a try block to do your work and
have a finally to unlock and release the lock.
On Thu, Jan 29, 2015 at 7:27 AM, Mike Tutkowski <
mike
Does this work for you?
GlobalLock lock = GlobalLock.getInternLock(
someStringYouMadeUpThatIsUniqueForThisPurpose);
try {
if (!lock.lock(timeoutInSeconds)) {
s_logger.debug("Couldn't lock the db on the string " +
someStringYouMadeUpTha
I have some code I've added to CloudStack that I am currently
synchronizing on in the traditional manner (synchronized block,
ExecutorService, etc). I'm currently running a single instance of
CloudStack so I don't have to deal with clustering.
I've read the Data Access Layer documentation and am w
