Seaside session timeout problem?

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

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

[hidden email] schrieb am Samstag, 12. Juni 2021 um 18:28:25 UTC+2:

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

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...

Marcus Wagner schrieb am Samstag, 12. Juni 2021 um 20:46:16 UTC+2:

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

[hidden email] schrieb am Samstag, 12. Juni 2021 um 18:28:25 UTC+2:

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

Hi Lou

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

br

Norbert

[hidden email] schrieb am Samstag, 12. Juni 2021 um 20:58:40 UTC+2:

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...

Marcus Wagner schrieb am Samstag, 12. Juni 2021 um 20:46:16 UTC+2:

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

[hidden email] schrieb am Samstag, 12. Juni 2021 um 18:28:25 UTC+2:

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

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

On Monday, June 14, 2021 at 6:17:05 AM UTC-4 Noschvie wrote:

Hi Lou

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

br

Norbert

[hidden email] schrieb am Samstag, 12. Juni 2021 um 20:58:40 UTC+2:

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...

Marcus Wagner schrieb am Samstag, 12. Juni 2021 um 20:46:16 UTC+2:

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

[hidden email] schrieb am Samstag, 12. Juni 2021 um 18:28:25 UTC+2:

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

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

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

[hidden email] schrieb am Samstag, 12. Juni 2021 um 18:28:25 UTC+2:

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

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

On Monday, June 14, 2021 at 11:27:00 AM UTC-4 [hidden email] wrote:

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

[hidden email] schrieb am Samstag, 12. Juni 2021 um 18:28:25 UTC+2:

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

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

On Monday, June 14, 2021 at 2:58:40 PM UTC-4 Louis LaBrunda wrote:

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

On Monday, June 14, 2021 at 11:27:00 AM UTC-4 [hidden email] wrote:

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

[hidden email] schrieb am Samstag, 12. Juni 2021 um 18:28:25 UTC+2:

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

Hi Lou

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

br

Norbert

[hidden email] schrieb am Montag, 14. Juni 2021 um 23:48:21 UTC+2:

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

On Monday, June 14, 2021 at 2:58:40 PM UTC-4 Louis LaBrunda wrote:

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

On Monday, June 14, 2021 at 11:27:00 AM UTC-4 [hidden email] wrote:

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

[hidden email] schrieb am Samstag, 12. Juni 2021 um 18:28:25 UTC+2:

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

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

Norbert

Noschvie schrieb am Dienstag, 15. Juni 2021 um 07:23:36 UTC+2:

Hi Lou

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

br

Norbert

[hidden email] schrieb am Montag, 14. Juni 2021 um 23:48:21 UTC+2:

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

On Monday, June 14, 2021 at 2:58:40 PM UTC-4 Louis LaBrunda wrote:

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

On Monday, June 14, 2021 at 11:27:00 AM UTC-4 [hidden email] wrote:

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

[hidden email] schrieb am Samstag, 12. Juni 2021 um 18:28:25 UTC+2:

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

... 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)

Noschvie schrieb am Dienstag, 15. Juni 2021 um 08:01:08 UTC+2:

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

Norbert

Noschvie schrieb am Dienstag, 15. Juni 2021 um 07:23:36 UTC+2:

Hi Lou

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

br

Norbert

[hidden email] schrieb am Montag, 14. Juni 2021 um 23:48:21 UTC+2:

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

On Monday, June 14, 2021 at 2:58:40 PM UTC-4 Louis LaBrunda wrote:

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

On Monday, June 14, 2021 at 11:27:00 AM UTC-4 [hidden email] wrote:

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

[hidden email] schrieb am Samstag, 12. Juni 2021 um 18:28:25 UTC+2:

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