Opened 2 weeks ago

Last modified 9 days ago

#2524 new defect

Duplicate tunnels shown in participating tunnels table on /tunnels

Reported by: Reportage Owned by: sadie
Priority: minor Milestone: undecided
Component: apps/console Version: 0.9.40
Keywords: /tunnels, participating Cc:
Parent Tickets: Sensitive: no


Duplicate tunnels are frequently shown in the participating tunnels table. From observation, it appears that only one duplicate pair is displayed in a given timeframe, and the duplicate will disappear before the end of the tunnel lifetime.


Change History (3)

comment:1 Changed 2 weeks ago by zzz

Can't reproduce here yet, although I understand it's intermittent. Please confirm this couldn't be caused by any local changes of yours, and also that it's an actual duplicate (i.e. same "receive on" ID, not just same "from" and "to" hops). Part. tunnels are indexed and stored internally by the unique receive ID, so I don't immediately see how dups would be possible.

comment:2 Changed 13 days ago by Reportage

Yes, I can confirm that the tunnels are actual duplicates with identical tunnels ids for receive on/send on, identical bandwidth usage, and identical expiry time. This wasn't so obvious when sorting by bandwidth, but when sorting by expiry date it's very easy to spot, as the first dupe tunnel of the pair always appears at the top of the table (when sorting from newest to oldest).

I don't think there's any local changes that should be causing this, and I vaguely recall seeing this problem long before I did any modifications to the tunnel renderer. The following edit to TunnelRenderer?.java should demonstrate the issue unless there's something I've missed:

    private static class TunnelComparator implements Comparator<HopConfig>, Serializable {
         public int compare(HopConfig l, HopConfig r) {
//             return (r.getProcessedMessagesCount() - l.getProcessedMessagesCount());
//             return (l.getProcessedMessagesCount() - r.getProcessedMessagesCount());
             long le = l.getExpiration();
             long re = r.getExpiration();
             if (le < 0)
                 le = 0;
             if (re < 0)
                 re = 0;
             if (le < re)
                 return 1;
             if (le > re)
                 return -1;
             return 0;

comment:3 Changed 9 days ago by zzz

still can't reproduce here after many days running, tested both my mod (to sort by receive ID) and yours (sorting by expiration). Neither of those should change along the way. The original code (sorting by message count) could, perhaps, generate a bad sort, perhaps with duplicates, because the sort data isn't fixed - it could change in the middle of the sort, thus corrupting the sort or even throwing an unchecked exception. The behavior may vary depending on JVM version. We have an exception-safe variant of the sort that we're not using there now. But you haven't reported any exception. No ideas atm.

Note: See TracTickets for help on using tickets.