Project

General

Profile

Actions
Copy link

Bug #11629

closed

[API] NoMemoryError in GroupsController#contents

Added by Tom Clegg over 7 years ago. Updated over 7 years ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Tom Clegg
Category:
API
Target version:
2017-05-10 sprint
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 open — 1 closed)

Task #11630: Review 11629-groups-contents-memoryResolvedRadhika Chippada05/05/2017Actions
Actions
Copy link
 #1

Updated by Tom Clegg over 7 years ago

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

Updated by Tom Clegg over 7 years ago

11629-groups-contents-memory @ cb109bfddd08bd8136b75e90b681e4af3d60ea30

Actions
Copy link
 #3

Updated by Radhika Chippada over 7 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
Copy link
 #4

Updated by Tom Clegg over 7 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
Copy link
 #5

Updated by Radhika Chippada over 7 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
Copy link
 #6

Updated by Tom Clegg over 7 years ago

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

Applied in changeset arvados|commit:ba917d72d48615cdd0c6da87d41b6bd0f9f26666.

Actions
Copy link
 #7

Updated by Tom Clegg over 7 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
Copy link
 #8

Updated by Tom Clegg over 7 years ago

  • Status changed from In Progress to Resolved
Actions
Copy link

Also available in: Atom PDF