There was a small bug in the selection of the dispatcher name when tracking routers/routees: if there was a deployment configuration (under akka.actor.deployment for the routees as this one here:
Then at the time the router is created the dispatcher name would be the akka.actor.default-dispatcher but when the routees were created the dispatcher would be properly set to custom-dispatcher. This was causing two different sets of metrics being created for each router. With these changes the instrumentation will try to resolve any deployment configuration for the routees when instrumenting the router and use that dispatcher instead of the default one.
Known limitations:
If someone gets fancy about separating the routees' dispatchers with mode complicated deployment configurations (e.g. having one dispatcher for router/$a and another for router/$b) the bug might kick again, although that seems like a rather uncommon situation.
There was a small bug in the selection of the dispatcher name when tracking routers/routees: if there was a deployment configuration (under
akka.actor.deployment
for the routees as this one here:Then at the time the router is created the dispatcher name would be the
akka.actor.default-dispatcher
but when the routees were created the dispatcher would be properly set tocustom-dispatcher
. This was causing two different sets of metrics being created for each router. With these changes the instrumentation will try to resolve any deployment configuration for the routees when instrumenting the router and use that dispatcher instead of the default one.Known limitations:
If someone gets fancy about separating the routees' dispatchers with mode complicated deployment configurations (e.g. having one dispatcher for
router/$a
and another forrouter/$b
) the bug might kick again, although that seems like a rather uncommon situation.