[Glass] WAGsZincStreamingServerAdaptor starts a new session on every request

[PAUL DEBRUICKER]

Some more info:

Changing ZnGemServerManagingMultiThreadedServer>>#writeResponse:on: to

 GRPlatform current
    doTransaction: [ response writeOn: streamTransientStackValue value ].
  streamTransientStackValue value flush.
  self logResponse: response



gets streamed responses working, and the counter app works.  

But the "meat" of the request processing happens outside the request/retry logic.  

Seems like having a way to stream the response and retry between sends to WAComboResponse>>#flush would fix that.  

So that after a portion of the document has been sent to the browser that same portion isn't resent while the retry is happening.  

The WAComboResponse buffers the response then sends the buffer when #flush is sent.  

So the retry could reset the buffer and attempt to process the request from the point of the last successful flush.  

Any ideas on how to build that? 




> On Jun 20, 2022, at 9:39 PM, PAUL DEBRUICKER <pdebruic at gmail.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