-
Notifications
You must be signed in to change notification settings - Fork 154
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
enhance: add client interceptor support #900
Conversation
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: madogar The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Welcome @madogar! It looks like this is your first PR to milvus-io/milvus-sdk-java 🎉 |
Signed-off-by: Shreesha Srinath Madogaran <[email protected]>
0b6020a
to
52456fa
Compare
@madogar Java SDK follows the python sdk logic. In python sdk, the interceptor is used to pass db_name and authorization. The python sdk doesn't provide direct interceptor for users, either. We only expose parameters that we can support. |
@yhmo As of today there is no way to set the param from java SDK, hence this change where would implement an interceptor like below and set it at client level:
}` The biggest challenge is setting this (unique value)param for every gRPC call. |
@madogar
We can add a method to the ConnectParam like this:
The ConnectParam.withClientInterceptors() directly exposes the grpc class ClientInterceptor to users, which is not a good design. It might be out of control if users pass ClientInterceptor freely to the server. Just let the user input an ID by |
@yhmo My thought, consider this scenario:
If we don't do this and follow the approach to explicitly pass it, multiple services has to intercept it and pass it explicitly. I think there could be scenarios where client wants to pass it explicitly but in most of enterprise scenarios there is common layer which takes care of intercepting transactionId to keep it implicit. cc: @xiaofan-luan |
@prrs |
@yhmo @xiaofan-luan We need unique transaction ID per API call, so it can't be at connection level. I am dropping a suggestion. Please help to conclude this or suggest a solution which can solve the problem in hand. Thanks. My thought: Allowing the Client SDK to Intercept and Use Transaction ID Making it Explicit for Client to Pass Transaction ID Default Behavior: By default, the SDK can generate and manage transaction IDs automatically. This makes it easy for most users who do not need to manage transaction IDs themselves. |
Does the transaction ID generator rely on the interceptCall() of ClientInterceptor? I mean: is the transaction ID generated inside the interceptCall()? |
@yhmo no the transaction id(trace id) wouldn't be generated inside the interceptCall(). Eventually in our JAVA app we would create a thread local variable whose value would be used in the interceptCall() for every grpc call. With this logic we would make sure every thread making a grpc call would set its own transaction id. PS: In the above example in the thread I might have hardcoded the value in the interceptCall() for testing reason. |
Could you show me an example of how your app achieves "every thread making a grpc call would set its own transaction id" by the interceptCall()? |
Here is the code where we set the traceId/transactionId in thread local in the Application class:
Here is how we would use it in intercept call:
|
@@ -75,6 +77,10 @@ public MilvusServiceClient(@NonNull ConnectParam connectParam) { | |||
metadata.put(Metadata.Key.of("dbname", Metadata.ASCII_STRING_MARSHALLER), connectParam.getDatabaseName()); |
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 not use this metadata?
metadata.put(Metadata.Key.of("traceID", Metadata.ASCII_STRING_MARSHALLER), traceID);
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.
can you please help with an example how we can set traceId unique for every grpc call in metadata.
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 think user should just specify traceID but not know any idea about interceptor
MilvusClient can handle it
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.
@xiaofan-luan in that case can we expose a threadlocal variable in ConnectParam which can be set during client instantiation?
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.
and further enhance the logic of consuming the trace id from the threadlocal variable in HeaderAttachingClientInterceptor?
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 think use threadlocal make sense to me.
For each reqeust thread, they set threadlocal before request milvus.
the milvus rpc check the traceID threadLocal
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.
cool, I will raise a PR to set threadlocal variable in ConnectParam and further use it in HeaderAttachingClientInterceptor.
Ok, I see. traceid is not a const value, it is unique for each thread. Concurrent threads use the same MilvusClient to call rpc interfaces, different threads have different traceid, right? |
yes! so, are you now aligned with client interceptor logic? |
I didn't find a workaround to avoid exposing grpc interceptor, it seems your pr is the only solution to handle the use case. @xiaofan-luan I think I can accept this pr. What do you think? |
@madogar
|
@yhmo @xiaofan-luan I have raised a new PR with the changes we aligned, please review: |
close this thread and switch to #955 |
No description provided.