Problem The Active Installs 2 script service (services.activeinstalls2) exposes only two methods, and neither can produce the number Active Installs exists to provide: how many distinct XWiki instances are running.
- countInstalls(String) returns a document count, i.e. a number of pings, not a number of instances. An instance pings once a day but also on every restart, so the value is inflated. Measured on extensions.xwiki.org over the last day, the extension org.xwiki.platform:xwiki-platform-dashboard-ui matched 8486 pings but only 7054 distinct instances, a 20% overestimate.
- searchInstalls(String) returns the raw hits, capped by Elasticsearch's default page size of 10, and the JSON it accepts is only the query part of the request body, so no aggs can be attached to it.
Counting distinct instances requires a cardinality aggregation on distribution.instanceId, and there is no way to run one through the script service. The Active Installs 1 script service did support this: it took the full Elasticsearch request body, aggregations included, and returned the parsed JSON response. Consequence The scheduler job on extensions.xwiki.org that refreshes the "installed count" shown on every extension page still queries the Active Installs 1 Elasticsearch instance only, because that is the only one it can get a distinct-instance count out of. It reports around 1200 instances a day where the real total is above 9000, so almost every extension page understates its install count by close to an order of magnitude. Working around this today means bypassing the script service entirely and talking to the Elasticsearch REST endpoint from Groovy, which puts the query, the index layout and the HTTP handling in a wiki page. Proposal Add two methods to ActiveInstallsScriptService (and to DataManager behind it):
- countDistinctInstalls(String jsonQuery) returning the number of distinct instances matching the query.
- countDistinctInstallsByExtension(String jsonQuery) returning, in a single Elasticsearch request, the number of distinct instances per extension id.
The second one also hides a detail that no script author is likely to get right: extensions is mapped as a nested type, so reaching the instance id from an extension bucket needs a reverse_nested aggregation. |
