[Glass] WAGsZincStreamingServerAdaptor starts a new session on every request

[Dale Henrichs]

Okay it looks like https://github.com/SeasideSt/Seaside/issues/1317 is at
least a reproduction of the "problem" ...

Do you have access to slack[1]? If so, we should arrange a chat and screen
share session tomorrow some time ...

Dale

[1] https://slack.com/

On Tue, Jun 21, 2022 at 4:47 PM Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

> Hey Paul,
>
> I'm just back in town after a customer visit last week and my work laptop
> is on the blink ... so I've just started taking a look at this issue  ...
>
> I haven't run through the installation steps yet, but I have noticed that
> there are no "standard seaside tests" for ZnZincStreamingServerAdaptor
> or WAGsZincStreamingServerAdaptor (?) so it may not be surprising that
> things aren't working correctly ... do you happen to know if there are some
> tests in Pharo for the streaming adaptors?
>
> Looking at git history it looks like Max Leske added
> the WAGsZincStreamingServerAdaptor back in 2018 ...
>
> It seems I have never worked with that code, so it will take a bit of time
> for me to get familiar with how things are hooked up internally and figure
> out how transactions should be handled, since that seems to be the crux of
> the issues ..
>
>
> Sooo, a test or two would certainly speed things up for me ...
>
> Dale
>
> On Mon, Jun 20, 2022 at 9:55 PM PAUL DEBRUICKER via Glass <
> glass at lists.gemtalksystems.com> wrote:
>
>> Hi Dale,
>>
>> In order to be more compliant with HTTP/2 and HTTP/3 I'm messing around
>> with streaming HTTP/1.1 responses from Seaside.  There are some classes
>> there to do it and it works in Pharo but not GemStone because a new session
>> is made with each request.
>>
>> I made an issue (https://github.com/SeasideSt/Seaside/issues/1317) and
>> am trying to understand whats happening.
>>
>> It looks like the code is identical between the streaming and
>> non-streaming (WAGsZincServerAdaptor) adaptors.  The non-streaming adaptor
>> works great/normally.  The streaming adaptor definitely streams the
>> responses
>>
>> But for the streaming adaptor, the response "exits" the transaction
>> mutex's #critical: block in
>> GRGemStonePlatform>>#seasideProcessRequestWithRetry:resultBlock: before
>> actually processing the request so the majority of the work is done outside
>> a transaction.
>>
>> The streaming adaptor uses a ZnDeferredResponse to hold a block processes
>> the request when the reponse begins being written by the WAComboResponse.
>> I think thats when the request is processed at least.
>>
>> Anyway,  any ideas how to get the request processed inside a transaction
>> using the zinc streaming adaptor?
>>
>>
>> Thanks
>>
>> Paul
>> _______________________________________________
>> Glass mailing list
>> Glass at lists.gemtalksystems.com
>> https://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/archives/glass/attachments/20220621/fdb3bd01/attachment.htm>