New architecture

This new version is primarily an internal architecture change, where flows are now even more separated by running as individual processes. This first version is designed to be backwards compatible with existing flows (with some exceptions, see below) but going forward new features and modules will be added that require this architecture.

Highlights

• Flows run as individual processes
• Better reporting of issues to Crosser Cloud
• Python included in all Docker images (Python version 3.9.6)
• Local UI and API for monitoring of node health
• More intuitive processing of messages in complex flows
• The installation of a Node as a Windows service has changed

For more details, see Changes below.

A word of caution

Even though we have done extensive testing to validate backwards compatibility, both internally and at select customers, we strongly recommend that you first verify your flows in a safe environment before upgrading critical production environments. This is also a good opportunity to upgrade all modules to the latest version, to make sure you get all the improvements and bug fixes.

The Memory Buffer module

There is one case where we had to break backwards compatibility: The Memory Buffer module. With this new node version every module will add a crosser object to the output messages to indicate the status of the operation. Previous versions of the Memory Buffer module uses the crosser.success property to acknowledge messages. Since every message added to the buffer will now have a crosser.success property they will be acknowledged immediately, instead of waiting for the feedback from an output module, or other logic. In the new version of the Memory Buffer module [2.0.0] the property to use for message acknowledgement is configurable and defaults to memorybuffer.success. If you are using the Memory Buffer module you must therefore upgrade to the latest version and rename the acknowledge property you want to use, e.g. using a Property Mapper module. Contact support@crosser.io if you need help with this.

Message processing

With the new architecture we have changed how messages are processed in flow modules, to get more intuitive and consistent behavior. If you have complex flows with multiple paths (branches) where the result depends on the order of execution along different paths (intentional or unintentional) you may see a changed behavior. Read more about these changes below or contact Crosser for more information.

Updating to the new version

Docker

In your docker.compose.yml files, make sure the image line looks like this:

image: docker.crosser.io/crosser/edgenode:latest

or if you want to refer to a specific version:

image: docker.crosser.io/crosser/edgenode:2.5.0

Then run sudo docker-compose pull followed by sudo docker-compose restart.

Windows service

The Windows service installation has changed a bit. You first need to uninstall the current version by following these steps:

1. Open a PowerShell window as Administrator and go to the directory where you installed the Crosser software
2. Run Crosser.EdgeNode.Service.Windows.exe stop followed by Crosser.EdgeNode.Service.Windows.exe uninstall

To install the new software, follow these steps:

Note: The new installer is implemented as a PowerShell script, therefore scripting must be enabled in PowerShell for scripts downloaded from the Internet. You can check your current execution policy with:

Get-ExecutionPolicy

Make sure it’s one of RemoteSigned, UnRestricted or Bypass, if not use the following command to change it:

Set-ExecutionPolicy -Scope Process UnRestricted

1. Download the new software from Crosser Cloud on the Nodes->Register Nodes->Advanced options->EdgeNode Windows Service Installers page. Select the latest (topmost) file.
2. Unzip the file into an empty directory.
3. Copy the data directory from your previous installation directory into the Host\data directory for your new installation.
4. Run .\InstallWindowsService.ps1
5. When asked for Id and Access key just hit return to use your existing credentials.
6. At the end of the installation, make sure to enter run (when asked) before hitting enter. Otherwise the service will only be installed but not started.
7. In Crosser Cloud verify that your node now is running version 2.5.0
8. Sync all your flows by selecting the Node on the Nodes page and then select all flows and click on Sync

See Installation for more information.

Changes

The following list presents changes where the behavior differs versus previous versions:

• Each flow runs in its own process
  • A misbehaving flow can never affect the operation of other flows.
  • If HaltOnError is set to false, flows that crash due to an error will be restarted automatically.
  • Each flow gets its own runtime which could increase the total amount of memory needed, depending on the number of flows deployed.
• Python
  • Python is now included in all Docker images, i.e. there are no images with -python tags.
  • The Python version is now 3.9.6.
• Image size
  • Due to the changes introduced with this version the Docker images are larger (~280 MB) than the previous non-python versions (~145 MB), but smaller than previous python versions (~550 MB).
• Local Monitoring UI and API
  • A new local UI is available at http://localhost:9191 (the port can be changed in Docker). With this UI the status of the node and the running flows can be monitored.
  • A new monitoring REST API is available at http://localhost:9191/api. This API can be used to monitor the node from other systems. See http://localhost:9191/swagger for a description of the API.
• Logs
  • Since flows now run as separate processes they also have their own logs. In the data/logs folder there are now two subfolders: host and flows, where the flows folder has a subdirectory for each deployed flow.
  • Logfiles can also be viewed through the monitoring UI (only host logs in this release).
• Remote debug
  • If only configuration changes are made to a flow, i.e. the same modules are used, restarting it in a remote session will be much faster since the modules are not downloaded every time.
• Message queing
  • The default behavior when processing messages in flow modules has been changed. This change primarily affects flows with multiple paths (branches), for single path flows there are no differenses in most cases.
  • In previous versions a single path was processed from start to finish before another path was processed. A path starts where a message originates, e.g. at an input module, a multi-branch or a module that aggregates messages, and ends in a module where the message processing finishes, e.g. an output module or a module that aggregates messages. This could sometimes lead to unintuitive behavior, where the order of execution was unclear, especially if modules that takes long time to complete an operation were used (such as I/O modules).
  • In the new node all modules have a message queue on the input and as long as there is room in the queue it will not block any processing. As a result slow processing in one path will not impact the processing along other paths in the same flow.
  • As a consequence of this change it is now possible to loop back an output from a module to another module located earlier in the flow. This would have created a dead-lock with previous versions, except when using some specially designed modules like the Memory Buffer and Delay modules.
  • New settings have been added in the common settings on all modules to control the queueing behavior. Both the size of the queue (default: infinite (up to available memory)) and the strategy for dealing with a full queue (default: Wait) can be configured. These are advanced settings that normally shouldn’t need to be changed. If you want to get the previous behavior, set the queue size to 1 and the Queue Full Mode to Wait.
• Windows service installation
  • The installation of the Windows service has changed, see Updating to the new version above.
• Status reports
  • The load reported by nodes (shown on the dashboard) is now an average of the load of the running flows.
  • For situations where bandwidth is limited it is now possible to reduce the amount of data sent to Crosser Cloud in the regular status reports (by default sent every 10 seconds). Using the new setting EdgeNodeConfiguration__pingsBetweenStatusReports a much smaller “ping” message can be used just to inform Crosser Cloud that the node is online, while a full status report is sent more infrequently. For example, if pingsBetweenStatusReports is set to 10 there will be 10 “ping” messages followed by one full status report, all messages sent at the specified reportStatusIntervalInSeconds.
• New Ping service: To help identify general networking issues the node can be setup to ping a public web service at regular intervals. Two new settings have been added to the Host/data/appsettings.json file, edgeNodeConfiguration.pingUri (default “google.com”) and edgeNodeConfiguration.pingEnabled (default “false”).