[Glass] Workaround to browser maximum connection limit ?

[Otto Behrens via Glass]

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.

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?

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.

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
>