that helps Eric. Thanks for reminding me about onClose. I am just building the interceptor framework now and haven't thought through this completely.
On Fri, Jul 24, 2020 at 7:45 PM Eric Anderson <[email protected]> wrote: > 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> >> . >> > -- 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/CABeKz3%3DNOZY9JaMdxmwubJK_xTD0-f5QM4%2BLbdTkBCYznfdK5Q%40mail.gmail.com.
