[Glass] Workaround to browser maximum connection limit ?

Tue Mar 21 11:41:29 PDT 2017

Seems I answered to Mariano directly…
Sending this to list for reference..

-----

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.
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.

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]

So… I’m wondering if the limit of parallel requests in the browser is really an issue if you cannot circumvent this session lock?

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 ;-)

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/>

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