[tor-bugs] #12651 [Onionoo]: Details documents of non-running nodes may contain "running":true
Tor Bug Tracker & Wiki
blackhole at torproject.org
Mon Dec 1 10:58:04 UTC 2014
#12651: Details documents of non-running nodes may contain "running":true
-------------------------+--------------------------
Reporter: karsten | Owner: karsten
Type: defect | Status: needs_review
Priority: normal | Milestone:
Component: Onionoo | Version:
Resolution: | Keywords:
Actual Points: | Parent ID:
Points: |
-------------------------+--------------------------
Comment (by iwakeh):
You did do quite some testing on the mirror. So, it should be ok to merge
to master and deploy.
One issue I see is the "hostname-hack":
Is there a way to avoid the unnecessary additional lookup (after an update
to the new format) computationally rather than by changing the code after
the first run?
Other than that I only have some minor things and coding style issues
which could be implemented at some point later.
a) In NodeStatus:124
{{{
if (orAddressAndPort.contains(":") &&
orAddressAndPort.length() > 0)
}}}
wouldn't
{{{ if (orAddressAndPort.contains(":")) }}}
suffice?
b) NodeStatus:432
{{{
...
written = 0;
for (String orAddressAndPort : this.orAddressesAndPorts) {
sb.append((written++ > 0 ? "+" : "") + orAddressAndPort);
}
...
}}}
As commons-lang3 is available, why not use StringUtils.join?
{{{
sb.append(StringUtils.join(this.exitAddresses, "+"));
}}}
This would apply to a few other places, too:
{{{
src/main/java/org/torproject/onionoo/docs/NodeStatus.java:433:
sb.append((written++ > 0 ? "+" : "") + orAddressAndPort);
src/main/java/org/torproject/onionoo/docs/NodeStatus.java:440:
sb.append((written++ > 0 ? "+" : "") + exitAddress);
src/main/java/org/torproject/onionoo/docs/NodeStatus.java:449:
sb.append((written++ > 0 ? "," : "") + relayFlag);
src/main/java/org/torproject/onionoo/docs/NodeStatus.java:482:
sb.append((written++ > 0 ? ";" : "") + familyFingerprint);
src/main/java/org/torproject/onionoo/docs/ClientsHistory.java:125:
sb.append((written++ > 0 ? "," : "") + e.getKey() + "="
src/main/java/org/torproject/onionoo/server/PerformanceMetrics.java:67:
sb.append((written++ > 0 ? ", " : "") + string + " ("
src/main/java/org/torproject/onionoo/server/PerformanceMetrics.java:100:
sb.append((j > 0 ? ", " : "") + "." + permilles[j]
src/main/java/org/torproject/onionoo/server/PerformanceMetrics.java:111:
sb.append((j > 0 ? ", " : "") + "." + permilles[j] + "<null");
src/main/java/org/torproject/onionoo/server/ResponseBuilder.java:154:
addressesBuilder.append((written++ > 0 ? "," : "") + "\""
}}}
=== Coding Style
Well, when reading through code, the coding style also gets some focus.
Thus, a few suggestions for the contributer guide:
NodeDetailsStatusUpdater:236
{{{
int orPort = entry.getOrPort(), dirPort = entry.getDirPort();
}}}
Such declarations are a little less readable imho;
and, they can trip up IDEs during refactoring.
I'd prefer
{{{
int orPort = entry.getOrPort();
int dirPort = entry.getDirPort();
}}}
instead.
So, maybe we could add this to the contributing guide?
In addition, there are many places where 'null' values are validated,
e.g. {{{ if(someVariable == null) ... }}}.
It might be better to always use {{{ if(null == someVariable) ...}}}
in order to avoid accidental assigment by style?
In quite a few places I encountered if-statements that lead to a silent
method exit, e.g.
{{{
if(someBooleanExpression){
return;
}
}}}
A debug logging statement with a reason might be of value in these cases;
for both reading the code and later on when programming maintenance or
enhancements.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/12651#comment:10>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list