Feature/redrive on buffer too small error #79
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
-Make Length parameters implicitly grab length from passed strings/arrays -Re-structure response from pyRACF as dictionary rather than tuple -Add handle pointer to the returned dictionary Signed-off-by: Elijah Swift <elijah.swift@ibm.com>
update C code to re-drive requests with dynamically adjusted buffer size. remove passing of handle pointer to python LOTS OF DEBUGGING Signed-off-by: Elijah Swift <elijah.swift@ibm.com>
Update version number Signed-off-by: Elijah Swift <elijah.swift@ibm.com>
Remove accounting for previously allocated buffer space. Since only 1 command comes to SMO00, this should only practically be the XML header returned on the first call (116 bytes or so). Signed-off-by: Elijah Swift <elijah.swift@ibm.com>
ElijahSwiftIBM
force-pushed
the
feature/redrive_on_buffer_too_small_error
branch
4 times, most recently
from
7169696
to
28b2c29
Compare
Move Re-driving requests from c code to python Move redriving requests from c layer to python layer drop the initial results buffer as this is no longer doing anything. debug prints Signed-off-by: Elijah Swift <elijah.swift@ibm.com>
ElijahSwiftIBM
force-pushed
the
feature/redrive_on_buffer_too_small_error
branch
from
59294cc
to
14ce1e5
Compare
This reverts commit 14ce1e5.
Test different return code locations at c layer Signed-off-by: Elijah Swift <elijah.swift@ibm.com>
Try making new handle
Test different return code locations at c layer Signed-off-by: Elijah Swift <elijah.swift@ibm.com> Update irrsmo00.c Try making new handle Update irrsmo00.c
This reverts commit 14ce1e5.
This reverts commit 1f94b93.
Try passing the handle through c and python Signed-off-by: Elijah Swift <elijah.swift@ibm.com>
Fixed error in handling test_irrsmo00_interface with returned handle
ElijahSwiftIBM
force-pushed
the
feature/redrive_on_buffer_too_small_error
branch
from
92c0cb9
to
16e7d23
Compare
Update irrsmo00.c
ElijahSwiftIBM
force-pushed
the
feature/redrive_on_buffer_too_small_error
branch
from
16e7d23
to
811b1b2
Compare
Change handle to "w"
|
Closing this PR as we are re-assessing these features. This will either get moved to python layer or involve new unit testing in C layer. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
💡 Issue Reference
Issue: #71
💻 What does this address?
Now that users can specify buffer sizes as a part of the class constructor, we need to dynamically respond to the buffer size being too small to hold the response xml.
📟 Implementation Details
At the C code level, if the failing request is detected, a new buffer is allocated large enough for the remaining response and the request is re-driven. If the buffer would need to be larger than the maximum tolerable size for our constructor, we fail and surface the error as a DownstreamFatalError with IRRSMO00's return and reason codes.
📋 Is there a test case?
Since this re-drive is done at the c level, there are no applicable unit tests available. A function test could be added, but we would need confirmation that the environment is appropriate for the test (a command and buffer size must be chosen that we KNOW would fail prior to this feature which may differ dependent on the environment and authority bestowed to pyRACF).
On our test system, I ran two tests. One with setropts_admin.list_racf_options with a buffer specified at 10000 bytes (the minimum) which failed before the added code and now succeeds, and one with resource_admin.extract("*","FACILITY) with the default 16KB buffer which failed and now succeeds.