[Seaside] Re: Concurrent requests from multiple sessions

[Bob Arning]

One question that occurs to me is whether different Smalltalks exhibit 
different behaviors in switching from one process to another at the same 
priority. I recall thinking this was a bit odd when I first became aware 
of it and I seem to remember a discussion once about changing Squeak's 
behavior in this case. I don't know if other Smalltalks did change or 
were even different from the very beginning. If you run the following, 
do the three processes proceed at roughly the same pace or does 1 finish 
before 2 starts?

     | nums procs |

     nums := OrderedCollection new.
     procs := (1 to: 3) collect: [ : i |
         nums add: 0.
         [
             10 timesRepeat: [
                 [10000 factorial] timeToRun.
                 nums at: i put: (nums at: i) + 1.
             ].
         ].
     ].
     procs do: [ : e | e forkAt: Processor userBackgroundPriority].
     nums inspect


On 3/10/15 7:51 AM, Sven Van Caekenberghe wrote:
> Well, we can't help him unless he give us a reproducible case.
>
> My code shows there is no such problem.
>
> There might be some miscommunication going on, but from my cursory reading, I got the impression that he suggests there is a fundamental problem with something except his own code.
>
>> On 10 Mar 2015, at 12:31, Nowak, Helge <HNowak at cincom.com> wrote:
>>
>> Hmm,
>>
>> I am sure Ondrej understood what was proposed. He mentioned at least twice that the DB connections are NOT the problem. He said that the processing AFTER loading the data from the database into the image is the problem. Why shouldn't I believe him? OTOH I believe you Seaside experts that Seaside's architecture is inherently non-blocking between sessions.
>>
>> Thus there are two questions:
>> - how could any processing block the whole Seaside image?
>> - how to find possibly problematic spots in Ondrej's application code?
>>
>> Once that is resolved one could think about further improvements.
>>
>> Cheers
>> Helge
>>
>> -----Ursprüngliche Nachricht-----
>> Von: seaside-bounces at lists.squeakfoundation.org [mailto:seaside-bounces at lists.squeakfoundation.org] Im Auftrag von Sven Van Caekenberghe
>> Gesendet: Dienstag, 10. März 2015 12:12
>> An: Seaside - general discussion
>> Betreff: Re: [Seaside] Re: Concurrent requests from multiple sessions
>>
>>
>>> On 10 Mar 2015, at 11:15, wilwarin <Ondrej.Altman at seznam.cz> wrote:
>>>
>>> ( I tried Sven's code and it is possible to do another work during
>>> waiting, it is OK. )
>> Does it also work (slowly) during the benchmark ?
>> That simulates your 'long running work'.
>>
>>>> But that problem (not being able to process concurrent requests) is
>>>> certainly not inherent to Seaside or Pharo. If that were the case we
>>>> should all stop using it.
>>> Hopefully I understand, so it is not the case. If I am correct, it
>>> means that in Seaside it is necessary to solve similar situations with
>>> different access. In case of for example difficult server-side
>>> calculation (or processing of big amount of data), we have to count on
>>> a possible problem with concurrent requests from multiple sessions. Am
>>> I right? Or, if not, where could the problem lay?
>> What everybody here tries to explain to you is that the problem is most probably in your DB driver (in Smalltalk or further down): it probably cannot do more than one concurrent request (as it is currently implemented). That is not a Seaside nor a fundamental Smalltalk problem.
>>
>> Try investigating that aspect, separate from Seaside._______________________________________________
>> seaside mailing list
>> seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>> _______________________________________________
>> seaside mailing list
>> seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20150310/beaa0566/attachment-0001.htm