Depending on what you are tracking, you may still have to consider thread-safety between sending and receiving; the ClientCall and Listener are *independently* non-thread-safe and so may need synchronization if reading stats from both. Note that Listener.onClose is the "end of the RPC" but the sender may continue sending a bit after that since the sender may not have processed the closure yet.
It's not clear to me what sort of tracking you're talking about. It seems "it's up to you" and what you want to do. We do have some of our own stats-keeping in gRPC that dumps the data into Census. But that would mean that Census handles the cross-RPC synchronization and combines the data. On Tue, Jul 21, 2020 at 5:12 PM Sivabalan <[email protected]> wrote: > Actually my bad. I was thinking in terms of SimpleClientInterceptor that I > was proposing in the other thread. So with grpc’s out of the box > ClientInterceptor, guess any tracking within a single Clientcall should not > be an issue, since each is an object in itself. > > So, would like to know if there are any guidance or examples on tracking > something across diff client calls within an interceptor. > > On Tue, Jul 21, 2020 at 6:13 PM Sivabalan <[email protected]> wrote: > >> Hey folks, >> I would like to know the general guidance from the community on >> tracking some stats for a single client call and also to update some >> shared variables across different clientcalls. >> >> I have a logging interceptor which collects some stats (like latency) for >> each call. From what I understand, we can't update the instance variables >> of the interceptor directly from within ClientCall (onStart() or >> sendMessage() etc), as we might have synchronization issues unless we take >> care of synchronization for such accesses. >> >> So, I was thinking of having a ConcurrentHashMap keyed on some >> unique identifier for a clientcall and value being some object to hold >> stats for the resp clientCall. Ideally every client call (all apis within >> clientcall) should access only one entry in the map and hence not much of >> an overhead(I do understand under the hood, concurrent hash map does have >> multiple buckets, but it makes developer life easier). So, may I know is >> there some other better way to key rather than having the clientCall >> object? >> >> Simple eg: >> >> class LoggingInterceptor { >> Map<ClientCall, RequestStats> statsMap; >> >> . >> . >> onStart(Metadata headers) { >> RequestStats stats = new RequestStats(); >> stats.startTime = System.currentTimeInMillies(); >> statsMap.put(this.clientCall, stats); >> } >> . >> . >> onClose(....) { >> RequestStats stats = statsMap.get(this.clientCall); >> stats.endTime(System.currentTimeInMillies()); >> // emit request latency to some msg queue >> statsMap.remove(this.clientCall); >> } >> } >> >> I could think of having a static Atomic counter and increment for every >> new call to avoid keying on ClientCall object itself. >> >> In general, would like to know the general guidance from the community on >> tracking some stats for a single client call and also to update some >> shared variables across different clientcalls(for eg, count no of 307s. >> This might update an instance variable in the interceptor). If there are >> any wikis or docs, do let me know. >> >> -- >> Regards, >> -Sivabalan >> > -- > Regards, > -Sivabalan > > -- > You received this message because you are subscribed to the Google Groups " > grpc.io" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/grpc-io/CABeKz3mWDR9idxRnfCjm-ugpTZmFXqd3%3DiBk-m23ubab5Y-jBQ%40mail.gmail.com > <https://groups.google.com/d/msgid/grpc-io/CABeKz3mWDR9idxRnfCjm-ugpTZmFXqd3%3DiBk-m23ubab5Y-jBQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CA%2B4M1oN%3DNywSUfcj9KrWmwm6cJzp4%2BksigemcZ_xkcqgVYBtCw%40mail.gmail.com.
smime.p7s
Description: S/MIME Cryptographic Signature
