#6 Notification: departure before arrival

[Vadim Tkachenko]

java.lang.NullPointerException
at
net.sf.dz.daemon.onewire.OneWireServer.poll(OneWireServer.java:347)
at
net.sf.dz.daemon.onewire.OneWireServer.execute(OneWireServer.java:274)
at
org.freehold.jukebox.service.ActiveService$ExecWrapper.call(ActiveService.java:71)
at
org.freehold.jukebox.service.PassiveService.wrap(PassiveService.java:818)
at
org.freehold.jukebox.service.ActiveService$ActiveWrapper.run(ActiveService.java:113)
at java.lang.Thread.run(Thread.java:536)

[Vadim Tkachenko]

Logged In: YES
user_id=16279

The root cause is still unclear, but the code was modified
in such a way that this is now flagged as a warning, not an
error, condition, thus it doesn't break the rest of the
logic.

[Vadim Tkachenko]

Logged In: YES
user_id=16279

Update: this seems to be happening (at least sometimes)
because of the double departure notification, as shown here:

02/05 12:33:37.146 (application) [OWNetworkMonitor]:
Departed: CF00000020AA1512 from
DS9097U_/dev/ttyS0/1300000000E6B51F_0/
02/05 12:34:45.381 (application) [OWNetworkMonitor]:
Departed: CF00000020AA1512 from
DS9097U_/dev/ttyS0/1300000000E6B51F_0/5900000000E6B81F_0/
02/05 12:34:45.398 (application) [1-Wire]: Got the departure
notification before arrival notification for
CF00000020AA1512

[Vadim Tkachenko]

Logged In: YES
user_id=16279

It seems that this bug causes the 1-Wire devices to
disappear from the bus permanently - the root cause must be
found and fixed.

[Vadim Tkachenko]

Logged In: YES
user_id=16279

The root cause turned to be a bizarre one - OWPath returning
wrong hashCode(). As a result, same path could've been in
the path2device map multiple times, and still never matched.
Consequently, they were accumulating with each next
departure/arrival.

Side effect: the departure is handled much cleaner now, and
rescan logic has been improved - there will be no more races
between poll() and browse().

[Vadim Tkachenko]

Logged In: YES
user_id=16279

I hate this bug. It shows up after a few days of uptime and
never allows to reproduce itself at will...

[Vadim Tkachenko]

Logged In: YES
user_id=16279

Hopefully, fixed for good now. The DAC had been running for
the last 16 days without dropping sensors, even though
network fluctuactions and lightning storms have definitely
pushed it to the edge quite a few times.

Funny side effect (will have to be fixed somehow, just don't
know how to approach it yet): a device is seen migrating
between the path it is on and the root path. In a hindsight,
the reason is obvious - there will be circumstances under
which the device that is really on a main trunk arrives only
when the branch is open, therefore the arrival is
erroneously associated with the branch. Next time, the
device is registered on the main trunk, with obvious
consequences. Have to think about it. For the record, here's
how it looks like in the log:

08/17 14:17:18.380 (application) [OWNetworkMonitor]: Moved:
6D00080021DF5010 from DS9097U_/dev/ttyS0/1300000000E6B51F_0/
to DS9097U_/dev/ttyS0/
08/17 14:17:18.409 (application) [TCP/Broadcaster]:
Departed: 6D00080021DF5010
08/17 14:17:18.869 (application) [TCP/Controller]: Arrived:
6D00080021DF5010 (DS1920)
08/17 14:17:18.871 (application) [TCP/Broadcaster]: Arrived:
6D00080021DF5010 (DS1920)