[Pharo-project] [ANN] 5965 Can't allocate semaphores? VirtualMachine>>maxExternalSemaphores: aSize | Not enough space for external objects, set a larger size at startup!
Hey guys, this is kind of a show stopper for images in production :/ http://code.google.com/p/pharo/issues/detail?id=5965 sebastian o/
On 23 May 2012 18:57, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
Hey guys,
this is kind of a show stopper for images in production :/ http://code.google.com/p/pharo/issues/detail?id=5965
i thought we already dealt with it. no?
sebastian
o/
-- Best regards, Igor Stasenko.
On May 23, 2012, at 7:41 PM, Igor Stasenko wrote:
On 23 May 2012 18:57, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
Hey guys,
this is kind of a show stopper for images in production :/ http://code.google.com/p/pharo/issues/detail?id=5965
i thought we already dealt with it. no?
No, the image as it is now just quits. Delayed our deployment of the ESUG registration server for some weeks... normal seaside use, image quites after a day. It's far from obvious. I think the image should work out of the box. Why destinguish between deployment and development? What is good in deployment is for sure gut in development. Marcus -- Marcus Denker -- http://marcusdenker.de
On May 23, 2012, at 7:49 PM, Marcus Denker wrote:
On May 23, 2012, at 7:41 PM, Igor Stasenko wrote:
On 23 May 2012 18:57, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
Hey guys,
this is kind of a show stopper for images in production :/ http://code.google.com/p/pharo/issues/detail?id=5965
i thought we already dealt with it. no?
No, the image as it is now just quits. Delayed our deployment of the ESUG registration server for some weeks...
^^^^^^^ days of course. "It's down" "strange, I restarted". "Again" "Wow. But wait, there is an error message". This has to be done better. There should not be a destinction of "deployment" and "development" on that level. Marcus -- Marcus Denker -- http://marcusdenker.de
On 23 May 2012 19:55, Marcus Denker <marcus.denker@inria.fr> wrote:
On May 23, 2012, at 7:49 PM, Marcus Denker wrote:
On May 23, 2012, at 7:41 PM, Igor Stasenko wrote:
On 23 May 2012 18:57, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
Hey guys,
this is kind of a show stopper for images in production :/ http://code.google.com/p/pharo/issues/detail?id=5965
i thought we already dealt with it. no?
No, the image as it is now just quits. Delayed our deployment of the ESUG registration server for some weeks...
         ^^^^^^^           days of course. "It's down" "strange,  I restarted". "Again" "Wow. But wait, there is an                          error message".
This has to be done better. There should not be a destinction of "deployment" and "development" on that level.
Definitely.
    Marcus
-- Marcus Denker -- http://marcusdenker.de
-- Best regards, Igor Stasenko.
On Wed, May 23, 2012 at 10:48 AM, Marcus Denker <marcus.denker@inria.fr>wrote:
On May 23, 2012, at 7:41 PM, Igor Stasenko wrote:
On 23 May 2012 18:57, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
Hey guys,
this is kind of a show stopper for images in production :/ http://code.google.com/p/pharo/issues/detail?id=5965
i thought we already dealt with it. no?
No, the image as it is now just quits. Delayed our deployment of the ESUG registration server for some weeks... normal seaside use, image quites after a day.
But then there must be a leak. Some sockets are not getting closed or their associated semaphores are not getting released.
It's far from obvious.
I think the image should work out of the box. Why destinguish between deployment and development? What is good in deployment is for sure gut in development.
Marcus
-- Marcus Denker -- http://marcusdenker.de
-- best, Eliot
On 23 May 2012 19:48, Marcus Denker <marcus.denker@inria.fr> wrote:
On May 23, 2012, at 7:41 PM, Igor Stasenko wrote:
On 23 May 2012 18:57, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
Hey guys,
this is kind of a show stopper for images in production :/ http://code.google.com/p/pharo/issues/detail?id=5965
i thought we already dealt with it. no?
No, the image as it is now just quits. Delayed our deployment of the ESUG registration server for some weeks... normal seaside use, image quites after a day.
It's far from obvious.
I think the image should work out of the box. Why destinguish between deployment and development? What is good in deployment is for sure gut in development.
perhaps we should write a watchdog of external semaphore table. to see if semaphore orphaned and detect by whom.
    Marcus
-- Marcus Denker -- http://marcusdenker.de
-- Best regards, Igor Stasenko.
On 23 May 2012, at 19:48, Marcus Denker wrote:
No, the image as it is now just quits. Delayed our deployment of the ESUG registration server for some weeks... normal seaside use, image quites after a day.
It's far from obvious.
I think the image should work out of the box. Why destinguish between deployment and development? What is good in deployment is for sure gut in development.
It might be a bit surprising, but I think Hendrik's reasoning is quite good: you don't want to keep on expanding when there are problems not freeing resources that are limited. A good server needs resource limits. We can discuss more tomorrow⦠Sven
On 23 May 2012 20:18, Sven Van Caekenberghe <sven@beta9.be> wrote:
On 23 May 2012, at 19:48, Marcus Denker wrote:
No, the image as it is now just quits. Delayed our deployment of the ESUG registration server for some weeks... normal seaside use, image quites after a day.
It's far from obvious.
I think the image should work out of the box. Why destinguish between deployment and development? What is good in deployment is for sure gut in development.
It might be a bit surprising, but I think Hendrik's reasoning is quite good: you don't want to keep on expanding when there are problems not freeing resources that are limited. A good server needs resource limits.
Definitely.
We can discuss more tomorrowâ¦
Absolutely (i'm in a good humor today ;)
Sven
-- Best regards, Igor Stasenko.
On 23.05.2012 20:18, Sven Van Caekenberghe wrote:
On 23 May 2012, at 19:48, Marcus Denker wrote:
No, the image as it is now just quits. Delayed our deployment of the ESUG registration server for some weeks... normal seaside use, image quites after a day.
It's far from obvious.
I think the image should work out of the box. Why destinguish between deployment and development? What is good in deployment is for sure gut in development. It's the other way around in this case, what's good in development is not always so good in deployment. In development, you want to be notified of issues as soon as possible. If they still slip through to deployment, you want them dealt with as gracefully as possible.
It might be a bit surprising, but I think Hendrik's reasoning is quite good: you don't want to keep on expanding when there are problems not freeing resources that are limited. A good server needs resource limits.
We can discuss more tomorrowâ¦
Sven
Well, both that, and the fact it can't be done safely. The process of increasing its size might lead to lost signals. 99% of the time, setting the size at startup to a larger value than the default (before anything but the input semaphore is registered) is a better approach than increasing automatically, and in the remaining 1% it is better to fix whatever application issue is causing semaphore leaks anyways. Cheers, Henry
I agree with Henrik (both clarifications) For the record, the error happens with a surprising value in aSize. It happens when aSize is as low as 260 o.O sebastian o/ On May 24, 2012, at 5:33 AM, Henrik Sperre Johansen wrote:
On 23.05.2012 20:18, Sven Van Caekenberghe wrote:
On 23 May 2012, at 19:48, Marcus Denker wrote:
No, the image as it is now just quits. Delayed our deployment of the ESUG registration server for some weeks... normal seaside use, image quites after a day.
It's far from obvious.
I think the image should work out of the box. Why destinguish between deployment and development? What is good in deployment is for sure gut in development. It's the other way around in this case, what's good in development is not always so good in deployment. In development, you want to be notified of issues as soon as possible. If they still slip through to deployment, you want them dealt with as gracefully as possible.
It might be a bit surprising, but I think Hendrik's reasoning is quite good: you don't want to keep on expanding when there are problems not freeing resources that are limited. A good server needs resource limits.
We can discuss more tomorrowâ¦
Sven
Well, both that, and the fact it can't be done safely. The process of increasing its size might lead to lost signals.
99% of the time, setting the size at startup to a larger value than the default (before anything but the input semaphore is registered) is a better approach than increasing automatically, and in the remaining 1% it is better to fix whatever application issue is causing semaphore leaks anyways.
Cheers, Henry
participants (6)
-
Eliot Miranda -
Henrik Sperre Johansen -
Igor Stasenko -
Marcus Denker -
Sebastian Sastre -
Sven Van Caekenberghe