signalr/dcrank

The new stuff

dcrank's Issues

DCrank should handle unrecognized messages on standard IO

For instance: SignalR trace messages written to Standard Output

Fix warnings

Compiling DCrank results in many warnings. With the azure deployment the first step we recommend is to build the project. As an end user if I see all these warnings I would not know if I did something wrong or why I am seeing all these warnings and if something needs to be done before proceeding.
The build should always be clean.

DCrank should support sending messages at rates lower than 1 per second

Investigate adding unit tests for javascript

Look into unit tests for javascript with something like Phantom

Use a proper command line parser for crank.exe

Worker does not terminate if agent crashes

Separate Stop and Kill scenarios

My understanding is that we want to handle 2 distinct scenarios - (1) stopping a worker gracefully which would shut down a connection and then kill the process. (2) killing the worker process abruptly.

We need to make the required changes on the UI to allow the user to issue these 2 types of commands.

UI Changes

Remove agent ID from UI.
Fix issue involving duplicate messages in the agent log.

What is DCrank?

What is DCrank?

Command line parser does not separate properties for different modes

The CmdLine package does not have explicit support for the 'executable command [arguments]' format used by DCrank.

Either rework how CmdLine is being used (i.e. switch to the token mode) or replace CmdLine with a different parser that is more adaptable to the DCrank use case.

SetupTest shoudl get the connection ids of agents instead of number of agents

@mikary @intern-felicco

In order to solve the connection remainder problem, we need to be able to send messages to individual agents so we need the connection ids.

Parsing errors in Worker/Agent communication are not reported to TestController

Modify UI to enable auto scenario to test max number of connections possible

*Make an option available that lets you test this scenario
*Do want to send any messages during this test - if so the test flow needs to change
*The workers should not appear yellow because there is no target number of connections

In SendTestInfoAuto in ControllerHub numberOfAgents is 0 even when an agent is running

Communication between the Agent and Workers is not thread-safe

Give Client.CreateConnection a more accurate name

The method name should be more descriptive of the actual behavior, i.e. CreateAndStart

Small UI fixes/updates

*Messages per second : change label to messages per sec per connection
*remove 'N/A' and 'TBA' from the UI (where possible, given the information we have)
*given agents and workers names like Agent 1, put the ids elsewhere in the display
*Once you are looking at workers, it's not clear how one can go back to the 'agent level'..how to transition between different levels should be more intuitive

DCrank should allow users to stop sending without disconnecting

Add number of connections to the agent tile

When logging connected, disconnected number of connections, do at agent level and not worker

Agent worker dictionary is not threadsafe

Sending an invalid URL to a worker crashes the agent

Sort out threading model and decouple logger implementation in DCrank agent/worker

Worker responds to each ping multiple times

Seems to be an increase in the number of pings when more agents are connected.

Clicking Start Test increases number of messages instead of resetting

Use of Parallel For in Agent.cs introduces race conditions

Add ability to specify number of connections per worker in manual mode

Stop button for worker needs to gracefuly disconnect

Add option to disconnect without starting to send messages from clients

Stacking kill commands and Pings blocks the thread (stopping heartbeats) and causes a disconnect of the agent

Make Agent-Worker message payload more flexible