Search Crosser Knowledge Base

FAQ

What happens to the order of messages in the queue if the first message fails to deliver but new messages arrive?

Understanding message queues: Failed messages go to a dead letter queue and can be restored or deleted via the Node API if persistence is enabled.

How do we handle or track messages that get dropped from the message queue before the connection is re-established?

Tracking dropped messages: With persistent messages enabled, dropped messages go to the dead letter queue and can be restored or deleted via the Node API.

What should I do when recreating a Crosser Edge Node with a different name on the same host machine?

Recreating a Crosser Edge Node on the same host with a different name.

How can I remove credentials from a deployed flow?

Credentials cannot be deleted if they are used in a read-only version of a deployed flow, as doing so would invalidate that version. If the flow version is no longer deployed/needed you can delete that version and then delete the credential.

Can I scale up performance with multiple nodes?

There is no automatic scaling but processing can be split over multiple nodes by for example selecting subsets of data using filter conditions or separate by data sources.

What is the performance of the Crosser Node?

One of the great benefits with Crosser is the performance, tests show that we can process >100 000 messages per second on a pretty basic VM. A Raspberry Pi3 can process about 8000 messages per second.

Flow-to-Flow Communication

Split your use cases into smaller Flows and bind them together with the concept of Flow-to-Flow communication.

Can I have redundant nodes?

There is no automated support for redundant nodes. However, the same flow can be installed on multiple nodes and started from the Cloud service on failure. You can also use container management tools, such as Kubernetes, to build high-availability setups with Crosser Nodes.

What ports need to be open when using the Crosser node?

The Edge node communicates with the Crosser Control Center is using HTTPS on port 443. The HTTPS port is also used by many modules that connects to web services. All traffic is initiated from the edge node, so this port must be open for outbound traffic. Locally port 9090 is used for inbound HTTP(S) traffic to the HTTP Listener module and port 1883 / 8883 for inbound MQTT traffic (MQTT Sub Broker/Client modules). The local web UI and API is accessed through port 9191. Inbound port mappings are configurable.

Can the Crosser Node sit behind a proxy?

Yes, the Crosser Node needs to be configured locally when sitting behind a proxy. See here for more information. By default Crosser Nodes uses websocket communication with Crosser Cloud during remote sessions, so if the proxy does not support websockets the default configuration needs to be changed.