WAStreamedResponse

I'm working on transitioning a project from VisualWorks to GLASS. We've hacked the current VW implementation (still on Seaside 2.8) to write a response directly to the socket stream, thus preventing us from buffering a large response in RAM before sending it to the user.

On 08/01/2012 10:09 AM, Ken Treis wrote:
>
> I see that Seaside 3.0 has this sort of infrastructure in
> WAStreamedResponse, but it doesn't appear to be supported by the FastCGI
> server yet. Do any of the other servers support it?


I think this is relevant to your interests:

http://forum.world.st/support-for-streamed-files-with-Zinc-adaptor-td4635474.html#a4635481


The Zinc-Seaside adaptor for Gemstone has (as far as I know) only been
tested in Gemstone2.4.  I made it and I can't think of a reason it won't
also work in Gemstone3.1 once Zinc does (which I think Dale is working
on: https://github.com/dalehenrich/zinc).



I did not test a WAStreamedResponse when I did test the Zinc adaptor in
Gemstone2.4.


Hope this helps.

Paul

On Wed, Aug 1, 2012 at 7:09 PM, Ken Treis <[hidden email]> wrote:
Right now I'm only aware of Kom. However in Seaside 3.0 the
implementation has the following limitations that have been fixed in
Seaside 3.1:
 - streaming is either all or nothing, you can't stream just one
response, you have to stream every response or none
 - due to missing chunking we can't use keep-alive and have to close
the connection after every request, this introduces latency and
increases page loading time

We haven't released Seaside 3.1 officially yet because we're still
working on configurations but the functionality is implemented. I hope
I'll have time to work on the configurations at ESUG.

Be aware of the downsides of streaming:
 - once part of the response has been written you have to follow it
through the end, if an exception happens you can't render an error
page anymore
 - once part of the response has been written you can't add any
headers anymore (in theory you can use footer when doing chunking)

Also note that a server doesn't necessarily have to use
WAStreamedResponse, it's just there for convenience.

Cheers
Philippe

Ken,

I would agree (without looking closely) that FastCGI is probably not a good route to go for streaming.

As Paul has mentioned the best bet is to go with Zinc (and Zodiac on 3.1 for ssh). I am in the process of porting the latest Zinc[1] code base to GemStone2.4 and will follow with a port to GemStone3.1 ... the work is based on Paul's earlier work on Zinc port.

The work in being done using git/github so if you have the time to participate in the port let me know...

With your interest in the streaming api, I will make sure to port that piece:)

I really haven't looked at the streaming stuff, but it definitely sounds like Seaside3.1 would be the way go. I agree with Philippe that we should use the time at the Seaside sprint to get port Seaside3.1 .... with regards to the streaming connections I assume that we can work something out that avoids taking hits for long transactions...

Dale

[1] https://github.com/glassdb/zinc

----- Original Message -----
| From: "Ken Treis" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Wednesday, August 1, 2012 10:09:36 AM
| Subject: [GS/SS Beta] WAStreamedResponse
|
| I'm working on transitioning a project from VisualWorks to GLASS.
| We've hacked the current VW implementation (still on Seaside 2.8) to
| write a response directly to the socket stream, thus preventing us
| from buffering a large response in RAM before sending it to the
| user.
|
|
| We don't use this for everything, just for big stuff like CSV export
| or 500-page dynamically-generated PDFs.
|
|
| I see that Seaside 3.0 has this sort of infrastructure in
| WAStreamedResponse, but it doesn't appear to be supported by the
| FastCGI server yet. Do any of the other servers support it?
|
|
| I imagine that there are some challenges to doing this in GLASS,
| given the way transaction retry is implemented. It'd be no good to
| send a normal WAResponse to the user, only to find that you had
| transaction conflicts and you need to abort/retry. But in our usage
| here, I would be willing to live with transaction conflicts. As long
| as the CSV/PDF gets to the user, there's nothing I need committed:
| an abort would be fine.
|
|
|
| --
| Ken Treis
| [hidden email]
|