hsx group repos are open - perm removal integration is complete

[Kelly O'Hair]

So I need some feedback from the hotspot team as to what the behavior should be now.

Assuming we are continuing with the multiple jobs feature of JPRT...  Everybody ok with that???

There is a job queue for each system (all the jobs that were submitted and have not finished).
There is a running queue for each system (all jobs actively building or testing).

The old "rule" has been that any job pushing to the same repository on any queue should not progress (or block) until
the other job completes, this is currently enforced with a lock (directory called "lockdir") in the
NFS area /net/prt-archiver/.../locks. (If anyone has a better lockdir mechanism, please let me know).

I started rejecting jobs that would block a while back because it was severely reducing throughput
for everyone else. Now that JPRT can run multiple jobs, I have alternatives.

I can let the job take up a slot in the running job list, and just let it block, that preserves it's
priority when it does start running for that queue, but I have no easy way to prioritize it against
all other jobs in all the queues, e.g. all that are blocked on the same repo.
If that is acceptable, please let me know.

Currently rejecting it at submit is bad, I agree, I will try and look into fixing that.

-kto

On Sep 17, 2012, at 1:07 PM, Coleen Phillimore wrote:

> 
> Bengt you got a "Could not acquire lock for parent" because I am pushing to hotspot-gc and I think the behavior now is to lock out the second job rather than just integrate.   This should be fixed.
> Also my job has been stuck in the JPRT east queue for 3 hours.  If I kill it and you submit, I'll have to wait for your job again to even start mine.
> Tim's looking at this now.
> 
> Coleen
> 
> On 9/17/2012 4:00 PM, Bengt Rutisson wrote:
>> 
>> On 2012-09-17 21:42, John Coomes wrote:
>>> Vladimir Kozlov (vladimir.kozlov at oracle.com) wrote:
>>>> John, did you unlock repos?
>>> Yes.  The config on the servers looks ok (no restrictions), and Bengt
>>> was able to push to hotspot-gc this morning.
>> 
>> Yes, I was able to push once this morning. But now I also get " Could not acquire lock for parent" when I try to push:
>> 
>> http://prt-web.us.oracle.com//archive/2012/09/2012-09-17-191527.brutisso.hs-gc-g1-gc-timestamp/syslogs/2012-09-17-191527.brutisso.hs-gc-g1-gc-timestamp.log 
>> 
>> Bengt
>> 
>>> 
>>>> > At this point, all the hsx repos will be identical, and *locked*
>>>> > except for perm removal changes.
>>>> 
>>>> I see that few JPRT jobs are filed with:
>>>> 
>>>> "Fail/kill comment:  Could not acquire lock for parent:"
>>> This looks like something strange with jprt.  One of Zhengyu's jobs
>>> (2012-09-14-170744.zhgu.hotspot) is marked as failed, but it actually
>>> pushed the changeset to hotspot-gc, and I don't see any error in the
>>> jprt logs.
>>> 
>>> -John
>>> 
>>>> John Coomes wrote:
>>>>> The perm removal changes have been pushed up to hotspot-main and
>>>>> pulled down into all the hotspot-{group} repos, so the group repos are
>>>>> now open for normal work.  Thanks for your help and patience.
>>>>> 
>>>>> Please avoid pushing to hsx/hotspot-main for a few more days while we
>>>>> run PIT, in case there are some fixes required to allow integration
>>>>> into jdk8.
>>>>> 
>>>>> -John
>>