[Glass] Workaround to browser maximum connection limit ?

Tue Mar 21 05:52:02 PDT 2017

On Tue, Mar 21, 2017 at 7:52 AM, Otto Behrens <otto at finworks.biz> wrote:

> Hi,
>
> We use a background process to generate big reports. This is a topaz
> session that logs in on its own (nothing to do with seaside as such)
> and picks up the report to generate. It commits the report results in
> GemStone and the UI aborts to pick up the progress and results.
>

Yes, I thought about this too (as I have an extended version of your
BackgroundProcess working nicely) but reports are Seaside and quite a bit
of the effort happens on rendering rather than the "callback".

>
> There is not much sophistication here on the UI because we do not
> display results until the report is done (only progress, which shows a
> simple line of relative progress). We could display results I suppose,
> but then you can sort them yet, and things like that.
>
> Maybe you can spawn multiple background process jobs that each take a
> bit of the work and commit the results as they do it. I suppose you've
> already looked at the concurrency issues to do something like that?
>

Yes! And it's still a possibility but of course, not trivial.

>
> If the rendering is heavy weight, you could perhaps generate some of
> your html in the results of the report in stead of some report result
> object.
>
>
Yeah, this is the thing the rendering is heavy weight.
mmmm I didn't understand your point here. Could you explain better?

> Cheers
> Otto
>
> On Tue, Mar 21, 2017 at 12:41 PM, Mariano Martinez Peck via Glass
> <glass at lists.gemtalksystems.com> wrote:
> >
> >
> > On Tue, Mar 21, 2017 at 3:20 AM, Johan Brichau via Glass
> > <glass at lists.gemtalksystems.com> wrote:
> >>
> >> Hey Mariano,
> >>
> >> On 21 Mar 2017, at 01:01, Mariano Martinez Peck via Glass
> >> <glass at lists.gemtalksystems.com> wrote:
> >>
> >> The second thing is that making this on AJAX calls, that would end up on
> >> different Gems on my GemStone which was very performant. I have 10
> Seaside
> >> gems on a 8 cores CPU so all those AJAX request were load balanced via
> nginx
> >> over the 10 seaside gems, which on the other hand were split across all
> >> cores. Previously, with a single request, only one Gem took care and
> hence
> >> only one CPU core was used.
> >>
> >>
> >> Quick question: does this mean these requests are "Seaside
> session-less”?
> >
> >
> > Uhhhh ... great question. I think they are indeed "quite session-less"
> ...
> > but.. is there an easy way to check this? Of course, something easier
> than
> > following code to see if I access session. Maybe simply putting some
> logging
> > in session accessing code ?
> >
> >
> >>
> >> Because processing seaside requests in parallel is not possible (the
> >> session object is locked).
> >
> >
> >
> > Yes, maybe this is the case for my scenario. But at least, the report can
> > still be rendered ASAP rather than having to wait until fully done, even
> if
> > all requests would not go parelel even if they are on multiple gems.
> > But...honestly, I would love they go paralel....  do you have some
> reference
> > or link explaining the locking? I remember some old Dale posts as well as
> > some code but any hint would be appreciated.
> > Have someone improved or make any progress on this locking / multi-gem
> > issue?
> >
> > Thanks in advance!
> >
> >>
> >>
> >> Johan
> >>
> >> _______________________________________________
> >> Glass mailing list
> >> Glass at lists.gemtalksystems.com
> >> http://lists.gemtalksystems.com/mailman/listinfo/glass
> >>
> >
> >
> >
> > --
> > Mariano
> > http://marianopeck.wordpress.com
> >
> > _______________________________________________
> > Glass mailing list
> > Glass at lists.gemtalksystems.com
> > http://lists.gemtalksystems.com/mailman/listinfo/glass
> >
>

-- 
Mariano
http://marianopeck.wordpress.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170321/bda27a10/attachment.html>