Seaside walkback post install

[sanjayminni]

I start getting this walkback anytime shortly after installing seaside. tried multiple times in all combinations with a clean image

also the seaside control panel does not come up in Dolphin shell

The seaside initial welcome server at localhost:8080 does come up.

Errors file is also attached

DPRO.txt

[rko281]

I haven't ported the Seaside control panel to Dolphin I'm afraid.

Could you confirm which version of Dolphin you're using? I've loaded Seaside into a recent D7.1 image (February) and its been running for a while with no errors.

[sanjayminni]

this starts happening erratically after a couple of image saves / exits / restarts. I am using 7.1.20 let me observe

…

On Fri, 16 Apr 2021 at 22:44, John Aspinall ***@***.***> wrote: I haven't ported the Seaside control panel to Dolphin I'm afraid. Could you confirm which version of Dolphin you're using? I've loaded Seaside into a recent D7.1 image (February) and its been running for a while with no errors. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC3ZGLWRFWWZNURZFMHZONTTJBV5VANCNFSM43AYLZEA> .

[sanjayminni]

Here is a way i reproduced it (D7.1.20 Windows 10)

• started with a clean image
• loaded seaside thru package browser
• moved around in welcome screen played with counter
• saved image in dolphin (welcome screen still open) (*see note 1 below)
• then closed the welcome screen but other tabs in browser open not related to seaside
• saved image again
• exited
• restarted dolphin and ... error message appeared

however saving image with a seaside web screen still open is not the only way - i keep getting it in various ways to the point if D7+Seaside being impossible to use

DPRO-SeasideWebOpenImageSave.txt

here is another attempt

DPROerrors.txt

[rko281]

Thanks for the detailed info, I was able to reproduce the issue.

Could I request you re-raise the issue in fxgallego/DolphinHttpServer? The issue looks to be in this library rather than Seaside.

[sanjayminni]

I Will raise

…

On Mon, 19 Apr, 2021, 1:21 pm John Aspinall, ***@***.***> wrote: Thanks for the detailed info, I was able to reproduce the issue. Could I request you re-raise the issue in fxgallego/DolphinHttpServer <https://github.com/fxgallego/DolphinHttpServer>? The issue looks to be in this library rather than Seaside. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC3ZGLQAXEVVRWAEX4QXUEDTJPOJJANCNFSM43AYLZEA> .

[sanjayminni]

I raised the issue in https://github.com/fxgallego/DolphinHttpServer and Sebastian took a look at it,
fxgallego/DolphinHttpServer#15

But Dolphin+DolphinHttpServer Demo works perfectly. Issue arises after installing Seaside . I have detailed my observation is the DolphinHttpServer/issues/15 above

separately I am dropping a mail marked to Sebastian and yourself to resolve this if possible as I am stuck

[rko281]

I've spent some time looking at this and think the issue is around the termination of the server listener process.

After installing Seaside, with the Process Monitor open you can see there is a single HTTP Server Listener (bottom process):

After snapshotting there are now two:

Attempting to snapshot a third time generates the following error:

Exiting and restarting the image now gives the UndefinedObject does not understand #asInteger error; at this point there are now three listener processes.

The problem can be reproduced without snapshotting by restarting the Seaside Server as follows:

WAServerManager shutDown; startup

Evaluating this code a few times results in the double listener process issue followed by The IO operation has been aborted... error, as per snapshotting. However, running the two instructions separately with a small gap is generally OK (no duplicate listeners; no errors):

WAServerManager shutDown.
"Wait a moment"
WAServerManager startup

I think therefore that the issue is that the listener process is not given the opportunity to terminate during the server shutdown (performed prior to snapshotting and image shutdown). I'd like to propose the following fix to HttpServerListener>>stop to address this:

stop
	state := #stopping.
	loop ifNotNil: [loop priority: Processor activeProcess priority; terminate. Processor yield].
	queue ifNotNil: [queue close].
	urlGroup ifNotNil: [urlGroup close].
	threadPool ifNotNil: [threadPool stop].
	queue := urlGroup := loop := threadPool := nil.
	state := #stopped

The modification boosts the priority of the loop (listener) process to that of the active process prior to termination, allowing it to process the termination signal when the active process yields.

With this modification in place I am able to follow the original instructions without any errors resulting.

[sanjayminni]

Hi John Should i share this with Sebastian @ https://github.com/fxgallego/DolphinHttpServer who was working on this ? You could post it in the Dolphin smalltalk group where I made a post on this or for quicker turn around let me have your ID and I will mark a common mail to him. regards

…

On Fri, 30 Apr 2021 at 17:44, John Aspinall ***@***.***> wrote: I've spent some time looking at this and think the issue is around the termination of the server listener process. After installing Seaside, with the Process Monitor open you can see there is a single HTTP Server Listener (bottom process): [image: image] <https://user-images.githubusercontent.com/16988710/116691713-24687e00-a9b3-11eb-9cc0-a89040825482.png> After snapshotting there are now two: [image: image] <https://user-images.githubusercontent.com/16988710/116691752-30ecd680-a9b3-11eb-8a36-e5f76f054a10.png> Attempting to snapshot a third time generates the following error: [image: image] <https://user-images.githubusercontent.com/16988710/116691813-47932d80-a9b3-11eb-951b-73791507e4e0.png> Exiting and restarting the image now gives the UndefinedObject does not understand #asInteger error; at this point there are now three listener processes. The problem can be reproduced without snapshotting by restarting the Seaside Server as follows: WAServerManager shutDown; startup Evaluating this code a few times results in the double listener process issue followed by The IO operation has been aborted... error, as per snapshotting. However, running the two instructions separately with a small gap is generally OK (no duplicate listeners; no errors): WAServerManager shutDown."Wait a moment"WAServerManager startup I think therefore that the issue is that the listener process is not given the opportunity to terminate during the server shutdown (performed prior to snapshotting and image shutdown). I'd like to propose the following fix to HttpServerListener>>stop to address this: stop state := #stopping. loop ifNotNil: [loop priority: Processor activeProcess priority; terminate. Processor yield]. queue ifNotNil: [queue close]. urlGroup ifNotNil: [urlGroup close]. threadPool ifNotNil: [threadPool stop]. queue := urlGroup := loop := threadPool := nil. state := #stopped The modification boosts the priority of the loop (listener) process to that of the active process prior to termination, allowing it to process the termination signal when the active process yields. With this modification in place I am able to follow the original instructions without any errors resulting. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#6 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC3ZGLREMKTTIKD7HN2UQLTTLKNLZANCNFSM43AYLZEA> .

[sanjayminni]

posted it at DolhinHttpServer and response is here
fxgallego/DolphinHttpServer#15 (comment)

in the meanwhile I have made the change in my image and will keep working and let you know if If there there is an issue