[JIRA] (JENKINS-57870) Request too large for server memory since 10.1.0

21 views
Skip to first unread message

kwirth@perforce.com (JIRA)

unread,
Jun 20, 2019, 11:59:03 AM6/20/19
to jenkinsc...@googlegroups.com
Karl Wirth updated an issue
 
Jenkins / Bug JENKINS-57870
Request too large for server memory since 10.1.0
Change By: Karl Wirth
Summary: populate: previewOnly(quiet: true) fail Request too large for server memory since 10.1.0
Add Comment Add Comment
 
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

delikat.mateusz@gmail.com (JIRA)

unread,
Jun 28, 2019, 6:33:02 AM6/28/19
to jenkinsc...@googlegroups.com
Mateusz Delikat commented on Bug JENKINS-57870
 
Re: Request too large for server memory since 10.1.0

Karl Wirth, Paul Allen: Why are we actually seeing 
02:02:59 p4 changes -m1 -ssubmitted //jenkins-SE-SWARM_AT_SA-21-se-swarm-at-sa-sv1sw-klt6z/...02:02:59
02:02:59 Change 2688516 on 2019/06/05 by sj828...@sj8282.park_NOVUS_TASK_SVR19A_mare03 'Add Test Case Template with reg'
and then

02:02:59* (p4):cmd:... p4 changes -m1 -ssubmitted //jenkins-SE-SWARM_AT_SA-21-se-swarm-at-sa-sv1sw-klt6z/.__02:02:59 p4 changes -m1 -ssubmitted //jenkins-SE-SWARM_AT_SA-21-se-swarm-at-sa-sv1sw-klt6z/...@2688516*
when we already know the change number from the first call?

On our end we don't have "Request too large" errors but the first command on our stream takes about 1 second to complete and the second often takes more than 10 minutes. Does the plugin really needs to re-verify that changelist? Won't it be always the same?

 

delikat.mateusz@gmail.com (JIRA)

unread,
Jun 28, 2019, 6:33:03 AM6/28/19
to jenkinsc...@googlegroups.com
Mateusz Delikat edited a comment on Bug JENKINS-57870
[~p4karl] {color:#172b4d} , {color} [~p4paul] {color : #172b4d}: Why are we actually seeing  {color}
{code:java}
02:02:59 p4 changes -m1 -ssubmitted //jenkins-SE-SWARM_AT_SA-21-se-swarm-at-sa-sv1sw-klt6z/...02:02:59
02:02:59 Change 2688516 on 2019/06/05 by sj828...@sj8282.park_NOVUS_TASK_SVR19A_mare03 'Add Test Case Template with reg' {code}

{color:#009100} and then {color }
{color
:#172b4d} and then
{color}
{
color code:java }
02:02:59* (p4):cmd:... p4 changes -m1 -ssubmitted //jenkins-SE-SWARM_AT_SA-21-se-swarm-at-sa-sv1sw-klt6z/.__02:02:59 p4 changes -m1 -ssubmitted //jenkins-SE-SWARM_AT_SA-21-se-swarm-at-sa-sv1sw-klt6z/...@2688516*
{code}
{color:#172b4d}

when we already know the change number from the first call?


On our end we don't have "Request too large" errors but the first command on our stream takes about 1 second to complete and the second often takes more than 10 minutes. Does the plugin really needs to re-verify that changelist? Won't it be always the same?{color}

{color:#
172b4d}{color:# 009100} {color} {color}

delikat.mateusz@gmail.com (JIRA)

unread,
Jun 28, 2019, 6:34:02 AM6/28/19
to jenkinsc...@googlegroups.com
Mateusz Delikat edited a comment on Bug JENKINS-57870
[~p4karl]{color:#172b4d}, {color}[~p4paul]{color:#172b4d}: Why are we actually seeing {color}
{code:java}
02:02:59 p4 changes -m1 -ssubmitted //jenkins-SE-SWARM_AT_SA-21-se-swarm-at-sa-sv1sw-klt6z/...02:02:59
02:02:59 Change 2688516 on 2019/06/05 by sj828...@sj8282.park_NOVUS_TASK_SVR19A_mare03 'Add Test Case Template with reg'{code}

{color:#009100}and then{color}
{
color:#172b4d}
{color}
{
code:java}

02:02:59* (p4):cmd:... p4 changes -m1 -ssubmitted //jenkins-SE-SWARM_AT_SA-21-se-swarm-at-sa-sv1sw-klt6z/.__02:02:59
p4 changes -m1 -ssubmitted //jenkins-SE-SWARM_AT_SA-21-se-swarm-at-sa-sv1sw-klt6z/...@2688516*{code}
{color:#172b4d}
when we already know the change number from the first call?

On our end we don't have "Request too large" errors but the first command on our stream takes about 1 second to complete and the second often takes more than 10 minutes. Does the plugin really needs to re-verify that changelist? Won't it be always the same?{color}

{color:#172b4d} {color:#009100}  {color} {color}

kwirth@perforce.com (JIRA)

unread,
Jun 28, 2019, 6:43:02 AM6/28/19
to jenkinsc...@googlegroups.com

Mateusz Delikat - I have been working with this with Paul and it looks like Jenkins is going through an unexpected path to trigger the command (we provide hooks and jenkins chooses which one's to call).

We are still looking into this but it may be that we don't have enough contextually information when Jenkins calls the second instance to decide if the command needs to be run or not.

pallen@perforce.com (JIRA)

unread,
Jun 28, 2019, 11:07:03 AM6/28/19
to jenkinsc...@googlegroups.com

kwirth@perforce.com (JIRA)

unread,
Jul 1, 2019, 11:00:04 AM7/1/19
to jenkinsc...@googlegroups.com
Karl Wirth updated an issue
Change By: Karl Wirth
Labels: P4_SUPPORT P4_VERIFY

kwirth@perforce.com (JIRA)

unread,
Jul 1, 2019, 11:00:05 AM7/1/19
to jenkinsc...@googlegroups.com
Karl Wirth assigned an issue to Unassigned
Change By: Karl Wirth
Assignee: Karl Wirth

kwirth@perforce.com (JIRA)

unread,
Jul 17, 2019, 12:21:03 PM7/17/19
to jenkinsc...@googlegroups.com
Karl Wirth resolved as Fixed
 

Test patch released.

Change By: Karl Wirth
Status: Open Resolved
Resolution: Fixed

kwirth@perforce.com (JIRA)

unread,
Jul 17, 2019, 12:21:03 PM7/17/19
to jenkinsc...@googlegroups.com
Karl Wirth commented on Bug JENKINS-57870
 
Re: Request too large for server memory since 10.1.0

Have released a test patch version to fix the "Request too large for memory" problem. Instead of running 'p4 changes -m1' it now runs for the last N changes:
  
    p4 changes m1 -ssubmitted //jenkins-masterJENKINS-57870-changes-m1-0/...@27+23784,273+3784

N is a configurable variable that can be set under:

  Jenkins > Manage Jenkins > Configure System >  Head change query limit

 

The test patch can be downloaded from: https://ci.jenkins.io/job/Plugins/job/p4-plugin/job/master/

pallen@perforce.com (JIRA)

unread,
Jul 23, 2019, 10:27:02 AM7/23/19
to jenkinsc...@googlegroups.com

pallen@perforce.com (JIRA)

unread,
Oct 2, 2019, 7:23:02 AM10/2/19
to jenkinsc...@googlegroups.com
Paul Allen closed an issue as Fixed
 
Change By: Paul Allen
Status: Resolved Closed
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages