[DISPATCH-360] Disallow router with duplicate ID from joining the network

• Type: Improvement
• Status: Open
• Priority: Minor
• Resolution: Unresolved
• Affects Version/s: 0.6.0
• Fix Version/s: Backlog
• Component/s: Routing Engine

Environment

Debian 8.3, Apache Qpid Proton 0.12.2 for drivers and dependencies, Hardware: 2 CPUs, 15 GB RAM, 60 GB HDD on 3 separate machines

• Assignee: Unassigned
• Reporter: Vishal Sharda
• Created: 07/Jun/16 02:15
• Updated: 03/Apr/18 17:37

Description

In order to isolate the issues that I am getting with 2-way SSL connections among routers, I created a cluster of 3 inter-connected routers (R1, R2 and R3 with R2 connecting to R1 and R3 connecting to both R1 and R2) without any type of SSL (I had been using just 2 routers so far but our actual cluster consists of 3 nodes). All connections were insecure as shown in my config files.

When I tried sending 4 messages using simple_send.py to R1 after starting simple_recv.py to receive from R2, I saw no messages were sent.

If I stop R3 and reduce the cluster to just two nodes, it works fine.
If I have 2-way SSL connections between all the 3 routers, it again works fine.

In my more than 20 runs to test this scenario of sending just 4 messages, it even worked a few times after waiting for very long. In the other two cases above, I always got the messages instantaneously (there were no other senders/receivers active).

The drivers.tar.gz that I attached in DISPATCH-343 either timed out or returned with unclear status when trying to send just 4 messages from 1 sender (connected to R1) to 1 receiver (connected to R2). It showed successful just once. The behavior is completely non-deterministic.

This basic test working non-deterministically some times and failing most of the times seemed very weird and I turned to running routers outside gdb but the results were similar. In the process of stopping/restarting the 3 routers for testing this scenario, I also got a crash (backtrace attached).