hsx group repos are open - perm removal integration is complete

[Kelly O'Hair]

On Sep 17, 2012, at 2:15 PM, Coleen Phillimore wrote:

> 
> 
> On 9/17/2012 4:54 PM, Kelly O'Hair wrote:
>> 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???
> 
> Love it!
>> 
>> 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).
> 
> It has to be global somewhere.

Yup.

>> 
>> 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 didn't notice this change.   Maybe it's not as frequent as it has been today.
>> 
>> 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.
> 
> 
> Are you saying that if one job is running and there are more than one blocked for the same repository, it's really just luck which one gets the lock next?  I think that's fine.   The queue length for any given repository won't be that long so it won't be starved, and watching the queue to resubmit is a real pain.
> If there is a non-trivial merge, you kick out the job, right?

Correct. But that won't happen until it starts the job for real. doing the sync up.

-kto

> 
>> 
>> Currently rejecting it at submit is bad, I agree, I will try and look into fixing that.
> Thank you!
> Coleen
> 
>> -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