New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JSON.parse SyntaxError when running a duration test #358

Closed
gewfy opened this Issue Nov 2, 2017 · 2 comments

Comments

Projects
None yet
3 participants
@gewfy

gewfy commented Nov 2, 2017

This issue is related to #339 and #340
But I've reproduced this without using stages or rambda. The error happens if you set any form of duration e.g. k6 run --duration 5s test.js

This tiny test:

import { check } from 'k6';
import http from 'k6/http';

export default function () {
  const res = http.get('https://api.dev.peachworks.com/v1/products');

  check(res, {
    'status is 200': res => res.status === 200
  });

  const products = JSON.parse(res.body).results;

  check(products, {
    'products is not empty': products => products.length > 0
  });
}

The above test produces the SyntaxError problem but no check errors:
image

@ragnarlonn

This comment has been minimized.

Show comment
Hide comment
@ragnarlonn

ragnarlonn Nov 6, 2017

@liclac @gewfy This issue appears at the end of the test, and if you use a script that either idles the VUs at the end, or sleeps after the last HTTP request of the iteration, the bug is not triggered (e.g. running a 5-second test and not issuing any HTTP requests past the first 4 seconds of the test will not trigger it).

This makes it seem like it may be a matter of a faulty teardown order somewhere, in a code path that only happens when you use --duration (--iterations n does not trigger the bug).

This the smallest script that will trigger the EOF error (k6 run --duration 5s script.js):

import http from 'k6/http';

export default function () {
  const res = http.get('https://api.dev.peachworks.com/v1/products');
  const products = JSON.parse(res.body).results;
}

Now, if I add a sleep anywhere after the HTTP request the error disappears:

import http from 'k6/http';
import { sleep } from "k6";

export default function () {
  const res = http.get('https://api.dev.peachworks.com/v1/products');
  // sleep(1); // error goes away
  const products = JSON.parse(res.body).results;
  sleep(1); // error goes away
}

...but if I move the sleep to before the HTTP request the error is still triggered:

import http from 'k6/http';
import { sleep } from "k6";

export default function () {
  sleep(1); // error still there
  const res = http.get('https://api.dev.peachworks.com/v1/products');
  const products = JSON.parse(res.body).results;
}

So, my conclusion is that the error is triggered when duration ends while k6 either still has HTTP requests to make (as in when there is a sleep before the HTTP request), or is in the process of making a request (as in when there is no sleep at all, which means the HTTP request is the likely place the VU code will be when duration ends - because it is the longest-running function call in the script)

Wild guess: could it be something introduced with the new buffer pool code -
b002f2c ?

ragnarlonn commented Nov 6, 2017

@liclac @gewfy This issue appears at the end of the test, and if you use a script that either idles the VUs at the end, or sleeps after the last HTTP request of the iteration, the bug is not triggered (e.g. running a 5-second test and not issuing any HTTP requests past the first 4 seconds of the test will not trigger it).

This makes it seem like it may be a matter of a faulty teardown order somewhere, in a code path that only happens when you use --duration (--iterations n does not trigger the bug).

This the smallest script that will trigger the EOF error (k6 run --duration 5s script.js):

import http from 'k6/http';

export default function () {
  const res = http.get('https://api.dev.peachworks.com/v1/products');
  const products = JSON.parse(res.body).results;
}

Now, if I add a sleep anywhere after the HTTP request the error disappears:

import http from 'k6/http';
import { sleep } from "k6";

export default function () {
  const res = http.get('https://api.dev.peachworks.com/v1/products');
  // sleep(1); // error goes away
  const products = JSON.parse(res.body).results;
  sleep(1); // error goes away
}

...but if I move the sleep to before the HTTP request the error is still triggered:

import http from 'k6/http';
import { sleep } from "k6";

export default function () {
  sleep(1); // error still there
  const res = http.get('https://api.dev.peachworks.com/v1/products');
  const products = JSON.parse(res.body).results;
}

So, my conclusion is that the error is triggered when duration ends while k6 either still has HTTP requests to make (as in when there is a sleep before the HTTP request), or is in the process of making a request (as in when there is no sleep at all, which means the HTTP request is the likely place the VU code will be when duration ends - because it is the longest-running function call in the script)

Wild guess: could it be something introduced with the new buffer pool code -
b002f2c ?

@liclac

This comment has been minimized.

Show comment
Hide comment
@liclac

liclac Nov 15, 2017

Collaborator

This looks like an issue wrt how VUs are scheduled, I'll do some poking around.

Collaborator

liclac commented Nov 15, 2017

This looks like an issue wrt how VUs are scheduled, I'll do some poking around.

@liclac liclac closed this in 682a341 Nov 15, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment