WARequestContextNotFound after seaside-flow call:

Am 20.05.2020 um 23:01 schrieb Brodbeck Andreas via Glass <[hidden email]>:

Hi all

I have a stubborn "bug" or other creature which I can not catch after days of trying my best... Before I will eventually file a bug report, may I ask you if this problem sounds familiar to someone?

Bug summary:
Exception WARequestContextNotFound after seaside's call/answer

Steps:

1. I have a seaside application running in GemStone 3.4.5, latest Seaside, latest GsDevKit.
2. From the main seaside UI-component I simply open another seaside component with seaside's call: method.
3. I press the "close" UI-button, which calls seaside's answer method of that component.
4. I get a WARequestContextNotFound exception.

My observations:

--- Bug DOES NOT show up, if I use call:onAnswer: instead of call:. So it probably narrows down to the usage of GRPlatform current seasideSuspendFlowDo:, since that is what call: is using to suspend the flow with continuations.

--- Seaside's error handling will in turn fail itself because it also relies on calling current requestContext itself. Only a simple text based stack is placed on GemStone's ObjectLog. And the browser just shows a simple "Internal Error:"

--- WACurrentRequestContext is a WADynamicVariable and as such uses the environment dictionary of the active GsProcess (via something like this: Processor activeProcess environment at: WACurrentRequestContext). With stupid pseudo debugging (since I can't get a real debugger to work) I figured out, that after call:/answer the GsProcess changes and starts with an empty environment, therefore missing the WACurrentRequestContext.

--- Seaside tests all green


I'm really exhausted. Any clues or similar experiences?

Thanks!

Cheers, Andreas


-----------------------------------------
Brot? www.brotrezept.ch!

Andreas Brodbeck
Software-Macher
mindclue GmbH
Dipl. El.-Ing. ETH

+41 55 622 26 24
www.mindclue.ch
-----------------------------------------

_______________________________________________
Glass mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/glass

Am 21.05.2020 um 13:54 schrieb Jupiter Jones <[hidden email]>:

Hi Andreas,

I use call:onAnswer: a lot and just changed a couple of them to call: just to see… and had the same issue.

Seaside is installed from the main Seaside repo on Github in GemStone 3.5.1.

Without a debugger it’s not easy to pinpoint but a quick look at the log and the various call: methods, it does look like there’s something going on with GRPlatform current seasideSuspendFlowDo:

Had the same issue with #wait: …as would be expected if the issue is in GRPlatform current seasideSuspendFlowDo:

Cheers,

Phil

PS Copied this message to the Seaside list just in case someone there has seen this before.

On 21 May 2020, at 6:52 pm, Brodbeck Andreas via Glass <[hidden email]> wrote:

Additional astonishing observation: In a plain installation without any code from mine the WAFlowFunctionalTest fails! (GemStone 3.4.5, latest Seaside, latest GsDevKit, Platform Linux)

(I previously reported "all tests green" but that did not include the functional tests ...)

Since this would be a bug at the heart of seaside, I doubt my observations. I will investigate some more.

Cheers, Andreas

Am 20.05.2020 um 23:01 schrieb Brodbeck Andreas via Glass <[hidden email]>:

Hi all

I have a stubborn "bug" or other creature which I can not catch after days of trying my best... Before I will eventually file a bug report, may I ask you if this problem sounds familiar to someone?

Bug summary:
Exception WARequestContextNotFound after seaside's call/answer

Steps:

1. I have a seaside application running in GemStone 3.4.5, latest Seaside, latest GsDevKit.
2. From the main seaside UI-component I simply open another seaside component with seaside's call: method.
3. I press the "close" UI-button, which calls seaside's answer method of that component.
4. I get a WARequestContextNotFound exception.

My observations:

--- Bug DOES NOT show up, if I use call:onAnswer: instead of call:. So it probably narrows down to the usage of GRPlatform current seasideSuspendFlowDo:, since that is what call: is using to suspend the flow with continuations.

--- Seaside's error handling will in turn fail itself because it also relies on calling current requestContext itself. Only a simple text based stack is placed on GemStone's ObjectLog. And the browser just shows a simple "Internal Error:"

--- WACurrentRequestContext is a WADynamicVariable and as such uses the environment dictionary of the active GsProcess (via something like this: Processor activeProcess environment at: WACurrentRequestContext). With stupid pseudo debugging (since I can't get a real debugger to work) I figured out, that after call:/answer the GsProcess changes and starts with an empty environment, therefore missing the WACurrentRequestContext.

--- Seaside tests all green


I'm really exhausted. Any clues or similar experiences?

Thanks!

Cheers, Andreas


-----------------------------------------
Brot? www.brotrezept.ch!

Andreas Brodbeck
Software-Macher
mindclue GmbH
Dipl. El.-Ing. ETH

+41 55 622 26 24
www.mindclue.ch
-----------------------------------------

On 21 May 2020, at 14:29, Brodbeck Andreas via Glass <[hidden email]> wrote:

Hi Phil

In the meantime I figured out, that the problem was introduced between Seaside v3.2.5 and v3.3.0. call:/answer works OK with Seaside v3.2.5

They have changed the platform specific implementation of WADynamicVariable (which WACurrentRequestContext is a subclass of). On GemStone this is now a subclass of GemStone's own DynamicVariable class, which in turn uses "Processor activeProcess environment at:" to get the value of the dynamic variable.

I managed to figure out, that the "Processor activeProcess" changes after call:/answer and therefore the environment is blank and the current request context is gone, obviously. I don't know at which point the activeProcess is changed. But my guess is somewhere around GemServer?

I keep investigating. Looking forward for hints from GemStone staff! ;-)

Cheers, Andreas 

Am 21.05.2020 um 13:54 schrieb Jupiter Jones <[hidden email]>:

Hi Andreas,

I use call:onAnswer: a lot and just changed a couple of them to call: just to see… and had the same issue.

Seaside is installed from the main Seaside repo on Github in GemStone 3.5.1.

Without a debugger it’s not easy to pinpoint but a quick look at the log and the various call: methods, it does look like there’s something going on with GRPlatform current seasideSuspendFlowDo:

Had the same issue with #wait: …as would be expected if the issue is in GRPlatform current seasideSuspendFlowDo:

Cheers,

Phil

PS Copied this message to the Seaside list just in case someone there has seen this before.

On 21 May 2020, at 6:52 pm, Brodbeck Andreas via Glass <[hidden email]> wrote:

Additional astonishing observation: In a plain installation without any code from mine the WAFlowFunctionalTest fails! (GemStone 3.4.5, latest Seaside, latest GsDevKit, Platform Linux)

(I previously reported "all tests green" but that did not include the functional tests ...)

Since this would be a bug at the heart of seaside, I doubt my observations. I will investigate some more.

Cheers, Andreas

Am 20.05.2020 um 23:01 schrieb Brodbeck Andreas via Glass <[hidden email]>:

Hi all

I have a stubborn "bug" or other creature which I can not catch after days of trying my best... Before I will eventually file a bug report, may I ask you if this problem sounds familiar to someone?

Bug summary:
Exception WARequestContextNotFound after seaside's call/answer

Steps:

1. I have a seaside application running in GemStone 3.4.5, latest Seaside, latest GsDevKit.
2. From the main seaside UI-component I simply open another seaside component with seaside's call: method.
3. I press the "close" UI-button, which calls seaside's answer method of that component.
4. I get a WARequestContextNotFound exception.

My observations:

--- Bug DOES NOT show up, if I use call:onAnswer: instead of call:. So it probably narrows down to the usage of GRPlatform current seasideSuspendFlowDo:, since that is what call: is using to suspend the flow with continuations.

--- Seaside's error handling will in turn fail itself because it also relies on calling current requestContext itself. Only a simple text based stack is placed on GemStone's ObjectLog. And the browser just shows a simple "Internal Error:"

--- WACurrentRequestContext is a WADynamicVariable and as such uses the environment dictionary of the active GsProcess (via something like this: Processor activeProcess environment at: WACurrentRequestContext). With stupid pseudo debugging (since I can't get a real debugger to work) I figured out, that after call:/answer the GsProcess changes and starts with an empty environment, therefore missing the WACurrentRequestContext.

--- Seaside tests all green


I'm really exhausted. Any clues or similar experiences?

Thanks!

Cheers, Andreas


-----------------------------------------
Brot? www.brotrezept.ch!

Andreas Brodbeck
Software-Macher
mindclue GmbH
Dipl. El.-Ing. ETH

+41 55 622 26 24
www.mindclue.ch
-----------------------------------------

_______________________________________________
Glass mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/glass

Am 21.05.2020 um 16:55 schrieb Johan Brichau <[hidden email]>:

Hi Andreas,

Would it be possible to provide a repeatable scenario so I can take a look?

Perhaps report it via https://github.com/SeasideSt/Seaside/issues and give a pointer to it here (to remind me)?

The fact that Processor activeProcess changes reminds me of https://github.com/GsDevKit/Seaside31/issues/71 (mind this is an issue in the ‘old’ Seaside 3.1 repo for Gemstone, the current version is on the https://github.com/SeasideSt/Seaside/ repo).

And indeed we moved the implementation of WADynamicVariable to GRDynamicVariable in Grease etc…but afaik call/answer should work as before.

So, a repeatable case would be helpful to dive into this.

best

Johan

On 21 May 2020, at 14:29, Brodbeck Andreas via Glass <[hidden email]> wrote:

Hi Phil

In the meantime I figured out, that the problem was introduced between Seaside v3.2.5 and v3.3.0. call:/answer works OK with Seaside v3.2.5

They have changed the platform specific implementation of WADynamicVariable (which WACurrentRequestContext is a subclass of). On GemStone this is now a subclass of GemStone's own DynamicVariable class, which in turn uses "Processor activeProcess environment at:" to get the value of the dynamic variable.

I managed to figure out, that the "Processor activeProcess" changes after call:/answer and therefore the environment is blank and the current request context is gone, obviously. I don't know at which point the activeProcess is changed. But my guess is somewhere around GemServer?

I keep investigating. Looking forward for hints from GemStone staff! ;-)

Cheers, Andreas 

Am 21.05.2020 um 13:54 schrieb Jupiter Jones <[hidden email]>:

Hi Andreas,

I use call:onAnswer: a lot and just changed a couple of them to call: just to see… and had the same issue.

Seaside is installed from the main Seaside repo on Github in GemStone 3.5.1.

Without a debugger it’s not easy to pinpoint but a quick look at the log and the various call: methods, it does look like there’s something going on with GRPlatform current seasideSuspendFlowDo:

Had the same issue with #wait: …as would be expected if the issue is in GRPlatform current seasideSuspendFlowDo:

Cheers,

Phil

PS Copied this message to the Seaside list just in case someone there has seen this before.

On 21 May 2020, at 6:52 pm, Brodbeck Andreas via Glass <[hidden email]> wrote:

Additional astonishing observation: In a plain installation without any code from mine the WAFlowFunctionalTest fails! (GemStone 3.4.5, latest Seaside, latest GsDevKit, Platform Linux)

(I previously reported "all tests green" but that did not include the functional tests ...)

Since this would be a bug at the heart of seaside, I doubt my observations. I will investigate some more.

Cheers, Andreas

Am 20.05.2020 um 23:01 schrieb Brodbeck Andreas via Glass <[hidden email]>:

Hi all

I have a stubborn "bug" or other creature which I can not catch after days of trying my best... Before I will eventually file a bug report, may I ask you if this problem sounds familiar to someone?

Bug summary:
Exception WARequestContextNotFound after seaside's call/answer

Steps:

1. I have a seaside application running in GemStone 3.4.5, latest Seaside, latest GsDevKit.
2. From the main seaside UI-component I simply open another seaside component with seaside's call: method.
3. I press the "close" UI-button, which calls seaside's answer method of that component.
4. I get a WARequestContextNotFound exception.

My observations:

--- Bug DOES NOT show up, if I use call:onAnswer: instead of call:. So it probably narrows down to the usage of GRPlatform current seasideSuspendFlowDo:, since that is what call: is using to suspend the flow with continuations.

--- Seaside's error handling will in turn fail itself because it also relies on calling current requestContext itself. Only a simple text based stack is placed on GemStone's ObjectLog. And the browser just shows a simple "Internal Error:"

--- WACurrentRequestContext is a WADynamicVariable and as such uses the environment dictionary of the active GsProcess (via something like this: Processor activeProcess environment at: WACurrentRequestContext). With stupid pseudo debugging (since I can't get a real debugger to work) I figured out, that after call:/answer the GsProcess changes and starts with an empty environment, therefore missing the WACurrentRequestContext.

--- Seaside tests all green


I'm really exhausted. Any clues or similar experiences?

Thanks!

Cheers, Andreas


-----------------------------------------
Brot? www.brotrezept.ch!

Andreas Brodbeck
Software-Macher
mindclue GmbH
Dipl. El.-Ing. ETH

+41 55 622 26 24
www.mindclue.ch
-----------------------------------------

_______________________________________________
Glass mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/glass