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 report null 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.
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
Stringkeys andLongkeys, andpojovalues whoseFormscast non-distinctItemstonull-- 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:remove()is invoked and fails, iterate over the lane. The lane will still reportnullvalues under the keys, rather than the expected behavior of not revealing those keys in the first place.swim-climight 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:where
statusesis a JVL, and the remainder are MapLanes. The MapLanes always update correctly.Possibly related to #107.