Skip to content
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

Merged

Conversation

deepueg
Copy link
Contributor

@deepueg deepueg commented Jan 6, 2020

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.

@deepueg deepueg requested a review from friederbluemle January 6, 2020 22:19
Copy link
Member

@friederbluemle friederbluemle left a 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 {
Copy link
Member

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?

Copy link
Contributor Author

@deepueg deepueg Jan 6, 2020

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 calls unregisterRequestHandler on an old UUID the implementation was removing the current one.

Copy link
Contributor Author

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.

Copy link
Member

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
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

Copy link
Member

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();

Copy link
Member

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);
Copy link
Member

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"?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oops. Good catch!. typo.

Copy link
Contributor Author

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);
Copy link
Member

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..

Copy link
Contributor Author

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

@deepueg deepueg force-pushed the fix-request-handle-un-registration branch 2 times, most recently from 4bf20bc to d629db1 Compare January 6, 2020 23:38
@deepueg
Copy link
Contributor Author

deepueg commented Jan 6, 2020

@friederbluemle Updated the PR.

Copy link
Member

@friederbluemle friederbluemle left a 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.

@deepueg deepueg force-pushed the fix-request-handle-un-registration branch 2 times, most recently from 1e9c6fa to 773fefd Compare January 6, 2020 23:42
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.
@deepueg deepueg force-pushed the fix-request-handle-un-registration branch from 773fefd to d352e2c Compare January 6, 2020 23:47
@deepueg deepueg merged commit 492d585 into electrode-io:master Jan 7, 2020
@deepueg deepueg deleted the fix-request-handle-un-registration branch January 7, 2020 00:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants