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

[Joachim Tuchel]

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.
>
>>
>>
>>
>> Am 28.05.13 05:32, schrieb Bahman Movaqar:
>>> On 2013-05-27 22:29, intrader wrote:
>>>> As you now know, it is very simple to inadvertently cause your code to
>>>> freeze. I have managed to get my code to freeze in various ways 
>>>> including
>>>> recursion caused by initialize.AND, test before you deploy in a 
>>>> production
>>>> environment.
>>>>
>>>> The VM is correctly doing what you tell it to do.
>>> That's right.
>>>
>>> My only question is that, should a single bad process freeze the whole
>>> image?
>>>
>>> A process can go CPU-wild not only during initialisation but also by 
>>> I/O
>>> block/deadlock, e.g. when accessing the database.  I know, it is not
>>> usual or something that happens on a daily basis.
>>>
>>> I've had this on JVM: running multiple applications on a web server.
>>> Out there if the freeze happened at web server level, well, all
>>> applications were down and out of reach.  However if the freeze 
>>> happened
>>> in application (my code) level, the CPU usage would increase -sometimes
>>> to 100%- but the other web applications would remain accessible 
>>> though slow.
>>>
>>> I'm wondering about a way to achieve the same behaviour on Smalltalk.
>>>
>>
>
> Thank you,
> -- 
> Bahman Movaqar  (http://BahmanM.com)
> ERP Evaluation, Implementation, Deployment Consultant

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