Skip to content
This repository has been archived by the owner on May 10, 2022. It is now read-only.

feat(security): handle list mechanism response #136

Merged
merged 31 commits into from
Nov 20, 2020

Conversation

levy5307
Copy link
Contributor

No description provided.

import javax.security.auth.Subject;
import javax.security.sasl.Sasl;
import org.slf4j.Logger;

public class Negotiation {
private static final Logger logger = org.slf4j.LoggerFactory.getLogger(Negotiation.class);
// Because negotiation message is always the first rpc sent to pegasus server,
// which will cost much more time. so we set negotiation timeout to 10s here
private static final int negotiationTimeoutMS = 10000;

Choose a reason for hiding this comment

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

Negotiation should be set dynamically by the user timeout. It's under the user's control that how long an RPC should last.

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 don't think it must under the user's control. The negotiation process should be not visable to users

foreverneverer
foreverneverer previously approved these changes Oct 16, 2020
foreverneverer
foreverneverer previously approved these changes Nov 13, 2020
Comment on lines 388 to 406
// return value:
// true - pend succeed
// false - pend failed
public boolean tryPendRequest(RequestEntry entry) {
// double check. the first one doesn't lock the lock.
// Because negotiationSucceed only transfered from false to true.
// So if it is true now, it will not change in the later.
// But if it is false now, maybe it will change soon. So we should use lock to protect it.
if (!this.negotiationSucceed) {
synchronized (negotiationPendingSend) {
if (!this.negotiationSucceed) {
negotiationPendingSend.offer(entry);
return true;
}
}
}

return false;
}

Choose a reason for hiding this comment

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

  1. Your design here binds the responsibility of negotiation to ReplicaSession again. Why couldn't ReplicaSessionInterceptor hold the pending queue?

  2. negotiationPendingSend is declared final, but you offer items here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's hard to hold pending queue by ReplicaSessionInterceptor.

  1. ReplicaSessionInterceptor is a singleton, which will serves all of the ReplicaSession. So if we do this like you said, we must use a coarse-grained lock, which will produce low effiency
  2. If we use ReplicaSessionInterceptor to do this, we must implement a lot of logic in it. For example timeout handling, which will mantain a timeout pendingResponse queue and a PendingSend, and so on. It's too complicated, and there is a lot of overlap code with ReplicaSession. And we should modify ReplicaSession to support it.

@foreverneverer foreverneverer merged commit 6923623 into XiaoMi:master Nov 20, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants