B4J Question ABMaterial: Detect a dead page?

[techknight]

So I have an application that requires a one-person-at-a-time operation. So if one person is signed in, nobody else can take control unless he/she closes the browser.

So far, that works fine. But.... if said person just simply walks away, or switches WiFi without closing the browser (mobile device) then the web session becomes "dead".

I tried simply adding a timer in the Page that uses the websocket to run some code on the client side that acts like a ping, but if the page goes "dead" the timer just doesn't work anymore. I was hoping it would force/detect the dead websocket, and run websocket_disconnected, but it doesnt. the code just vaporizes.

so the webapp simply sits there and does nothing. But since the "websocket disconnected" event never fires on the dead page, it wont clear its session out to allow another to connect.

I need an easier way to track a dead page.

any ideas? thanks.

 

[alwaysbusy]

it wont clear its session out to allow another to connect.

Yes it will when needed. Jetty will do the garbage collection, and so does the ABM lib with the classes.

 

[techknight]

Then how do I make it do it? because it never did. if it does, it takes hours.

Thoughts?

Edit: Is it this I have to mess with?

    Public CacheScavengePeriodSeconds As Int = 30*60 ' 30 Minutes 
    ' -1 = immortal but beware! This also means your cache is NEVER emptied!
    Public SessionMaxInactiveIntervalSeconds As Int = 1440*60 ' 24 hours

 

[Cableguy]

Yeap!

 

[Harris]

Yeap

And so, what does he do to "mess" with it... Suspect - set a shorter interval...

 

[techknight]

thats what I thought.

I did toy around with the values, made it super short for testing purposes.

I noticed in doing that, even if the page is active on the screen with a valid websocket connection, it'll get kicked when that routine runs. Hmmm. (This is on windows). also my websocket test/kick routine works fine running the jar in windows.

But... the other weird thing, the routine never runs on Pi, and neither does the Expired cache cleanup. Its very odd.

 

[OliverA]

the routine never runs on Pi, and neither does the Expired cache cleanup. Its very odd.

Total stupid guess/hunch: Do you think it (the routine ABM uses) needs an RTC on the pi for it to work correctly? I know I purchased a seperate RTC for the pi I purchased. Please note I'm posting this w/o any research, so I could be making to total fool out of myself (would not be the first time )

 

[Cableguy]

I don't think so, since it doesn't use any real time values.
Another approach just came to me...
You could set a long timer, like 30m or 1h, but it must be larger than the sessionmaxinactiveinterval, and check if the cookie is still available.
If it is, then the session is still valid...

 

[alwaysbusy]

The other weird thing, the routine never runs on Pi, and neither does the Expired cache cleanup.

Weird indeed because that would mean that workers and timers don’t work on a pi.

Which values do you now use in your tests? If to short, jetty will indeed kick it if it hasn’t had done any communication in that timeslot. That is why ABM sends a heartbeat every half of your sessinmaxinactve value. Cachescavenge works also best half of sessionmaxinactive

 

[techknight]

I tried this:

Public SessionMaxInactiveIntervalSeconds As Int = 1*60

on the PC it took about a minute before that routine ran.

On the Pi, it eventually ran, but it took a VERY long time. like an hour and a half or so