Tracking stats for a single clientCall and across diff client calls within an interceptor

[Sivabalan]

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

[Sivabalan]

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. 

--

Regards,
-Sivabalan

[Eric Anderson]

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.

--
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 grpc-io+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CABeKz3mWDR9idxRnfCjm-ugpTZmFXqd3%3DiBk-m23ubab5Y-jBQ%40mail.gmail.com.

[Sivabalan]

that helps Eric. Thanks for reminding me about onClose. I am just building the interceptor framework now and haven't thought through this completely. 

--

Regards,
-Sivabalan