updateTable hangs if passed the same throughput as the table currently has #79
Assignees
Comments
|
Resolved while working on #78, will push commits once I've merged that feature branch to dev. |
|
For what it's worth, I suspect that it's not the call to |
ricardojmendez
added a commit
that referenced
this issue
Dec 15, 2015
Found that updateTable hangs if we pass the same throughput values as the table currently has (see #79). Refactored throughput parameter validation to its own function, since we'll need to validate the parameters for the other operations as well. Expanded tests.
ricardojmendez
added a commit
that referenced
this issue
Dec 15, 2015
Want to make sure we're running against the latest version, to avoid behavior like #79 being a known (and possibly solved) issue.
|
See #85 |
ricardojmendez
added a commit
that referenced
this issue
Dec 17, 2015
Found that updateTable hangs if we pass the same throughput values as the table currently has (see #79). Refactored throughput parameter validation to its own function, since we'll need to validate the parameters for the other operations as well. Expanded tests.
ricardojmendez
added a commit
that referenced
this issue
Dec 17, 2015
Want to make sure we're running against the latest version, to avoid behavior like #79 being a known (and possibly solved) issue.
ricardojmendez
added a commit
that referenced
this issue
Dec 19, 2015
* Renamed environment sample, more useful as a script * Global secondary index tests for create-table * Local secondary index tests * BREAKING CHANGE: update-table now receives options in a map [1] This commit only changes throughput so that it's passed as an option in a map, as discussed on #78. It's still required, which it shouldn't be since it's not the only option to change. * We no longer need to do stepping when updating throughput See discussion on #78 * Elaborating on table-status-watch comment * Tests for decreasing throughput * Disregarding throughput updates that are the same as the current values Found that updateTable hangs if we pass the same throughput values as the table currently has (see #79). Refactored throughput parameter validation to its own function, since we'll need to validate the parameters for the other operations as well. * Expanded tests. * Updating encore and AWS SDK version, all tests passing Want to make sure we're running against the latest version, to avoid behavior like #79 being a known (and possibly solved) issue. * Upgraded expectations, re-wrote tests that used expect-let * Sending empty map to update-table should have no effect See 8574687, this test should have gone in with that commit. * Global secondary index creation on update-table, see #80 * update-table can now change throughput on :gsindexes (#80) Also, new function: index-status-watch * update-table can now delete :gsindexes (#80) * Support for specifying index on scan (#82) * Supporting projection and expr-attr-names on scan (#82) * Added support for conditional deletes (#84) * Added missing tests for expressions on update-item-request * BREAKING CHANGE: update-map is now another value on update-item's params Updated tests, fixed deprecation warning. See #83. * Expanded docstring for update-table (#80)
ricardojmendez
added a commit
that referenced
this issue
Dec 22, 2015
* Renamed environment sample, more useful as a script * Global secondary index tests for create-table * Local secondary index tests * BREAKING CHANGE: update-table now receives options in a map [1] This commit only changes throughput so that it's passed as an option in a map, as discussed on #78. It's still required, which it shouldn't be since it's not the only option to change. * We no longer need to do stepping when updating throughput See discussion on #78 * Elaborating on table-status-watch comment * Tests for decreasing throughput * Disregarding throughput updates that are the same as the current values Found that updateTable hangs if we pass the same throughput values as the table currently has (see #79). Refactored throughput parameter validation to its own function, since we'll need to validate the parameters for the other operations as well. * Expanded tests. * Updating encore and AWS SDK version, all tests passing Want to make sure we're running against the latest version, to avoid behavior like #79 being a known (and possibly solved) issue. * Upgraded expectations, re-wrote tests that used expect-let * Sending empty map to update-table should have no effect See 8574687, this test should have gone in with that commit. * Global secondary index creation on update-table, see #80 * update-table can now change throughput on :gsindexes (#80) Also, new function: index-status-watch * update-table can now delete :gsindexes (#80) * Support for specifying index on scan (#82) * Supporting projection and expr-attr-names on scan (#82) * Added support for conditional deletes (#84) * Added missing tests for expressions on update-item-request * BREAKING CHANGE: update-map is now another value on update-item's params Updated tests, fixed deprecation warning. See #83. * Expanded docstring for update-table (#80)
ricardojmendez
added a commit
that referenced
this issue
Dec 22, 2015
* Renamed environment sample, more useful as a script * Global secondary index tests for create-table * Local secondary index tests * BREAKING CHANGE: update-table now receives options in a map [1] This commit only changes throughput so that it's passed as an option in a map, as discussed on #78. It's still required, which it shouldn't be since it's not the only option to change. * We no longer need to do stepping when updating throughput See discussion on #78 * Elaborating on table-status-watch comment * Tests for decreasing throughput * Disregarding throughput updates that are the same as the current values Found that updateTable hangs if we pass the same throughput values as the table currently has (see #79). Refactored throughput parameter validation to its own function, since we'll need to validate the parameters for the other operations as well. * Expanded tests. * Updating encore and AWS SDK version, all tests passing Want to make sure we're running against the latest version, to avoid behavior like #79 being a known (and possibly solved) issue. * Upgraded expectations, re-wrote tests that used expect-let * Sending empty map to update-table should have no effect See 8574687, this test should have gone in with that commit. * Global secondary index creation on update-table, see #80 * update-table can now change throughput on :gsindexes (#80) Also, new function: index-status-watch * update-table can now delete :gsindexes (#80) * Support for specifying index on scan (#82) * Supporting projection and expr-attr-names on scan (#82) * Added support for conditional deletes (#84) * Added missing tests for expressions on update-item-request * BREAKING CHANGE: update-map is now another value on update-item's params Updated tests, fixed deprecation warning. See #83. * Expanded docstring for update-table (#80)
ptaoussanis
pushed a commit
that referenced
this issue
Jan 23, 2016
* Renamed environment sample, more useful as a script * Global secondary index tests for create-table * Local secondary index tests * BREAKING CHANGE: update-table now receives options in a map [1] This commit only changes throughput so that it's passed as an option in a map, as discussed on #78. It's still required, which it shouldn't be since it's not the only option to change. * We no longer need to do stepping when updating throughput See discussion on #78 * Elaborating on table-status-watch comment * Tests for decreasing throughput * Disregarding throughput updates that are the same as the current values Found that updateTable hangs if we pass the same throughput values as the table currently has (see #79). Refactored throughput parameter validation to its own function, since we'll need to validate the parameters for the other operations as well. * Expanded tests. * Updating encore and AWS SDK version, all tests passing Want to make sure we're running against the latest version, to avoid behavior like #79 being a known (and possibly solved) issue. * Upgraded expectations, re-wrote tests that used expect-let * Sending empty map to update-table should have no effect See 8574687, this test should have gone in with that commit. * Global secondary index creation on update-table, see #80 * update-table can now change throughput on :gsindexes (#80) Also, new function: index-status-watch * update-table can now delete :gsindexes (#80) * Support for specifying index on scan (#82) * Supporting projection and expr-attr-names on scan (#82) * Added support for conditional deletes (#84) * Added missing tests for expressions on update-item-request * BREAKING CHANGE: update-map is now another value on update-item's params Updated tests, fixed deprecation warning. See #83. * Expanded docstring for update-table (#80)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If we pass the same throughput as the table currently has (or no throughput at all, which defaults to the same) the
update-tablecall hangs. I initially thought that the table's state never changed to:updating, but looking attable-status-watchthat wouldn't have affected it, since it only checks that the current status is not the one passed.Execution actually hangs when we call AmazonDynamoDB.updateTable.
This probably hadn't manifested before removing stepping (see #78) because if the throughput was the same as before, no steps were generated and the function was never called. Adding a single step to the old implementation with the same values as the current throughput reproduces the issue.
This happens against both the local database and a live instance.
The text was updated successfully, but these errors were encountered: