Lukáš Kvídera

This behaviour is already described in another issue https://github.com/payara/Payara/issues/2881

I think it is exactly the same scenario. _1. We log into app “A” and do some work._ -> **this session is not associated to SSO** _2. We then use...

Hi @AlanRoth , I need to collect more data. Yes, it is default Payara's implementation configured via metrics.xml.

Found hint in code: ``` // PAYARA-486 & PAYARA-1224 Correct the incorrect incrementation - needs further looking at ``` Incomplete attempts: https://github.com/payara/Payara/pull/561 https://github.com/payara/Payara/pull/1217

Method `sessionDestroyedEvent` is caled at least 20 times when hitting F5 on specific page. Session id stays the same.

FlashLightProbe#invokerList contains 36 identical listeners. ``` {Integer@15119} 142 -> {ReflectiveClientInvoker@15120} "id=142, target=org.glassfish.web.admin.monitor.SessionStatsProvider@2ea1e2fe, method=public void org.glassfish.web.admin.monitor.SessionStatsProvider.sessionDestroyedEvent(java.lang.String,java.lang.String,java.lang.String), paramNames=[sessionId, appName, hostName], probeIndices=[0, 1, 2], useProbeArgs=true, hasComputedParams=false" {Integer@15111} 158 -> {ReflectiveClientInvoker@15096} "id=158, target=org.glassfish.web.admin.monitor.SessionStatsProvider@31998dfa, method=public...

It seems that each war in ear registers own listener hook, but event does not care about war locality and executes all attached listeners from whole ear.

Fix seems to be easy... crafting a new code.

And fix is already present as isValidEvent method, and I am looking at a wrong place.

I have Examined positive values and they do not seem to be correct too. Some event happened and all numbers are going mad.