Seaside session timeout problem?

Louis LaBrunda

unread,

Jun 12, 2021, 12:28:25 PM6/12/21

to VAST Community Forum

Hi All,

I have a little problems with my RaspberryRelay Seaside program. It of course runs on Linux and is built with VA Smalltalk v9.2.2. If I inadvertently leave a session open for a while (the last time was about 2 hours and 45 minutes) the system hangs. By that I mean the current page won't close and I can't connect in and create a new session. A reboot solves the problem.

My guess is a lot of memory is being use and that hangs the system. I don't have any evidence of that yet, I'm open to suggestions as to how to obtain it.

I think the default timeout is 30 minutes. I don't think I have changed it. If the timeout is 30 minutes, it would seem that the problem occurs before the 30 minutes is up and the session is closed.

If this is a problem with running out of memory, I wonder if I can check the memory used and available and at some point kill any open old session?

Suggestions please.

Lou

Marcus Wagner

unread,

Jun 12, 2021, 2:46:16 PM6/12/21

to VAST Community Forum

Hi Lou,

i had the same problem communicating with a server using restful api with json.

From time to time, a service hung. No reaction. Nothing left than to kill the program. Experimentally once I waited a full day.

if did not had luck and glorious insight, I would still sit here and wait until forever.

The point is - there is no timeout - except you program it yourself!

The insight was: if you send something and wait on a response, no body else other than you can setup a reliable time out.

Try this or a similar code around the socket receive

    (result :=
        [localEndpoint receive]
            whenTimeoutInMilliseconds: 20000 "20 seconds"
            do: [:sig |
            sig exitWith: (SstError for: SstConstants::ExSstNonFatalError with: 'receive timeout')])
                isSstError
                    ifTrue: [result raise].

[Protocol is implemented in SstLocalEndpoint>>receive and Block>>whenTimeoutInMilliseconds: you will find in SstKernelExtensions]

This avoids the endless wait without no return.

However this only half of the medal: around this code you have to supply some sophisticated retry logic, as you have to properly shutdown this fruitless communication session and set up a new attempt - I guess you want to proceed in cases of simple glitches.

I count the retries and decided to dynamically adjust the timeout period (10, 20, 40 seconds) based on experience of the behaviour of the specific end point.

Hope that helps...

Kind regards

Marcus

Marcus Wagner

unread,

Jun 12, 2021, 2:58:40 PM6/12/21

to VAST Community Forum

Hi Lou,

I forgot something to add - I assume that you read data from your weather service and run Seaside around your app to have web access. If this is the case, than consider my code snippet as the receive blocks - if I am right the hang has absolutely nothing to do with Seaside...

Noschvie

unread,

Jun 14, 2021, 6:17:05 AM6/14/21

to VAST Community Forum

Hi Lou

did you have tested your "timeout issue" (Seaside application ?) with VAST 10.0.1 under Windows ?

br

Norbert

Louis LaBrunda

unread,

Jun 14, 2021, 8:58:53 AM6/14/21

to VAST Community Forum

Hi Guys,

Norbert: I haven't tested under v10.0.1 in windows. I will give v9.2.2 a try in the windows development just to see what happens because that is easy to do. I may be able to see what is happening. Testing under v10.0.1 is more work and since I can only use v9.2.2 on the Raspberry at the moment because the v10.0.1 binaries don't exist, it may not help much.

Marcus: I hadn't thought about the fetch of the weather data being the problem. I will look into it. The timeout I was talking about was the Seaside session. I thought that after 30 minutes of inactivity, Seaside would kill the session. I am using Ajax to update information, like the time and weather info, so that may keep the session alive. I will have to check into that.

Back to the weather fetch, I'm using "SstHttpClient fetch: url". I have a doctors appointment this morning, when I get back I will look to see if there is someway to set a timeout for it. Or, if Seth reads this, he may beat me to it.

Thanks for the help guys!

Lou

Louis LaBrunda

unread,

Jun 14, 2021, 9:04:01 AM6/14/21

to VAST Community Forum

Hi,

Actually, I'm doing this:

weatherData := [(SstHttpsUrl fromString: url) fetch] on: Error do: [:sig | sig exitWith: nil].

The other fetch was for latitude and longitude, which isn't done automatically. I should probably see if I should catch errors for that.

As for the weather, I will look to see if there is a timeout that on:do: catches or can catch.

Lou

Esteban Maringolo

unread,

Jun 14, 2021, 9:28:48 AM6/14/21

to va-sma...@googlegroups.com

I don't know exactly how you have your app organized, but at least
from the Seaside point of view, expired Sessions are swept "lazily",
meaning that there is no background process checking whether a Session
is expired, but on each access to the cache it will call
#sweepIncrementally.

If it works for you, you can define a maximum age of the session,
meaning that it will expire by being old (and not necessarily idle).

But if you only have one session, and nothing starts a new session,
then it will never reap the old session.

An workaround is to have a JS background loop in the browser (using
setInterval() o recursively via setTimeout()) that "pings" the server
with an empty callback, on each request this will check whether the
session key belongs to an active session, and it will expire the
session if it exceeds the maximum age.

On the server side you could have a forked process that loops and
waits on a Delay, and manually calls the sweepIncrementally, but
you'll have to fiddle with the internals of your WAApplication, get
the cache, etc.

Regards!

Esteban A. Maringolo

> --
> You received this message because you are subscribed to the Google Groups "VAST Community Forum" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to va-smalltalk...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/va-smalltalk/35aa8a90-4b4a-4db4-be28-d6fb12ca30dcn%40googlegroups.com.

Marcus Wagner

unread,

Jun 14, 2021, 11:27:00 AM6/14/21

to VAST Community Forum

Hi Lou,

your code snippet "(SstHttpsUrl fromString: url) fetch" perfectly matches my old case: fetch internally calls localEndpoint receive.

So If anything happens [power loss, line defect, machine down, service crash, packet loss...] the fetch will never come back and your code will wait forever.

As of this, in turn the calling process is blocked.

Now it depends it you decoupled this call from Seaside.

If not, this will also block a process of Seaside and further your whole image seems to be dead [it is not: it is still waiting for input on an open socket, but there is nobody to send something anymore].

Sockets behave very stable on this.

My code example yesterday was applied to the internal representation of a fetch (for other reasons) and too complicated for your call.

Give this code snippet a chance, apply the timeout protocol on the outside of the fetch:

weatherData :=
[

[(SstHttpsUrl fromString: url) fetch] whenTimeoutInMilliseconds: 20000 "20 seconds"

] on: Error do: [:sig | sig exitWith: nil].

It guarantees you not to block longer than 20 seconds and then return nil.

And consider to decouple service accesses from Seaside threads (similar to old school, from the UI process).

Kind regards

Marcus

L...@Keystone-Software.com schrieb am Samstag, 12. Juni 2021 um 18:28:25 UTC+2:

Louis LaBrunda

unread,

Jun 14, 2021, 2:58:40 PM6/14/21

to VAST Community Forum

Hi Guys,

While waiting to see the doctor, I gave Marcus' idea some thought and came up with the same code as he did. I think he meant to say this:

weatherData := [

[(SstHttpsUrl fromString: url) fetch] whenTimeoutInMilliseconds: 20000 do: [:toSig |

toSig exitWith: (SstError for: ExSstNonFatalError with: MxSSTG122)]

] on: Error do: [:sig | sig exitWith: nil].

I assume he left a little out by accident.

Lou

Louis LaBrunda

unread,

Jun 14, 2021, 5:48:21 PM6/14/21

to VAST Community Forum

Hi,

I packaged and installed on the Raspberry, left a web browser window open for a couple of hours without a problem. That doesn't "prove" the problem is fixed but it looks good.

Lou

Noschvie

unread,

Jun 15, 2021, 1:23:36 AM6/15/21

to VAST Community Forum

Hi Lou

maybe you could add a counter to know the number of timeouts per hour?

br

Norbert

Noschvie

unread,

Jun 15, 2021, 2:01:08 AM6/15/21

to VAST Community Forum

... have added the OpenWeather API call to our application just to have a look to timeouts..

Norbert

Noschvie

unread,

Jun 15, 2021, 4:05:56 AM6/15/21

to VAST Community Forum

... running the SstHttpClient with #get: to retrieve the OpenWeather API (with an interval of 10 seconds) seems to end with a memory leak (VAST 10.0.1 x64 and Windows)

Louis LaBrunda

unread,

Jun 15, 2021, 11:05:40 AM6/15/21

to VAST Community Forum

Hi Guys,

I have added my KscWeather app to VAST Goodies. There is a single class (#KscOpenWeatherMap) that makes it easier to call the One Call API of Open Weather API.

In my RaspberryRelay program I use #KscOpenWeatherMap as a singleton. Most calls for the weather forecast are made to #currentForecast. It checks to see how old the forecast is and only refreshes it if it is older than #oldAgeLimit minutes old (defaults to 15 minutes). Please note that some of the comments are out of date, they reference a time when constants were used. I will go over them and update them soon.

Norbert, I find your test of calling for the weather every 10 seconds interesting. I expect someone will have to look into the memory leak. It may be a long term problem for me, as opposed to a short term problem because I only get the forecast every 15 minutes, about 100 times a day.

As for counting the timeouts, I will take a look. I have code to log things, so I will see if how easy it is to log the timeouts. I would prefer not to add the logging/counting code to the #KscOpenWeatherMap class but to add it to the code that calls for the forecast. If an empty dictionary is returned, some kind of error occurred, could be a timeout, could be some other error.

Lou

Mariano Martinez Peck

unread,

Jun 15, 2021, 1:47:22 PM6/15/21

to VA Smalltalk

On Tue, Jun 15, 2021 at 5:05 AM Noschvie <norbert....@neunzehn.at> wrote:

... running the SstHttpClient with #get: to retrieve the OpenWeather API (with an interval of 10 seconds) seems to end with a memory leak (VAST 10.0.1 x64 and Windows)

Hi Norbert,

Not sure what that means but if you indeed have a memory leak please send an email to support with the necessary details and information please.

Best,

--