Draft version of documentation to setup OW on a Mac host is added.

I have no idea on documentation convention, PG(?), rebase rule. I want someone to guide me about these community rules.

I know this branch is conflicting with master branch. Once I get the review, I will amend them and rebase it.

I tried to minimize the changes and maximize to utilize existing contents.

building wsk cli off of openwhisk/openwhisk-cli instead of from local openwhisk/openwhisk repo

These changes are still under testing and not completely working on my local system.

Description

With this change, it is required to install Docker=18.06.3 on target servers. This is a breaking change.

Related issue and scope

• [x] I opened an issue to propose and discuss this change (#4336)

My changes affect the following components

• [ ] API
• [x] Controller
• [ ] Message Bus (e.g., Kafka)
• [ ] Loadbalancer
• [x] Invoker
• [ ] Intrinsic actions (e.g., sequences, conductors)
• [ ] Data stores (e.g., CouchDB)
• [x] Tests
• [x] Deployment
• [ ] CLI
• [ ] General tooling
• [x] Documentation

Types of changes

• [ ] Bug fix (generally a non-breaking change which closes an issue).
• [x] Enhancement or new feature (adds new functionality).
• [ ] Breaking change (a bug fix or enhancement which changes existing behavior).

Checklist:

• [x] I signed an Apache CLA.
• [x] I reviewed the style guides and followed the recommendations (Travis CI will check :).
• [x] I added tests to cover my changes.
• [x] My changes require further changes to the documentation.
• [ ] I updated the documentation where necessary.

Environment details:

• local deployment, ubuntu VM (16.04 LTS - 64 bit Memory 3.8 GB , Disk 14.7 GB)
• version of docker Containers: 6 Running: 6 Paused: 0 Stopped: 0 Images: 116 Server Version: 17.03.1-ce Storage Driver: aufs ..

Deploying Using CouchDB

The command ansible-playbook -i environments/<environment> openwhisk..yml produces error.

Provide the actual results and outputs:

TASK [invoker : determine docker root dir] *************************************
Sunday 04 June 2017  18:00:25 +0000 (0:00:00.329)       0:04:19.028 *********** 
fatal: [172.17.0.1]: FAILED! => {"changed": false, "content": "", "failed": true, "msg": "Status code was not [200]: Request failed: <urlopen error [Errno 111] Connection refused>", "redirected": false, "status": -1, "url": "http://172.17.0.1:4243/info"}

PLAY RECAP *********************************************************************
172.17.0.1                 : ok=25   changed=18   unreachable=0    failed=1   
ansible                    : ok=2    changed=1    unreachable=0    failed=0   

Sunday 04 June 2017  18:00:26 +0000 (0:00:00.918)       0:04:19.947 *********** 
=============================================================================== 
kafka : pull the ches/kafka:0.10.0.1 image ----------------------------- 98.14s
controller : wait until the Controller in this host is up and running -- 39.38s
kafka : pull the zookeeper:3.4 image ----------------------------------- 38.62s
kafka : wait until the kafka server started up ------------------------- 11.44s
kafka : create the active-ack and health topic -------------------------- 9.38s
kafka : wait until the Zookeeper in this host is up and running --------- 8.43s
consul : start registrator using docker cli ----------------------------- 7.34s
consul : pull the consul:0.7.0 image ------------------------------------ 6.89s
consul : wait until the Consul Server/Agent in this host is up and running --- 6.44s
kafka : create the invoker topics --------------------------------------- 4.76s
consul : fill consul kv ------------------------------------------------- 4.66s
consul : (re)start consul server/agent ---------------------------------- 2.32s
kafka : (re)start zookeeper --------------------------------------------- 2.10s
controller : (re)start controller --------------------------------------- 1.99s
write whisk.properties template to openwhisk_home ----------------------- 1.85s
Gathering Facts --------------------------------------------------------- 1.81s
kafka : (re)start kafka ------------------------------------------------- 1.79s
Gathering Facts --------------------------------------------------------- 1.78s
Gathering Facts --------------------------------------------------------- 1.74s
Gathering Facts --------------------------------------------------------- 1.39s

ansible-playbook -i environments/<environment> postdeploy.yml produces

dial tcp 172.17.0.1:443: getsockopt: connection refused

Additional information you deem important:

• The command docker ps --format "{{.Names}} - {{.Image}}" provide the following output. controller - whisk/controller:latest kafka - ches/kafka:0.10.0.1 zookeeper - zookeeper:3.4 registrator - gliderlabs/registrator consul - consul:0.7.0 couchdb - couchdb:1.6
• There is no nginx and invoker.

Environment details:

• Docker version 17.04.0-ce, build 4845c56
• Ubuntu 16.04..
• Local deployement

Steps to reproduce the issue:

1. try to create trigger using the below command
2. wsk -i trigger create every-20-seconds --feed /whisk.system/alarms/alarm --param cron '*/10 * * * * *' --param maxTriggers 6

Provide the expected results and outputs:

Trigger should have got created successfully 

Provide the actual results and outputs:

error: Unable to create trigger 'every-20-seconds': Unable to invoke trigger 'every-20-seconds' feed action '/whisk.system/alarms/alarm'; feed is not configured: Unable to invoke action 'alarms/alarm': The supplied authentication is not authorized to access this resource. (code 22040)

Additional information you deem important:

• I have done this installation on my local Ubuntu VM
• I am trying to work on the the sample application. link: https://github.com/IBM/openwhisk-action-trigger-rule

I am creating this enhancement to discuss/add distributed tracing support to Openwhisk project. This will help to gather latency data of various components(controller, invoker etc.) in various usage context(eg. action invocation). This data can help troubleshoot any performance bottlenecks.

One option is to use Zipkin - http://zipkin.io/ There is already instrumented library which supports Akka and Spray framework - https://github.com/levkhomich/akka-tracing

I have done some initial work around this and I can contribute it back once its complete. It would be nice to get thoughts/concerns/suggestions around this.

Alphabetize, coauthored by myself and @bpoole16, is intended to allow the user to sort a given list of entities alphabetically. This applies to actions, triggers, rules, packages, and apis.

By default, entities are listed in order from most to least recently updated:

$ wsk action list
actions
/guest/packageB/A                  private nodejs:6
/guest/C                                  private nodejs:6
/guest/A                                  private nodejs:6
/guest/packageA/B                  private nodejs:6
/guest/packageA/A                  private nodejs:6
/guest/B                                  private nodejs:6

To see the list of entities sorted alphabetically, use the flag --name-sort or -n:

$ wsk action list --name-sort
actions
/guest/A                                  private nodejs:6
/guest/B                                  private nodejs:6
/guest/C                                  private nodejs:6
/guest/packageA/A                  private nodejs:6
/guest/packageA/B                  private nodejs:6
/guest/packageB/A                  private nodejs:6

The entities are sorted by namespace first, then package name (with the default package actions at the top), and finally by entity name.

Side effects of this PR

• We centralized the printing functions within commands/util.go
• We created two new interfaces:

1. Printables: structures that are printed in lists on a regular basis.
2. Sortables: structures that are meant to be sorted.

Potential upgrades from this branch:

• Currently, activations are not sorted alphabetically, only by their start time, and therefore --name-sort is not applicable to activations; however, there may be another way of sorting activations which would be beneficial. The ability to sort activations is set up, one only needs to set the function Compare() in whisk/activation.go and make a custom flag to activate the sorting for it to be implemented.
• Add a flag to sort alphabetically by Action name -> Base path -> Rel path -> Verb for APIs

A prototype of one possible approach for dynamic invoker registration. The invoker's instanceId is not provided on the command line on startup. Instead, the invoker dynamically requests an id from the controller during its startup via the message bus (kafka). Once it receives an id, invoker startup continues unchanged.

On the plus side, this protocol maintains the property that invokers are densely assigned ids starting from 0. On the minus side, it takes an extra round of messages thus mildly delaying system startup.

An alternative approach would be to use randomly generated UUIDs as the invoker's id and adapt the load balancer algorithm accordingly. Using UUIDs as invoker ids might make some aspects of operations slightly more annoying as well, as the invokers would not have stable (or short/easy to recognize) names. This is a larger change, but I think it is possible to implement without too much trouble.

Enables running a minimal OpenWhisk (with in memory store) as a runnable jar outside of docker

Description

Currently users looking to explore OpenWhisk directly have few options like devtools docker compose, mini kube etc. This PR provides yet another option which enables launching a fully working OpenWhisk server via a runnable jar

java -jar openwhisk-standalone-1.0.0-SNAPSHOT.jar

This launches a fully functional OpenWhisk controller and invoker. You can run wsk commands against it and launch and execute actions etc.

To try it out currently you can download a pre built jar from here

Design

This PR builds up on lean openwhisk support. It configures OpenWhisk to use a MemoryArtifactStore (thus avoiding nead of a separate CouchDB container) and enables executing the standard wsk commands against it

See also the discussion thread

Key aspects

• Configured by default to use a MemoryArtifactStore
• Can be configured to use another store via simple config
• Delievered as a jar executable
• Adapts the config as per OS
• Bootstraps a set of default users (guest and whisk.system)

Usage

First build the standalone module

./gradlew :core:standalone:build

In future

wget maven/openwhisk.jar

Launch the server

$ java -jar openwhisk-standalone-1.0.0-SNAPSHOT.jar -h
OpenWhisk standalone launcher
  -c, --config-file  <arg>   application.conf which overwrites the default
                             whisk.conf
  -m, --manifest  <arg>      Manifest json defining the supported runtimes
  -p, --port  <arg>          Server port
  -h, --help                 Show help message
$ java -jar openwhisk-standalone-1.0.0-SNAPSHOT.jar

When to use

This mode may be benefical in cases like

• Running simple test against an OpenWhisk server say when testing compositions
• Faster development cycle - No need to build and relaunch docker container to test out simple changes in regular development flow on OpenWhisk core codebase
• Easier entrypoint for new users to get a feel of OpenWhisk features

Related issue and scope

• [ ] I opened an issue to propose and discuss this change (#????)

My changes affect the following components

• [ ] API
• [ ] Controller
• [ ] Message Bus (e.g., Kafka)
• [ ] Loadbalancer
• [ ] Invoker
• [ ] Intrinsic actions (e.g., sequences, conductors)
• [ ] Data stores (e.g., CouchDB)
• [ ] Tests
• [ ] Deployment
• [ ] CLI
• [ ] General tooling
• [ ] Documentation

Types of changes

• [ ] Bug fix (generally a non-breaking change which closes an issue).
• [ ] Enhancement or new feature (adds new functionality).
• [ ] Breaking change (a bug fix or enhancement which changes existing behavior).

Checklist:

• [ ] I signed an Apache CLA.
• [ ] I reviewed the style guides and followed the recommendations (Travis CI will check :).
• [ ] I added tests to cover my changes.
• [ ] My changes require further changes to the documentation.
• [ ] I updated the documentation where necessary.

If I'm looking at a recent activation to debug it and I don't know its ID, it would be useful to have its start/end time, its status (success, running, failed).

Currently other than confirming there are activations, it is not very useful:

$ wsk activation list
activations
123fb4243552491b94b6fcf6a94be745             vision-analysis                         
21526c4dd7564090a9095941fa1d546b             vision-analysis                         
0fa2dd0bb55f4df3ba68a571da1a6d34             vision-analysis                         
3b33904f79f448beb0c913856363a088             vision-analysis                         
e2e22077ad3945b48b612436fe0bb334             vision-analysis                         
48581ba45fac4119a5970250e3f0b0d7             vision-analysis                         
dec75b9e241942e6a9ddd0fc9b8dd68b             vision-analysis                         
3a0e3cbf45734ce1b13220414d6c10af             vision-analysis

Say I have a web-exported sequence S: A=>B=>C and action B is responsible for some kind of authentication or authorization. Thus, B may encounter a 403 or 401 situation, and, if so, needs to short-circuit the execution of the sequence.

Unfortunately, short-circuiting of sequences can only be done by reject()'ing in action B. Today, this results in the web-exporter communicating a 400 to the client: no opportunity for clearing server-side session cookies, or redirecting the client to a login page.

More broadly, I suggest that B should not know about web-export. It should simply reject the request. It is the entire sequence S that has been exported, so the notion of web-oriented error handling should be encapsulated at the level of S, not B.

We could accomplish this by supporting a catch operator. For example:

wsk package bind Http BluemixHttp -p redirect_uri https://bluemix.net/login
wsk action update S A,B,C --annotation catch BluemixHttp/403

i.e. when the sequence short-circuits, invoke the action Http/403. Here, we have the opportunity to provide a general package Http that implements common catch patterns.

I did performance test for Openwhisk with New Scheduler (pull-based activation). When it comes to test with 5000 RPS, hundred of error happened. Then, I checked it by invoked the tested action from WSK CLI and get error response

error: Unable to invoke action 'perfTest': Too many requests (code 74bd570f6b048c437664907592f07bbe).

I waited for 4 hours with hope that the action will be normal again. But it seems like the action cannot be normal anymore (always return 'too many requests' error).

After long of waiting, I try to re-created the function (delete existing function and create the new one with the same name and kind) and still got too many requests error.

Is that the true behavior? or that is a bug?

Environment details:

• distributed deployment, all VMs (AWS EC2 Instance) are Linux
• 2 VMs Controller, 4 VMs Invoker, 2 VMs Scheduler, 1 VMs ETCD

Steps to reproduce:

1. Create simple nodejs action, for example perfTest action
2. Test perfTest action with 5000 RPS for 1 minutes. We use wrk 2 as a tool. Below is the commad wrk -t10 -c10 -d60s -R5000 --script post.lua --latency https://owserver/api/v1/namespaces/_/actions/perfTest?blocking=false
3. Wait until test finished with some of errors
4. Try to invoke perfTest action

Expected results:

invocation success:

{
    "params": {}
}

Actual results:

invocation error:

error: Unable to invoke action 'perfTest': Too many requests (code 74bd570f6b048c437664907592f07bbe)
Run 'wsk --help' for usage.

Additional information:

• The perfTestaction back to normal after Scheduler was restarted. There us no other way besides that.

This is an urgent task.

As Travis announced the end of unlimited support for open-source projects, we need to migrate to GitHub-Actions. Please take a look: https://cwiki.apache.org/confluence/display/INFRA/Travis+Migrations

We have 26 repos and all of them should be migrated to GitHub Actions by the end of 2022.

Hi, we have come across a reporting issue/bug(?). So in the case of activations of a working custom docker image, occasionally there are some errors (reported as developer errors) especially with the indication of failure during initialization (no available POST /init endpoint). This happens mainly in cold starts.

Environment details:

Openwhisk deployment on top of kubernetes and Openshift, running on AWS VMs

Steps to reproduce the issue:

1. Create a docker action and register it (in our case a docker action based on the Node-RED server)
2. Test it so that it works ok (with proper INIT, RUN endpoints etc.)
3. Launch activations with the same input, normally finalizing with success, however occasionally some errors (developer error type) occur, especially in cold starts that happen after some inactivity time

Provide the expected results and outputs:

The action should finalize with success, example:

{
    "namespace": "guest",
    "name": "Inference_3fff08e8-3617-4eb4-b118-4229f30514e3.json",
    "version": "0.0.6",
    "subject": "guest",
    "activationId": "be308f36967d4613b08f36967df6138b",
    "start": 1658257753690,
    "end": 1658257762621,
    "duration": 8931,
    "statusCode": 0,
    "response": {
        "status": "success",
        "statusCode": 0,
        "success": true,
        "result": {
          },
    "logs": [],
    "annotations": [
        {
            "key": "path",
            "value": "guest/Inference_3fff08e8-3617-4eb4-b118-4229f30514e3.json"
        },
        {
            "key": "waitTime",
            "value": 6
        },
        {
            "key": "kind",
            "value": "blackbox"
        },
        {
            "key": "timeout",
            "value": false
        },
        {
            "key": "limits",
            "value": {
                "concurrency": 1,
                "logs": 10,
                "memory": 512,
                "timeout": 300000
            }
        }
    ],
    "publish": false
}

Provide the actual results and outputs:

The server has started ok inside the action container as seen in the logs. Given that it happens in cold starts, maybe there is some form of timeout that is violated for fetching the image? Does Openwhisk try to /init before the server inside the container is up? If yes then this is masked behind a misleading error message (developer error) or potentially there should be some retry from Openwhisk side?

{
    "namespace": "guest",
    "name": "Inference_3fff08e8-3617-4eb4-b118-4229f30514e3.json",
    "version": "0.0.6",
    "subject": "guest",
    "activationId": "1040685ebb1e444980685ebb1e64495a",
    "start": 1658257763885,
    "end": 1658257771584,
    "duration": 7699,
    "statusCode": 0,
    "response": {
        "status": "action developer error",
        "statusCode": 0,
        "success": false,
        "result": {
            "error": "The action failed during initialization: <!DOCTYPE html>\n<html lang=\"en\">\n<head>\n<meta charset=\"utf-8\">\n<title>Error</title>\n</head>\n<body>\n<pre>Cannot POST /init</pre>\n</body>\n</html>\n"
        }
    },
    "logs": [
        "2022-07-19T19:09:23.899349481Z stdout: ",
        "2022-07-19T19:09:23.899349481Z stdout: > [email protected] start /usr/src/node-red",
        "2022-07-19T19:09:23.899349481Z stdout: > node $NODE_OPTIONS node_modules/node-red/red.js $FLOWS \"--userDir\" \"/data\"",
        "2022-07-19T19:09:23.899349481Z stdout: ",
        "2022-07-19T19:09:26.301015945Z stdout: 19 Jul 19:09:26 - [info] ",
        "2022-07-19T19:09:26.301015945Z stdout: ",
        "2022-07-19T19:09:26.301015945Z stdout: Welcome to Node-RED",
        "2022-07-19T19:09:26.301015945Z stdout: ===================",
        "2022-07-19T19:09:26.301015945Z stdout: ",
        "2022-07-19T19:09:26.302106314Z stdout: 19 Jul 19:09:26 - [info] Node-RED version: v2.2.2",
        "2022-07-19T19:09:26.302956696Z stdout: 19 Jul 19:09:26 - [info] Node.js  version: v14.19.1",
        "2022-07-19T19:09:26.303139937Z stdout: 19 Jul 19:09:26 - [info] Linux 5.14.14-200.fc34.x86_64 x64 LE",
        "2022-07-19T19:09:27.305314368Z stdout: 19 Jul 19:09:27 - [info] Loading palette nodes",
        "2022-07-19T19:09:31.219388687Z stdout: 19 Jul 19:09:31 - [info] Settings file  : /data/settings.js",
        "2022-07-19T19:09:31.220267452Z stdout: 19 Jul 19:09:31 - [info] Context store  : 'default' [module=memory]",
        "2022-07-19T19:09:31.221039641Z stdout: 19 Jul 19:09:31 - [info] User directory : /data",
        "2022-07-19T19:09:31.221229505Z stdout: 19 Jul 19:09:31 - [warn] Projects disabled : editorTheme.projects.enabled=false",
        "2022-07-19T19:09:31.239239234Z stdout: 19 Jul 19:09:31 - [info] Flows file     : /data/flows.json",
        "2022-07-19T19:09:31.340091186Z stdout: 19 Jul 19:09:31 - [info] Server now running at http://127.0.0.1:8080/",
        "2022-07-19T19:09:31.617204409Z stdout: 19 Jul 19:09:31 - [info] Starting flows",
        "2022-07-19T19:09:31.709196934Z stdout: 19 Jul 19:09:31 - [info] Started flows",
        "2022-07-19T19:09:31.584796934Z stderr: The action did not initialize or run as expected. Log data might be missing."
    ],
    "annotations": [
        {
            "key": "path",
            "value": "guest/Inference_3fff08e8-3617-4eb4-b118-4229f30514e3.json"
        },
        {
            "key": "waitTime",
            "value": 4199
        },
        {
            "key": "kind",
            "value": "blackbox"
        },
        {
            "key": "timeout",
            "value": false
        },
        {
            "key": "limits",
            "value": {
                "concurrency": 1,
                "logs": 10,
                "memory": 512,
                "timeout": 300000
            }
        },
        {
            "key": "initTime",
            "value": 7699
        }
    ],
    "publish": false
}

Additional information you deem important:

The issue seems to happen always in the first cold start case after a long time of inactivity. So maybe this is triggered by longer delays needed for fetching more container layers from the registry.

Bumps Newtonsoft.Json from 12.0.1 to 13.0.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Error during processing of request: 'Request too large: Request of size 89252740 was longer than the maximum of 52428800'. Completing with 500 Internal Server Error response. To change default exception handling behavior, provide a custom ExceptionHandler. akka.http.scaladsl.model.EntityStreamException: Request too large: Request of size 89252740 was longer than the maximum of 52428800 at akka.http.scaladsl.model.HttpEntity.toStrict(HttpEntity.scala:89) at akka.http.scaladsl.model.HttpEntity.toStrict$(HttpEntity.scala:87) at akka.http.scaladsl.model.HttpEntity$Default.toStrict(HttpEntity.scala:370) at akka.http.scaladsl.server.directives.BasicDirectives.$anonfun$toStrictEntity$3(BasicDirectives.scala:400) at akka.http.scaladsl.server.directives.BasicDirectives.$anonfun$textract$2(BasicDirectives.scala:161) at akka.http.scaladsl.server.directives.BasicDirectives.$anonfun$mapRouteResult$2(BasicDirectives.scala:68) at akka.http.scaladsl.server.directives.BasicDirectives.$anonfun$mapRouteResultWith$2(BasicDirectives.scala:74) at akka.http.scaladsl.server.directives.BasicDirectives.$anonfun$textract$2(BasicDirectives.scala:161) at akka.http.scaladsl.server.directives.BasicDirectives.$anonfun$mapRequestContext$2(BasicDirectives.scala:45) at akka.http.scaladsl.server.directives.BasicDirectives.$anonfun$mapRouteResult$2(BasicDirectives.scala:68) at akka.http.scaladsl.server.directives.BasicDirectives.$anonfun$textract$2(BasicDirectives.scala:161) at akka.http.scaladsl.server.directives.BasicDirectives.$anonfun$textract$2(BasicDirectives.scala:161) at akka.http.scaladsl.server.directives.BasicDirectives.$anonfun$mapRouteResult$2(BasicDirectives.scala:68) at akka.http.scaladsl.server.directives.BasicDirectives.$anonfun$textract$2(BasicDirectives.scala:161) at akka.http.scaladsl.server.directives.BasicDirectives.$anonfun$textract$2(BasicDirectives.scala:161) at akka.http.scaladsl.server.directives.BasicDirectives.$anonfun$mapRouteResultWith$2(BasicDirectives.scala:74) at akka.http.scaladsl.server.directives.BasicDirectives.$anonfun$textract$2(BasicDirectives.scala:161) at akka.http.scaladsl.server.directives.ExecutionDirectives.$anonfun$handleExceptions$2(ExecutionDirectives.scala:32) at akka.http.scaladsl.server.directives.BasicDirectives.$anonfun$textract$2(BasicDirectives.scala:161) at akka.http.scaladsl.server.Route$.$anonfun$asyncHandler$1(Route.scala:86) at akka.stream.impl.fusing.MapAsyncUnordered$$anon$31.onPush(Ops.scala:1376) at akka.stream.impl.fusing.GraphInterpreter.processPush(GraphInterpreter.scala:523) at akka.stream.impl.fusing.GraphInterpreter.execute(GraphInterpreter.scala:409) at akka.stream.impl.fusing.GraphInterpreterShell.runBatch(ActorGraphInterpreter.scala:606) at akka.stream.impl.fusing.GraphInterpreterShell$AsyncInput.execute(ActorGraphInterpreter.scala:485) at akka.stream.impl.fusing.GraphInterpreterShell.processEvent(ActorGraphInterpreter.scala:581) at akka.stream.impl.fusing.ActorGraphInterpreter.akka$stream$impl$fusing$ActorGraphInterpreter$$processEvent(ActorGraphInterpreter.scala:749) at akka.stream.impl.fusing.ActorGraphInterpreter$$anonfun$receive$1.applyOrElse(ActorGraphInterpreter.scala:764) at akka.actor.Actor.aroundReceive(Actor.scala:539) at akka.actor.Actor.aroundReceive$(Actor.scala:537) at akka.stream.impl.fusing.ActorGraphInterpreter.aroundReceive(ActorGraphInterpreter.scala:671) at akka.actor.ActorCell.receiveMessage(ActorCell.scala:612) at akka.actor.ActorCell.invoke(ActorCell.scala:581) at akka.dispatch.Mailbox.processMailbox(Mailbox.scala:268) at akka.dispatch.Mailbox.run(Mailbox.scala:229) at akka.dispatch.Mailbox.exec(Mailbox.scala:241) at akka.dispatch.forkjoin.ForkJoinTask.doExec(ForkJoinTask.java:260) at akka.dispatch.forkjoin.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1339) at akka.dispatch.forkjoin.ForkJoinPool.runWorker(ForkJoinPool.java:1979) at akka.dispatch.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:107)

Please look at the above problem, which configuration needs to be modified [email protected]

Description

Scheduler queue metrics for individual actions generates too many metrics since the action version is included in the metric name currently as a part of the action name. This PR breaks that up so that if kamon tags is not used the action version is not included in the met. Also one fix specifically to the queueActivation metric where the metric name had the namespace twice because the passed in string was $namespace/$action and the full entity path string of $action already includes the namespace.

I'm kept it such that the kamon tag will still include the version on the action tag value for now unless that becomes a problem as well.

Related issue and scope

• [ ] I opened an issue to propose and discuss this change (#????)

My changes affect the following components

• [ ] API
• [ ] Controller
• [ ] Message Bus (e.g., Kafka)
• [ ] Loadbalancer
• [X] Scheduler
• [ ] Invoker
• [ ] Intrinsic actions (e.g., sequences, conductors)
• [ ] Data stores (e.g., CouchDB)
• [ ] Tests
• [ ] Deployment
• [ ] CLI
• [ ] General tooling
• [ ] Documentation

Types of changes

• [X] Bug fix (generally a non-breaking change which closes an issue).
• [ ] Enhancement or new feature (adds new functionality).
• [ ] Breaking change (a bug fix or enhancement which changes existing behavior).

Checklist:

• [X] I signed an Apache CLA.
• [X] I reviewed the style guides and followed the recommendations (Travis CI will check :).
• [ ] I added tests to cover my changes.
• [ ] My changes require further changes to the documentation.
• [ ] I updated the documentation where necessary.