[Glass] WAGsZincStreamingServerAdaptor starts a new session on every request

Dale Henrichs dale.henrichs at gemtalksystems.com
Tue Jun 21 16:47:50 PDT 2022


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/a7bceb3d/attachment.htm>


More information about the Glass mailing list