swim
swim copied to clipboard
JoinValueLane.remove(key) occasionally fails
Has been observed very sporadically. Needs more experimentation to determine whether the underlying downlink properly gets closed, or if the lane simply contains the last value. Unfortunately this seems to be very hard to reproduce.
The JoinValueLanes that observed this behavior used String
keys and Long
keys, and pojo
values whose Forms
cast non-distinct Items
to null
-- if that happens to make a difference. When the issue happens, it can be observed both on the server side and on the client side:
- Server side: after
remove()
is invoked and fails, iterate over the lane. The lane will still reportnull
values under the keys, rather than the expected behavior of not revealing those keys in the first place. - Client side: downlinking to the lane reveals the keys present but without any corresponding values, e.g. using
swim-cli
might return@update(key:2313084330)
.
Note that for a given lane, it is possible that the first happens but not the second. I'm not sure whether the second can happen without the first.
It is a JoinValueLane.remove()
problem because the following logic is present in a sample app:
@SwimLane("unsubscribe")
private CommandLane<String> unsubscribe = this.<String>commandLane()
.onCommand(uri -> {
this.statuses.remove(uri);
final String k = uri.substring("/submission/".length());
this.reviewed.remove(k);
this.answered.remove(k);
this.unanswered.remove(k);
this.unreviewed.remove(k);
});
where statuses
is a JVL, and the remainder are MapLanes. The MapLanes always update correctly.
Possibly related to #107.