You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Vishal Sharda (JIRA)" <ji...@apache.org> on 2016/06/07 17:00:24 UTC
[jira] [Commented] (DISPATCH-360) Disallow router with duplicate ID
from joining the network
[ https://issues.apache.org/jira/browse/DISPATCH-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15318872#comment-15318872 ]
Vishal Sharda commented on DISPATCH-360:
----------------------------------------
Thanks Ted. I corrected my mistake and will continue testing without SSL. Is it possible to prevent the router with duplicate ID from joining the network? This subtle error can happen easily in large networks of routers.
> Disallow router with duplicate ID from joining the network
> ----------------------------------------------------------
>
> Key: DISPATCH-360
> URL: https://issues.apache.org/jira/browse/DISPATCH-360
> Project: Qpid Dispatch
> Issue Type: Improvement
> Components: Routing Engine
> Affects Versions: 0.6.0
> 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
> Reporter: Vishal Sharda
> Priority: Minor
> Attachments: Crash_bt_no_SSL.png, Crash_bt_no_SSL_2.png, config1_nossl.conf, config2_nossl.conf, config3_nossl.conf
>
>
> 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).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org