The PR is updated with some major changes:

• NamedRunnable is no more used in Executor.executeSafe() function to wrap every runnable from our SDK, because it will cause the Executor.remove fail if we want to remove the same instance of runnable. Instead, the caller of executeSafe need to wrap the runnable by itself, and provide the name. In this case, only rum-pipeline runnables are wrapped with it.
• proguard-rules is added in order to keep the class name of RumRawEvent.

I discussed it with Yi already, but will duplicate here for everyone else.

I have a concern that if the user calls methods of RumMonitor on main thread one after another and each of these calls leads to the Runnable being dropped due to backpressure, we might have a risk to cause an ANR.

We copy 1024 items from the queue, then compute some Map with statistics.

Especially taking into account the customer case related to backpressure I found this morning.

This needs to be checked, I am not entirely sure, but it looks a bit scary to me.

We copy 1024 items from the queue

Although the copy of the individual item should be cheap, it is just by reference. The main time-consumer here is the iteration over the items.

It can be another approach: maintain statistics at the offer / remove/pull calls and read it when needed, without looping though the items.

It can be another approach: maintain statistics at the offer / remove/pull calls and read it when needed, without looping though the items.

Looks good to me. Performance shouldn't change significantly, it doesn't look heavy. I didn't measure though, but looking at the code, it seems ok.

We copy 1024 items from the queue

Although the copy of the individual item should be cheap, it is just by reference. The main time-consumer here is the iteration over the items.

It can be another approach: maintain statistics at the offer / remove/pull calls and read it when needed, without looping though the items.

For me a problem of this is that we have to listen all the functions which might cause the size change of the LinkedBlockingQueue, for example we need to deal the exception with put, we have to deal with the result of offer which can be rejected, we have to deal with drainTo and removeAll, and also to handle them properly we need to take care of concurrency issue of each. It's like reinventing the wheel of LinkedBlockingQueue ourselves.

For me maybe copy the queue toArray at the call thread and delegate the map computation on background thread is easier and has less performance overhead?

Latest PR update summary:

• Create ObservableBlockingQueue class to extract the dump logic with time interval (5s) protection, and add unit test for this.
• BackPressuredBlockingQueue extends from ObservableBlockingQueue, calling dumpQueue function when threshold reached.

Codecov Report

❌ Patch coverage is 81.57895% with 7 lines in your changes missing coverage. Please review.
✅ Project coverage is 70.00%. Comparing base (5376af1) to head (3709b4f).
⚠️ Report is 219 commits behind head on develop.

@@             Coverage Diff             @@
##           develop    #2673      +/-   ##
===========================================
+ Coverage    69.95%   70.00%   +0.05%     
===========================================
  Files          820      822       +2     
  Lines        30657    30687      +30     
  Branches      5162     5168       +6     
===========================================
+ Hits         21445    21481      +36     
+ Misses        7769     7763       -6     
  Partials      1443     1443