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 <j...@greenqloud.com> wrote:
> 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 management server and running out of
> threads. Let's say 10 of these operations are submitted. They all get
> blocked and execute one at a time, per user. If enough users submit
> enough of these requests, what will happen to other requests that
> don't need to be locked? I assume we can configure the management
> server's thread pool size somewhere?
>
> Jeff
>
> On Thu, Jan 29, 2015 at 2:34 PM, Mike Tutkowski
> <mike.tutkow...@solidfire.com> wrote:
> > Like this:
> >
> > GlobalLock lock = GlobalLock.getInternLock(
> > someStringYouMadeUpThatIsUniqueForThisPurpose);
> >
> > if (!lock.lock(timeoutInSeconds)) {
> >
> > s_logger.debug("Couldn't lock the db on the string " +
> > someStringYouMadeUpThatIsUniqueForThisPurpose);
> >
> > throw new CloudRuntimeException("Couldn't acquire DB
> lock");
> >
> > }
> > try {
> >
> > // do your work
> >
> > }
> >
> > finally {
> >
> > lock.unlock();
> >
> > lock.releaseRef();
> >
> > }
> >
> > On Thu, Jan 29, 2015 at 7:32 AM, Mike Tutkowski <
> > mike.tutkow...@solidfire.com> wrote:
> >
> >> 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.tutkow...@solidfire.com> wrote:
> >>
> >>> 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
> >>> " + someStringYouMadeUpThatIsUniqueForThisPurpose);
> >>>
> >>> throw new CloudRuntimeException("Couldn't acquire
> DB
> >>> lock");
> >>>
> >>> }
> >>>
> >>> // do your work
> >>>
> >>> }
> >>>
> >>> finally {
> >>>
> >>> lock.unlock();
> >>>
> >>> lock.releaseRef();
> >>>
> >>> }
> >>>
> >>> On Thu, Jan 29, 2015 at 3:32 AM, Jeff Hair <j...@greenqloud.com>
> wrote:
> >>>
> >>>> 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 wondering if the
> >>>> database locks are the actual appropriate solution rather than what
> >>>> I'm doing.
> >>>>
> >>>> Basically my issue is that I need to lock access to an IP address
> >>>> reserved to the account and perform some long operations on it. I also
> >>>> need to guarantee that no other IPs on the account are manipulated
> >>>> while performing this task. Synchronization accomplishes this because
> >>>> I can force the IP operations through an ExecutorService, but I'm
> >>>> really looking for a better solution that will also work with
> >>>> clustered management servers.
> >>>>
> >>>> Thanks,
> >>>>
> >>>> Jeff
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> *Mike Tutkowski*
> >>> *Senior CloudStack Developer, SolidFire Inc.*
> >>> e: mike.tutkow...@solidfire.com
> >>> o: 303.746.7302
> >>> Advancing the way the world uses the cloud
> >>> <http://solidfire.com/solution/overview/?video=play>*™*
> >>>
> >>
> >>
> >>
> >> --
> >> *Mike Tutkowski*
> >> *Senior CloudStack Developer, SolidFire Inc.*
> >> e: mike.tutkow...@solidfire.com
> >> o: 303.746.7302
> >> Advancing the way the world uses the cloud
> >> <http://solidfire.com/solution/overview/?video=play>*™*
> >>
> >
> >
> >
> > --
> > *Mike Tutkowski*
> > *Senior CloudStack Developer, SolidFire Inc.*
> > e: mike.tutkow...@solidfire.com
> > o: 303.746.7302
> > Advancing the way the world uses the cloud
> > <http://solidfire.com/solution/overview/?video=play>*™*
>
>
>
> --
> Jeff Hair
> Core Systems Developer
>
> Tel: (+354) 415 0200
> j...@greenqloud.com
> www.greenqloud.com
>
--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the cloud
<http://solidfire.com/solution/overview/?video=play>*™*
