1. 11 Oct, 2019 7 commits
    • Lubomir Bulej's avatar
      Merge branch 'wip-cleanups' into 'devel' · 4df6fdb2
      Lubomir Bulej authored
      First batch of cleanups along with a few fixes
      
      These clean-ups and the (few) fixes result from working with the integrated server for a bit. One of the bigger changes is partially deferring processing of analysis data to analysis threads. This removes some load from the main receiver thread and also allows reusing many of the objects that were previously allocated for each analysis request, which visibly reduces the allocation rate in the server.
      
      See merge request !10
      4df6fdb2
    • Lubomir Bulej's avatar
      Try bumping the test time limit to 45 seconds · 57219167
      Lubomir Bulej authored
      Again, this is to accomodate the "dispatchmp" test on slower
      machines (it takes 14-15 seconds on a modern machine).
      57219167
    • Lubomir Bulej's avatar
      Increase test time limit to 20 seconds · 457108c8
      Lubomir Bulej authored
      This may be necessary for the "dispatchmp" test to finish
      on slower machines.
      457108c8
    • Lubomir Bulej's avatar
      Remove test-util target from CI config · 39db1f9a
      Lubomir Bulej authored
      There are currently no tests in the util sub-project.
      39db1f9a
    • Lubomir Bulej's avatar
      Unmarshal analysis data and object tags in processing threads · b4262caa
      Lubomir Bulej authored
      This reduces the amount of work that the receiving thread has to do,
      but also allows to avoid repeated allocations of many objects for each
      analysis request, thus reducing the memory allocation rate in the
      server.
      b4262caa
    • Lubomir Bulej's avatar
      Fix unmarshaling of garbage-collected object tags · dd693fee
      Lubomir Bulej authored
      This was caused by forcing the byte buffer provided by protobuf
      implementation to BIG_ENDING byte order mode.
      dd693fee
    • Lubomir Bulej's avatar
      Fix race in "dispatchmp" test and repeatedly force GC · 814b47be
      Lubomir Bulej authored
      The race was in the code displaying the "So far received..." message.
      After the check if the counter value modulo 1000000 was zero, the
      value actually displayed was queried again, potentially obtaining a
      different value (another thread might have incremented the counter).
      
      To force the client to send notifications about garbage collected
      objects, the client code forces the GC repeatedly and waits a bit
      between the attempts.
      814b47be
  2. 09 Oct, 2019 11 commits
  3. 08 Oct, 2019 17 commits
  4. 07 Oct, 2019 2 commits
  5. 06 Oct, 2019 3 commits