[
https://issues.apache.org/jira/browse/HIVE-19077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16437916#comment-16437916
]
Vihang Karajgaonkar commented on HIVE-19077:
--------------------------------------------
You might want to try uploading the same version of the patch until we find a
better solution to this JIRA. That way you will not lose the position in the
queue and ptest will only once run with the latest patch attached. May be a
better solution for this patch could be to improve pre-commit admin job to not
add the patch to the queue if it already is pending. That way the precommit job
will run once with the latest version of the patch at the time when its ready
to run.
For instance in this case without the patch, jenkins would have run a
pre-commit job for all the times you re-attached but always with the same last
version of patch attached. That would have wasted lot of time and resources
testing essentially same patch.
> Handle duplicate ptests requests standing in queue at the same time
> -------------------------------------------------------------------
>
> Key: HIVE-19077
> URL: https://issues.apache.org/jira/browse/HIVE-19077
> Project: Hive
> Issue Type: Improvement
> Components: Testing Infrastructure
> Reporter: Adam Szita
> Assignee: Adam Szita
> Priority: Blocker
> Fix For: 3.1.0
>
> Attachments: HIVE-19077.0.patch, HIVE-19077.1.patch,
> HIVE-19077.sslFix.patch
>
>
> I've been keeping on eye on our {{PreCommit-HIVE-Build}} job, and what I
> noticed that sometimes huge queues can build up, that contain jira's more
> than once. (Yesterday I've seen a queue of 40, having 31 distinct jiras..)
> Simple scenario is that I upload a patch, it gets queued for ptest (already
> long queue), and 3 hours later I will update it, re-upload and re-queue. Now
> the current ptest infra seems to be smart enough to always deal with the
> latest patch, so what will happen is that the same patch will be tested 2
> times (with ~3 hours) diff, most probably with same result.
> I propose we do some deduplication - if ptest starts running the request for
> Jira X, then it can take a look on the current queue, and see if X is there
> again. If so, it can skip for now, it will be picked up later anyway.
> In practice this means that if you reconsider your patch and update it, your
> original place in the queue will be gone (like as a penalty for changing it),
> but overall it saves resources for the whole community.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
