Project

General

Profile

Actions

Bug #11629

closed

[API] NoMemoryError in GroupsController#contents

Added by Tom Clegg about 5 years ago. Updated about 5 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
API
Target version:
Start date:
05/05/2017
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Story points:
-

Description

Presumably, we are seeing this error because (unlike collections#index) the groups#contents controller does not respect max_index_database_read.

In this case the solution is to call ApplicationController#limit_database_read from GroupsController#contents at the appropriate time.


Subtasks 1 (0 open1 closed)

Task #11630: Review 11629-groups-contents-memoryResolvedRadhika Chippada05/05/2017

Actions
Actions #1

Updated by Tom Clegg about 5 years ago

  • Status changed from New to In Progress
  • Assigned To set to Tom Clegg
  • Target version set to 2017-05-10 sprint
Actions #2

Updated by Tom Clegg about 5 years ago

11629-groups-contents-memory @ cb109bfddd08bd8136b75e90b681e4af3d60ea30

Actions #3

Updated by Radhika Chippada about 5 years ago

  • Do we also want to add self.limit_index_columns_read on "components" column for jobs and pipeline_instances?
  • In groups_controller_test.rb, @ line 482, adding a comment such as “only one row will be returned by server because max db read of 12 is less than that of any collection’s manifest text length” might be helpful
Actions #4

Updated by Tom Clegg about 5 years ago

Yes to both, thanks. These updates also revealed that the changes had broken items_available in the groups#contents response by exiting the loop early without checking other types -- fixed that.

11629-groups-contents-memory @ 4cacfe7a9566d7ea6f53be24daf83cf9e441aebb

Actions #5

Updated by Radhika Chippada about 5 years ago

These updates also revealed that the changes had broken items_available in the groups#contents response by exiting the loop early without checking other types -- fixed that

Thanks for catching that; I noticed it and thought it was intentional though wondered how workbench would react to that.

LGTM @ 4cacfe7

Actions #6

Updated by Tom Clegg about 5 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

Applied in changeset arvados|commit:ba917d72d48615cdd0c6da87d41b6bd0f9f26666.

Actions #7

Updated by Tom Clegg about 5 years ago

  • Status changed from Resolved to In Progress

https://ci.curoverse.com/job/run-tests-apps-workbench-units/888/console

  1) Error:
WorkUnitTest#test_Completed_ContainerRequest_state_=_Complete_with_exit_code_=_0:
ArvadosApiClient::ApiErrorResponseException: #<PG::AmbiguousColumn: ERROR:  column reference "mounts" is ambiguous
LINE 1: SELECT  (octet_length(mounts)) as read_length FROM "containe...
                              ^
> [API: 422]
    app/models/arvados_api_client.rb:171:in `api'
    app/models/arvados_resource_list.rb:209:in `each_page'
    app/models/arvados_resource_list.rb:102:in `results'
    app/models/arvados_resource_list.rb:135:in `first'
    app/models/container_work_unit.rb:9:in `initialize'
    app/models/container_request.rb:15:in `new'
    app/models/container_request.rb:15:in `work_unit'
    test/unit/work_unit_test.rb:52:in `block (2 levels) in <class:WorkUnitTest>'
    test/test_helper.rb:299:in `run'
Actions #8

Updated by Tom Clegg about 5 years ago

  • Status changed from In Progress to Resolved
Actions

Also available in: Atom PDF