[Glass] Workaround to browser maximum connection limit ?

Tue Mar 21 11:42:16 PDT 2017

Also sent this one to Mariano directly instead of the list…

----

Hey Mariano,

The session-lock is only applicable if you call a service that is part of a Seaside session. Callbacks generated by Seaside are such an example.
If you would call a service that is not behind a Seaside session, it is not applicable.

It’s in WASession>>handle

So, Seaside-REST or Zinc-REST would not be affected.

So, this all depends if the data you need to retrieve is tied to a session or not...
If it is, you still might be able to register the data in the database and allow it to be retrieved session-less via the REST service. All you need is a way to uniquely and safely access it via the REST service.

This is, more-or-less what we do in a similar case where we pass generated reports to a Javascript app: a service vm produces the report data and it is being made available in a REST service where the Javascript app can pick it up.
All you need to do is some regular cleanup of the data, much like seaside session expiration.

…. that should allow you to burn that server’s cores :)

Hope this helps
Johan

> On 21 Mar 2017, at 16:52, Mariano Martinez Peck <marianopeck at gmail.com <mailto:marianopeck at gmail.com>> wrote:
> 
> 
> 
> On Tue, Mar 21, 2017 at 11:04 AM, Johan Brichau <johan at yesplan.be <mailto:johan at yesplan.be>> wrote:
> Mariano,
> 
> If your requests have a Seaside session key in it, and they are normal Seaside (ajax) callbacks, then I’m pretty sure that the Session lock will be applied in Gemstone.
> 
> 
> Yeah, indeed, it's exactly as you describe :(
>  
> The ‘session lock’ is not an actual lock: the request will abort and will be retried after some waiting time if another gem is processing a request for that same Seaside session.
> 
> yes.. I found the method I was remembering (#seasideProcessRequestWithRetry: )
>  
> 
> However… that means your requests cannot be processed in parallel… even worse is that because of the waiting time, the net processing time will be longer that if they were queued to the same gem.
> To avoid this, we use session affinity [1]
> 
> Exactly. I understand that. 
>  
> 
> So… I’m wondering if the limit of parallel requests in the browser is really an issue if you cannot circumvent this session lock?
> 
> 
> Well, I was thinking that maybe the SSL shake, the POST, then nginx forwarding to FastCGi etc (I mean...all the work from one point up to the gem) may be solved if the ajax would happen immediatly even if stucked on the gem. But you are clearly right now this is not nearly as good as I thought it was :(
>  
> But you seem to describe you do so requests being processed in parallel (up to 6?)… so I’m still wondering what you are doing ;-)
> 
> 
> Yeah, that SEEMED to while watching `htop` and see how cores were used. But I bet this was  UI thingy as probably the "usage" of each core was sequential in which each step was the gem that got the lock.
> 
> 
> Honestly I am a bit sad that we cannot have multiple gems doing real parallel work. I guess my client is willing to pay for it. I understand that somehow the session must be synchronized across multiple possible gems, but can't we improve current implementation? I mean, a better approach that  lock + abort and retry....   Have you ever tried this? Did you have an idea even if you did not implement it? Does GemTalks ever provided a possible workaround? 
> 
> 
>  
> Johan
> 
> [1] http://jbrichau.github.io/blog/when-to-use-http-session-affinity-in-glass <http://jbrichau.github.io/blog/when-to-use-http-session-affinity-in-glass>
> 
>> On 21 Mar 2017, at 11:41, Mariano Martinez Peck <marianopeck at gmail.com <mailto:marianopeck at gmail.com>> wrote:
>> 
>> 
>> 
>> On Tue, Mar 21, 2017 at 3:20 AM, Johan Brichau via Glass <glass at lists.gemtalksystems.com <mailto: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 <mailto: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 <mailto:Glass at lists.gemtalksystems.com>
>> http://lists.gemtalksystems.com/mailman/listinfo/glass <http://lists.gemtalksystems.com/mailman/listinfo/glass>
>> 
>> 
>> 
>> 
>> -- 
>> Mariano
>> http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>
> 
> 
> 
> 
> -- 
> Mariano
> http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170321/a8b13c94/attachment-0001.html>