[Glass] WARequestContextNotFound after seaside-flow call:

Thu May 21 08:32:49 PDT 2020

Andreas,

I now see you wrote that WAFlowFunctionalTest fails in Gemstone.
Will check on that.
The functional tests are not yet running automated in the build (wip), so I need to do that manually and I can tomorrow.

In the meantime, you might want to change WADynamicVariable to be a subclass of GRNotificationBasedDynamicVariable instead of GRDynamicVariable and see if that fixes it?

Johan

> On 21 May 2020, at 16:55, Johan Brichau <johan at yesplan.be> wrote:
> 
> 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 <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 <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/ <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 <glass at lists.gemtalksystems.com <mailto:glass at lists.gemtalksystems.com>> 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 <jupiter.jones at mail.com <mailto:jupiter.jones at mail.com>>:
>>> 
>>> 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 <glass at lists.gemtalksystems.com <mailto:glass at lists.gemtalksystems.com>> 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 <glass at lists.gemtalksystems.com <mailto:glass at lists.gemtalksystems.com>>:
>>>>> 
>>>>> 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 <http://www.brotrezept.ch/>!
>>>>> 
>>>>> Andreas Brodbeck
>>>>> Software-Macher
>>>>> mindclue GmbH
>>>>> Dipl. El.-Ing. ETH
>>>>> 
>>>>> +41 55 622 26 24
>>>>> www.mindclue.ch <http://www.mindclue.ch/>
>>>>> -----------------------------------------
>> 
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com <mailto:Glass at lists.gemtalksystems.com>
>> https://lists.gemtalksystems.com/mailman/listinfo/glass
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gemtalksystems.com/mailman/private/glass/attachments/20200521/b21792e5/attachment.htm>