-
Notifications
You must be signed in to change notification settings - Fork 67
fix issue #41 #43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and 8000 privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
lynus
wants to merge
1
commit into
zrlio:master
Choose a base branch
from
lynus:issue41
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
fix issue #41 #43
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or 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
This file contains hidden or 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
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.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we allow partially allocated ActiveEndpoints to call close() in the first place, only to then check if they have been allocated and prevent the close from proceeding? Rather I suggest we check the allocation state in the endpoint and decide whether or not to de-allocate.
That being said, I'm not convinced that preventing close on partially allocated enpoints is a good idea. What if I do want to close and cleanup the resources? I can't do so anymore. Also, this leaves partially allocated endpoints in the group, lingering around forever. I think we should leave it to the application to decide whether they want to close or not, then then make sure the close call closes whatever needs to be closed while not closing what doesn't need to.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My intention is not to prevent closing partial allocated endpoints, but to prevent releasing un-allocated resource when users decide to close the failed ep.
This is exactly what I am trying to achieve by introducing isResourceAllocated(). Application ep's close() implementation should be the following pattern:
super.close();
if (isResourceAllocated())
release its own resources...
Check if resources has been successfully allocated before releasing its own resources. super.close() can be called without checking is because current close() of RdmaEndpoint works fine with partial allocated ep, and RdmaActiveEndpoint's needs the patch you quoted above to work.
This is not the case. Since ep throws exceptions before allocating resources
disni/src/main/java/com/ibm/disni/RdmaEndpoint.java
Line 116 in cfcee63
this ep never registered into cqProcessor. It is also unregistered from group's clientEndpointMap in
disni/src/main/java/com/ibm/disni/RdmaEndpoint.java
Line 213 in cfcee63
Therefore, no residues left after close().
In summary, users have to choices when catching exception on connect(): 1) close the failed ep and 2) try to connect() again. I think the patch can properly preventing releasing un-allocated resources if users decide to take opt-1. And the logic in connect() can handle the opt-2 situation.