-
Notifications
You must be signed in to change notification settings - Fork 22
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 privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix request handle un registration #63
Fix request handle un registration #63
Conversation
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.
Nice one!
Just confirming and double checking a couple of things:
- There can only be one registered handler for the request/response functionality (unlike "events", which can have multiple handlers). Is that assumption correct?
- Previously, what would happen if multiple handlers were registered for request/response? I guess we did not have a test case for that..
import static junit.framework.TestCase.assertSame; | ||
import static junit.framework.TestCase.fail; | ||
|
||
public class RequestHandleTests extends BaseBridgeTestCase { |
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.
Should the class name be RequestHandlerTests
?
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.
Nice one!
Just confirming and double checking a couple of things:
- There can only be one registered handler for the request/response functionality (unlike "events", which can have multiple handlers). Is that assumption correct?
- Previously, what would happen if multiple handlers were registered for request/response? I guess we did not have a test case for that..
-
Yes, we can only have one request handler at any given point of time.
-
Previously, the
mRequestNameByUUID
map was not updated when a new request handler is registered. Due to this, when someone callsunregisterRequestHandler
on an oldUUID
the implementation was removing the current one.
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.
RequestHandle
is the return type that stores the ID, hence kept this name. Guess it can be either.
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.
OK.. Just keep it. We can consider some naming refactoring/simplification for v2.
@@ -59,6 +59,6 @@ | |||
* @param name | |||
* @return {@link UUID} of the request handler | |||
*/ | |||
@NonNull | |||
@Nullable |
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.
Technically, this change is breaking and would require a new major version - So question: Is this required or can you keep it NonNull
? If the change is required, other parts need updates as well, e.g. the getRequestHandlerId
implementation in ElectrodeBridgeTransceiver
- It is still marked as NonNull, but can now return null
. That in turn might require other code updates and refactoring.
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.
This was technically not used anywhere till now, So it should be okay to change the signature. I will update the ElectrodeBridgeTransceiver
as well.
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.
Also, if you look at the old implementation it was done incorrectly. A null
value was returned if a match is not found.
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.
Makes sense 👍
import java.util.Map; | ||
import java.util.UUID; | ||
import java.util.concurrent.ConcurrentHashMap; | ||
|
||
public class RequestRegistrarImpl<T> implements RequestRegistrar<T> { | ||
private static final String TAG = RequestRegistrarImpl.class.getSimpleName(); | ||
|
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.
Replace double blank line with single blank line.
@@ -91,7 +91,7 @@ public void onSuccess(TResp obj) { | |||
|
|||
@Override | |||
public boolean unregister() { | |||
Logger.d(TAG, "Removing registered request handler %s with id %s", handler, id); | |||
Logger.w(TAG, "Removing registered request handler %s with id %s", handler, id); |
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.
Is this now an unexpected ("warning") case, or can it stay "debug"?
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.
oops. Good catch!. typo.
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.
In fact, I will clean up this logic now.
return mRequestHandlerByRequestName.remove(requestName); | ||
} else { | ||
Logger.d(TAG, "Request handler(id: %s) already removed", requestHandlerUuid); |
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.
The other two added Logger
usages have info level, and here it's debug (with a very similar message) - Keep it consistent? Either debug or info would be fine I think..
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.
I will drop it to debug
4bf20bc
to
d629db1
Compare
@friederbluemle Updated the PR. |
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.
Thanks @deepueg 👍
Consider rewording commit message to fix typo before merge:
Move RequestHandle test cases to it's own class
->
Move RequestHandle test cases to its own class
OR simply
Move RequestHandle test cases to separate class
Also, remove period from commit message subject line.
1e9c6fa
to
773fefd
Compare
Add more tests. The old implementation was unregistering wrong request handlers due to a bad UUID mapping Now, when a new request handler registration comes in the old one is automatically removed before registering the new one.
773fefd
to
d352e2c
Compare
This PR fixes an issue with unregistering request handlers.
The old implementation was unregistering wrong request handlers due to a bad UUID mapping
Now, when a new request handler registration comes in the old one is automatically removed before registering the new one.
Added more tests.