[Seaside] Re: VM freezes; how to find the cause?

[Bahman Movaqar]

On 2013-05-28 09:51, Joachim Tuchel wrote:
> Hi again,
>
> Am 28.05.13 06:51, schrieb Bahman Movaqar:
>
> I'm going to answer based on my (basic) knowledge of VA Smalltalk's
> implementation in its Server Smalltalk feature, which I guess is quite
> similar to what Zn in Pharo offers.
>> What you're basically saying is that
>>   1.  Web application is a thread: if it blocks it only blocks its
>> own thread meaning other web applications will still be accessible. 
>
> Well, in fact each http request gets answered in its own thread, so in
> the best of cases, only one single http request is blocked. You can
> still work on other requests and talk to the same application in other
> sessions. Imagine a ServerAdaptor in your smalltalk image kicking of
> an ST thread for each incoming request.
>>   2.  Web server is a thread: if it blocks all web applications will
>> be blocked but the VM is still accessible.
> Well, yes. The web server (which is really just a small listener on a
> socket) is a Thread in your Smalltalk Image. If it blocks, the VM
> cannot answer any http requests any more. In a development image, you
> can still work with Smalltalk Browsers and dev tools, because they run
> in another thread.
>
>> If that's true, well, it adds to my confusion :-)  The -possible- bad
>> initialisation occurred in a web application and in worst case at the
>> web server level.  Then why did the VM became non-operational? 
>> According to what you say, only the web application or in worst case
>> "Zn" must have become frozen.
> In theory, that is what happened. Just like in any other
> multithreading environment, there are lots of things that can happen
> when you make little mistakes. If you start a process with such a high
> priority that it won't let ohers execute any more.
> Then, there are exceptions to the things mentioned. External calls,
> for example, can block the whole VM (depending on how you call out of
> the image), even if they are issued in a low priority background
> process.  You can produce deadlocks with Semaphores and stuff. Lots of
> things can go wrong in multithreaded environments.
>
> Joachim
>>
>> I'm just trying to understand the process model Seaside is based on.

@Joachim:  Thanks for the thorough explanation.  I'm still a tad bit
confused but I guess pushing this any further without me having a
containedly flawed code doesn't help :-)

Thank you all for your time.

-- 
Bahman Movaqar  (http://BahmanM.com)
ERP Evaluation, Implementation, Deployment Consultant