Update docs

Author: ethanhann

docs-src/commands.md

@@ -103,6 +103,16 @@ Run your command:
 inengine.exe -pMyCommandPlugin my-command
 ```
 
+### Executing Arbitrary Processes
+
+It isn't necessary to create C# classes to utilize InEngine.NET.
+Arbitrary commands can be run, with an argument list by leveraging the InEngine.Core plugin's **proc** command.
+The command lists directory contents using "ls" with the "-lhp" switches:
+
+```bash
+inengine.exe -pInEngine.Core proc -c"/bin/ls" -a"-lhp"
+```
+
 ## View Available Plugins
 
 Run inengine.exe without any arguments to see a list of plugins:

docs-src/queuing.md

@@ -1,8 +1,10 @@
 # Queuing
 
+InEngine.NET's queue functionality allows for commands to be run in the background with a simple publish/consume model. 
+
 ## Prerequisites
 
-Redis is required to use the InEngine.NET Queue feature. 
+Redis is required to use the InEngine.NET queue feature. 
 It can be installed on Ubuntu with this command:
 
 ```bash
@@ -19,22 +21,27 @@ sudo service redis start
 It is highly recommended to <a href="https://redis.io/topics/security#authentication-feature">set a password</a> for Redis.
 </div>
 
-## Working with Queues
-
-### Publishing Commands
+## Publishing Commands
 
-#### Programmatically
+### From Code
 
 [Commands](commands) can be published programmatically with the **InEngine.Core.Queuing.Broker** class:
 
 ```c#
 Broker.Make().Publish(new MyCommand());
 ```
 
-#### From the Command Line
+Or publish to the secondary queue:
+
+```c#
+Broker.Make(true).Publish(new MyCommand());
+```
+
+### From the Command Line
+
 Commands can be published from the command line as well.
 Note that all queue commands reside in the **InEngine.Core** plugin.
-This is an example of how to publish a command from the CLI by specifying the commands assembly, class name, and arguments:
+This is an example of how to publish a command from the CLI by specifying the command's plugin, class name, and arguments:
 
 ```bash
 inengine.exe -pInEngine.Core queue:publish --command-plugin=MyCommandPlugin.dll --command-class=MyCommand --args "text=bar"
@@ -52,9 +59,9 @@ The command verb can also be specified instead of the full class name:
 inengine.exe -pInEngine.Core queue:publish --command-plugin=InEngine.Core.dll --command-verb=echo--args "text=foo"
 ```
 
-### Consuming Commands
+## Consuming Commands
 
-#### Programmatically
+### From Code
 Consuming a command is also accomplished with the Broker class:
 
 ```c#
@@ -70,7 +77,7 @@ Broker.Make(true).Consume();
 
 Commands can be consumed from the command line as well with this simple command:
 
-#### From the Command Line
+### From the Command Line
 
 ```bash
 inengine.exe -pInEngine.Core queue:consume
@@ -82,22 +89,86 @@ Use the **--secondary** argument to consume the secondary queue instead of the p
 inengine.exe -pInEngine.Core queue:consume --secondary
 ```
 
-#### With the Scheduler
+### With the Scheduler
 
 The InEngine scheduler is needed to consume queued messages in the background. 
 There are a variety of [ways to run the scheduler](scheduling/#running-the-scheduler).
 
+## Examining the Queue
+
+### Viewing Queue Lengths
+
+The **queue:length** command shows a quick summary of pending, in-progress, and failed commands in the primary and secondary queues:
+
+```bash
+inengine.exe -pInEngine.Core queue:length
+```
+
+### Peek at Commands
+
+The **queue:peek** command allows for queued commands to be inspected:
+
+```bash
+inengine.exe -pInEngine.Core queue:peek --pending --in-progress --failed
+```  
+
+It is of course possible to peek in the secondary queues:
+
+```bash
+inengine.exe -pInEngine.Core queue:peek --pending --secondary
+```
+
+Queued commands can be viewed in JSON which maybe useful for debugging:
+
+```bash
+inengine.exe -pInEngine.Core queue:peek --pending --json
+```  
+
+By default, up to 10 messages will be retrieved, but the number is configurable:
+
+```bash
+inengine.exe -pInEngine.Core queue:peek --pending --limit=100
+```
+
+The a paginated slice of the queue can be retrieved using the offset argument.
+For example, this queue:peek call retrieves the 100-200 queued commands:
+
+```bash
+inengine.exe -pInEngine.Core queue:peek --pending --limit=100 --offset=100
+```
+
+## Handling Failed Commands
+
+Commands that throw an exception are put in a special "failed" queue. 
+They can be republished with the **queue:republish** command:
+
+```bash
+inengine.exe -pInEngine.Core queue:republish
+```
+
+Failed secondary queue commands can be republished as well:
+
+```bash
+inengine.exe -pInEngine.Core queue:republish --secondary
+```
+
+By default, only 100 failed commands are republished at a time.
+The is configurable:
+
+```bash
+inengine.exe -pInEngine.Core queue:republish --limit=1000
+```
 
 ## Primary and Secondary Queue
 
 Other than the fact that the primary queue is used by default, there is no difference between the primary and secondary queues. 
-However, it is often desirable to have more than 1 queue. 
+However, it is often desirable to use two queues. 
 For example, long running jobs might be sent to the secondary queue, 
 while jobs that are expected to finish after only a few moments are sent to the primary queue.
 
 What about 3, 4, or 900 queues? Managing numerous queues gets to be a pain and, practically speaking, is probably unnecessary.
 If it is desirable, different [configuration files](configuration) can be used to run multiple instances of InEngine.NET.
-Simply create a new [config file](configuration) with a new QueueName setting and point inengine.exe at it with the -c argument:
+Simply create a new config file with a new QueueName setting and point inengine.exe at it with the -c argument:
 
 ```bash
 inengine.exe -cMyCustomSettingsFile.json -pInEngine.Core queue:consume

docs-src/scheduling.md

@@ -156,15 +156,14 @@ Running the scheduler from the CommandLine is useful for debugging or local deve
 inengine.exe -s
 ```
 
-It can also be run on Mac/Linux with Mono.
+It can also be run on Mac and Linux with Mono via a shell wrapper script:
 
 ```bash
-mono inengine.exe -s
+./inengine -s
 ``` 
 
 ### On Windows as a Service
 
-
 #### Installing
 Run the Install.ps1 PowerShell script in the scheduler directory to install the scheduler in place. 
 The script needs to be run as an administrator.