[
https://issues.apache.org/jira/browse/SLING-4761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14790643#comment-14790643
]
Stefan Egli commented on SLING-4761:
------------------------------------
[~cziegeler], good news is I was able to reproduce. Bad news is I don't know
why the direct 'current'-check makes tests fail..
Here's more details as to what seems happening:
* during startup discovery.impl typically sends out multiple
{{PROPERTIES_CHANGED}}, this is 'legal'
* in {{JobManagerConfiguration.handleTopologyEvent}} there is a mechanism which
[ignores the event if only properties have changed but no job-relevant
ones|https://github.com/apache/sling/blob/trunk/bundles/extensions/event/src/main/java/org/apache/sling/event/impl/jobs/config/JobManagerConfiguration.java#L548]
* so if the capabilities-properties do change - even though the view is
otherwise the same - then this will result in a sequence of
{{stopProcessing}}/{{startProcessing}}
* in {{startProcessing}} there is a mechanism to [trigger an async job after
10sec|https://github.com/apache/sling/blob/trunk/bundles/extensions/event/src/main/java/org/apache/sling/event/impl/jobs/config/JobManagerConfiguration.java#L527]
(I guess to avoid blocking the handleTopologyEvent)
* so, what can happen is that such a delay-job is started, then a
PROPERTIES_CHANGED comes in, that one will have correctly marked the (previous)
view of the delay-job as not-current
* thus once that delay-job wakes up it *can* see that the view is not current,
so that is legal
What very likely adds to the confusion of the output you noticed, is the fact
that +{{TopologyViewImpl}} overwrites hashCode()+ for internal and testing
purpose (to have topologyViews comparable/'equalable'). So just from the fact
that you output the hashCode above and given they are equal as a just received
PROPERTIES_CHANGED event, doesn't make it the *same* view object. In fact,
adding more logging output showed that they were indeed different views - and
thus in this case it was valid/correct that the view is not current (the event
for that change was received 10sec earlier, which is before the last received
event in your log).
So to reply to the initial reported issues:
bq. It seems that the last view you get via a topology listener might get mark
as old (not current)
that would then not be true - this view here was marked !current 10 sec before:
{code} 28.05.2015 19:59:06.995 active check, hash code 2037323133, current :
false{code}
bq. The interesting thing is that the properties changed event is received
twice, with the same new view object, ten seconds later the view is not current
anymore but no topology event / change has been received by the listener.
Same here - given the hashCode is the way it is, these assumptions do not hold
- the views were likely different
Which brings me to the actual issue: I don't know why enabling that direct
'current' check on makes tests fail. But I suspect the problem is not the
'current' itself..
> Latest view seems to get marked as not current
> ----------------------------------------------
>
> Key: SLING-4761
> URL: https://issues.apache.org/jira/browse/SLING-4761
> Project: Sling
> Issue Type: Bug
> Components: Extensions
> Affects Versions: Discovery Impl 1.1.0, Discovery Impl 1.1.2
> Reporter: Carsten Ziegeler
> Assignee: Stefan Egli
> Fix For: Discovery Impl 1.1.8
>
>
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
