Re: ERROR cannot read info: lock timeout exceeded

[Tim Penhey]

On 26/09/15 22:02, Mark Shuttleworth wrote:
> On 25/09/15 15:43, Tim Van Steenburgh wrote:
>>
>>> Generating separate JUJU_HOMEs will insulate your from bug
>>> https://bugs.launchpad.net/juju-core/+bug/1467331
>>
>> Thanks, I'm going to try this approach and see what happens. Although, it
>> seems
>> to me that if it's safe to have multiple JUJU_HOMEs, all "doing stuff"
>> concurrently,
>> it would also be possible to have one lock per env, instead of one global
>> lock. Can
>> anyone on the core team explain why there is one global lock? I'm just
>> curious.
> 
> Also, is there is any implication for the new multi-environment Juju
> servers?

This is all client side caching of information. Nothing to do with the
server side.

Tim


-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju

Re: ERROR cannot read info: lock timeout exceeded

[Tim Penhey]

The code does just hold the lock for the duration of the read or write.

Since it is possible to have multiple environments sharing a server, and
the server data, the access to that data is synchronized.

There *shouldn't* be a case where the lock is held but not released.

The lock file itself should hold some information about who locked it
and why.

Tim

On 26/09/15 18:43, John Meinel wrote:
> I don't know the concrete details here, but I do believe there are a few
> files that are shared in one JUJU_HOME. There is only one
> environments.yaml and the new multi-environment code means there is
> another shared file that holds the list of known servers and environments.
> I would hope that the code would not hold the lock for the lifetime of
> the process but only do a "grab the lock, read, update, write, release
> the lock". But I don't know that code, so there might have been some
> other thoughts there.
> 
> John
> =:->
> 
> On Sep 25, 2015 5:44 PM, "Tim Van Steenburgh"
>  > wrote:
> 
> 
> On Fri, Sep 25, 2015 at 9:56 AM, Curtis Hovey-Canonical
> > wrote:
> 
> On Fri, Sep 25, 2015 at 9:15 AM, Tim Van Steenburgh
>  > wrote:
> > Hi everyone,
> >
> > I have a jenkins slave that's running charm and bundle tests on 5 
> different
> > clouds pretty much all the time. My problem is that tests will 
> randomly fail
> > after hitting this lock timeout.
> 
> Juju QA has pondered deleting any lock more than a minute old every
> time we call the client to bootstrap or destroy-environment.
> 
> 
> This is a good idea and probably worth doing, although it won't fix
> our most common
> failure, where a test run bootstraps successfully, but then fails
> later when *another*
> env bootstraps just before the running test tries to execute a juju
> command.
>  
> 
> 
> > Is the best way around this to have a separate $JUJU_HOME for all 
> my test
> > clouds, so that I end up with one lock per cloud? I haven't tried 
> this yet
> > but it seems like the simplest way forward, if it works and is safe 
> (is
> > it?).
> 
> Generating separate JUJU_HOMEs will insulate your from bug
> https://bugs.launchpad.net/juju-core/+bug/1467331
> 
> 
> Thanks, I'm going to try this approach and see what happens.
> Although, it seems
> to me that if it's safe to have multiple JUJU_HOMEs, all "doing
> stuff" concurrently,
> it would also be possible to have one lock per env, instead of one
> global lock. Can
> anyone on the core team explain why there is one global lock? I'm
> just curious.
> 
> 
> 
> 
> 
> --
> Curtis Hovey
> Canonical Cloud Development and Operations
> http://launchpad.net/~sinzui
> 
> 
> 
> --
> Juju mailing list
> Juju@lists.ubuntu.com 
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/juju
> 
> 
> 


-- 
Juju mailing list
Juju@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/juju