Smalltalk › Pharo › Pharo Smalltalk Developers

Socket timeout terminates COG VM

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

24 messages Options

John Toohey

Socket timeout terminates COG VM

Hi,

I've had a problem since 1.0 with socket timeouts throwing exceptions
and invoking the debugger in my headless images. I don't know why a
socket timeout is considered exceptional, but I've gotten used to
using VNC to log into the server and close the debuger windows.
However, I've moved to COG and the latest one-click images, and now
the error terminates the VM.

My app is a standard Seaside server, using the streaming connector for
Comet support.

I've attached the PharoDebug.log. It would be appreciated if anyone
could help me with this problem, as I'm at a loss where to even begin.

Using Pharo1.3 #13298 on Lucid32 (Ubuntu)

--
~JT

PharoDebug.log (90K) Download Attachment

Igor Stasenko

Re: Socket timeout terminates COG VM

On 10 October 2011 23:19, John Toohey <[hidden email]> wrote:

> Hi,
>
> I've had a problem since 1.0 with socket timeouts throwing exceptions
> and invoking the debugger in my headless images. I don't know why a
> socket timeout is considered exceptional, but I've gotten used to
> using VNC to log into the server and close the debuger windows.
> However, I've moved to COG and the latest one-click images, and now
> the error terminates the VM.
>
> My app is a standard Seaside server, using the streaming connector for
> Comet support.
>
> I've attached the PharoDebug.log. It would be appreciated if anyone
> could help me with this problem, as I'm at a loss where to even begin.
>

So, just put an exception handler, and handle this exception in a
manner you want
and then your image will keep working! :)

>
> Using Pharo1.3 #13298 on Lucid32 (Ubuntu)
>
>
> --
> ~JT
>

--
Best regards,
Igor Stasenko.

Schwab,Wilhelm K

Re: Socket timeout terminates COG VM

In reply to this post by John Toohey

John,

Let me see if I can turn you to the dark side :) Sockets should **never** timeout. Socket servers (distinct from server sockets) should listen for and accept connections until told to stop. Client sockets should assume the server will respond a"any minute now" until they are told to give up. Sockets should use events vs. polling (one exception is arguably if a socket function call is running on a separate OS thread). All socket calls should block the calling Process while other Process instances run and the image remains responsive - no one would ever run a socket call on the gui thread, right?

Harsh, I know, but it makes sense once you try it. Part of why I mention OS threads and blocking calls is that I would very much like to see us have in-image support for SSL, and OpenSSL is a nice way to do that. The OpenSSL non-blocking API is kinda scary, so blocking calls make a lot of sense.

Bill

________________________________________
From: [hidden email] [[hidden email]] On Behalf Of John Toohey [[hidden email]]
Sent: Monday, October 10, 2011 4:19 PM
To: [hidden email]
Subject: [Pharo-project] Socket timeout terminates COG VM

Hi,

I've had a problem since 1.0 with socket timeouts throwing exceptions
and invoking the debugger in my headless images. I don't know why a
socket timeout is considered exceptional, but I've gotten used to
using VNC to log into the server and close the debuger windows.
However, I've moved to COG and the latest one-click images, and now
the error terminates the VM.

My app is a standard Seaside server, using the streaming connector for
Comet support.

I've attached the PharoDebug.log. It would be appreciated if anyone
could help me with this problem, as I'm at a loss where to even begin.

Using Pharo1.3 #13298 on Lucid32 (Ubuntu)

--
~JT

John Toohey

Re: Socket timeout terminates COG VM

In reply to this post by Igor Stasenko

The exception is not coming from my code, if it was I could trap it.
Regardless, isn't shutting the VM down a bit of overkill in this case?

On Mon, Oct 10, 2011 at 17:12, Igor Stasenko <[hidden email]> wrote:

> On 10 October 2011 23:19, John Toohey <[hidden email]> wrote:
>> Hi,
>>
>> I've had a problem since 1.0 with socket timeouts throwing exceptions
>> and invoking the debugger in my headless images. I don't know why a
>> socket timeout is considered exceptional, but I've gotten used to
>> using VNC to log into the server and close the debuger windows.
>> However, I've moved to COG and the latest one-click images, and now
>> the error terminates the VM.
>>
>> My app is a standard Seaside server, using the streaming connector for
>> Comet support.
>>
>> I've attached the PharoDebug.log. It would be appreciated if anyone
>> could help me with this problem, as I'm at a loss where to even begin.
>>
>
> So, just put an exception handler, and handle this exception in a
> manner you want
> and then your image will keep working! :)
>
>>
>> Using Pharo1.3 #13298 on Lucid32 (Ubuntu)
>>
>>
>> --
>> ~JT
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
>
>

--
~JT

John Toohey

Re: Socket timeout terminates COG VM

In reply to this post by Schwab,Wilhelm K

I agree. In my own networking code, my sockets handlers on both side
never timeout. I have a manager/monitor process that I use if I have
to kill them.

On Mon, Oct 10, 2011 at 17:18, Schwab,Wilhelm K <[hidden email]> wrote:

> John,
>
> Let me see if I can turn you to the dark side :) Sockets should **never** timeout. Socket servers (distinct from server sockets) should listen for and accept connections until told to stop. Client sockets should assume the server will respond a"any minute now" until they are told to give up. Sockets should use events vs. polling (one exception is arguably if a socket function call is running on a separate OS thread). All socket calls should block the calling Process while other Process instances run and the image remains responsive - no one would ever run a socket call on the gui thread, right?
>
> Harsh, I know, but it makes sense once you try it. Part of why I mention OS threads and blocking calls is that I would very much like to see us have in-image support for SSL, and OpenSSL is a nice way to do that. The OpenSSL non-blocking API is kinda scary, so blocking calls make a lot of sense.
>
> Bill
>
>
>
> ________________________________________
> From: [hidden email] [[hidden email]] On Behalf Of John Toohey [[hidden email]]
> Sent: Monday, October 10, 2011 4:19 PM
> To: [hidden email]
> Subject: [Pharo-project] Socket timeout terminates COG VM
>
> Hi,
>
> I've had a problem since 1.0 with socket timeouts throwing exceptions
> and invoking the debugger in my headless images. I don't know why a
> socket timeout is considered exceptional, but I've gotten used to
> using VNC to log into the server and close the debuger windows.
> However, I've moved to COG and the latest one-click images, and now
> the error terminates the VM.
>
> My app is a standard Seaside server, using the streaming connector for
> Comet support.
>
> I've attached the PharoDebug.log. It would be appreciated if anyone
> could help me with this problem, as I'm at a loss where to even begin.
>
>
> Using Pharo1.3 #13298 on Lucid32 (Ubuntu)
>
>
> --
> ~JT
>
>

--
~JT

Igor Stasenko

Re: Socket timeout terminates COG VM

In reply to this post by John Toohey

On 11 October 2011 00:24, John Toohey <[hidden email]> wrote:
> The exception is not coming from my code, if it was I could trap it.
> Regardless, isn't shutting the VM down a bit of overkill in this case?
>

No, it is not.
For handling an unhandled exception, without knowing its source and
cause which led to it,
i don't see any other alternative.
In headless mode there is no user who could respond to unhandled
exception popups,
therefore if your software doesn't handles it by itself, by default an
image just quits to OS.

> On Mon, Oct 10, 2011 at 17:12, Igor Stasenko <[hidden email]> wrote:
>> On 10 October 2011 23:19, John Toohey <[hidden email]> wrote:
>>> Hi,
>>>
>>> I've had a problem since 1.0 with socket timeouts throwing exceptions
>>> and invoking the debugger in my headless images. I don't know why a
>>> socket timeout is considered exceptional, but I've gotten used to
>>> using VNC to log into the server and close the debuger windows.
>>> However, I've moved to COG and the latest one-click images, and now
>>> the error terminates the VM.
>>>
>>> My app is a standard Seaside server, using the streaming connector for
>>> Comet support.
>>>
>>> I've attached the PharoDebug.log. It would be appreciated if anyone
>>> could help me with this problem, as I'm at a loss where to even begin.
>>>
>>
>> So, just put an exception handler, and handle this exception in a
>> manner you want
>> and then your image will keep working! :)
>>
>>>
>>> Using Pharo1.3 #13298 on Lucid32 (Ubuntu)
>>>
>>>
>>> --
>>> ~JT
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>>
>
>
>
> --
> ~JT
>
>

--
Best regards,
Igor Stasenko.

Henrik Sperre Johansen

Re: Socket timeout terminates COG VM

In reply to this post by John Toohey

On 10.10.2011 23:28, John Toohey wrote:
> I agree. In my own networking code, my sockets handlers on both side
> never timeout. I have a manager/monitor process that I use if I have
> to kill them.
Then raise Smalltalk vm maxExternalSemaphoresSilently: to an appropriate
number (max amount of socket handlers * 3 + some headroom), save your
image, and you should be set. While it has a max limit of 64k, the
socket plugin code on at least windows will max out at much less than
20k open sockets, as it uses 3 OS threads per socket. (Around 1k IIRC)
Semaphore timeouts were the old symptoms of running out of this space,
now it gives you an explicit exception instead.

maxExternalSemaphores: is what is raising the error, some info _should_
be written to wherever crLog: redirects to with a
NonInteractiveUIManager before the image terminates.

Cheers,
Henry

Schwab,Wilhelm K

Re: Socket timeout terminates COG VM

In reply to this post by John Toohey

John,

No question, the punishment certainly exceeds the crime :) I was making a general plea for what I really believe is the correct way to build network software.

Bill

________________________________________
From: [hidden email] [[hidden email]] On Behalf Of John Toohey [[hidden email]]
Sent: Monday, October 10, 2011 5:24 PM
To: [hidden email]
Subject: Re: [Pharo-project] Socket timeout terminates COG VM

The exception is not coming from my code, if it was I could trap it.
Regardless, isn't shutting the VM down a bit of overkill in this case?

On Mon, Oct 10, 2011 at 17:12, Igor Stasenko <[hidden email]> wrote:

--
~JT

Schwab,Wilhelm K

Re: Socket timeout terminates COG VM

In reply to this post by John Toohey

YES - EXACTLY !!!!! :)

________________________________________
From: [hidden email] [[hidden email]] On Behalf Of John Toohey [[hidden email]]
Sent: Monday, October 10, 2011 5:28 PM
To: [hidden email]
Subject: Re: [Pharo-project] Socket timeout terminates COG VM

I agree. In my own networking code, my sockets handlers on both side
never timeout. I have a manager/monitor process that I use if I have
to kill them.

On Mon, Oct 10, 2011 at 17:18, Schwab,Wilhelm K <[hidden email]> wrote:

--
~JT

John Toohey

Re: Socket timeout terminates COG VM

In reply to this post by Henrik Sperre Johansen

Henrik,

Could you explain this in a little more detail for me? Are you saying
the socket timeout is really a semaphore problem?

On Mon, Oct 10, 2011 at 17:58, Henrik Sperre Johansen
<[hidden email]> wrote:

> On 10.10.2011 23:28, John Toohey wrote:
>>
>> I agree. In my own networking code, my sockets handlers on both side
>> never timeout. I have a manager/monitor process that I use if I have
>> to kill them.
>
> Then raise Smalltalk vm maxExternalSemaphoresSilently: to an appropriate
> number (max amount of socket handlers * 3 + some headroom), save your image,
> and you should be set. While it has a max limit of 64k, the socket plugin
> code on at least windows will max out at much less than 20k open sockets, as
> it uses 3 OS threads per socket. (Around 1k IIRC)
> Semaphore timeouts were the old symptoms of running out of this space, now
> it gives you an explicit exception instead.
>
> maxExternalSemaphores: is what is raising the error, some info _should_ be
> written to wherever crLog: redirects to with a NonInteractiveUIManager
> before the image terminates.
>
> Cheers,
> Henry
>
>

--
~JT

John Toohey

Re: Socket timeout terminates COG VM

In reply to this post by Schwab,Wilhelm K

Yep, now even if I fix this, I'll have to move each of my apps to a
separate VM. Dynamic typing and Web apps are not always a perfect
match, and I don't want an error in one bringing everything down.

I'm guessing that this was not a problem for me before, as the older
images or the squeak VM started the UIManager even in headless mode.
Therefore when I used VNC to check the servers, I would see the
debugger windows.

On Mon, Oct 10, 2011 at 18:27, Schwab,Wilhelm K <[hidden email]> wrote:

> John,
>
> No question, the punishment certainly exceeds the crime :) I was making a general plea for what I really believe is the correct way to build network software.
>
> Bill
>
>
>
>
> ________________________________________
> From: [hidden email] [[hidden email]] On Behalf Of John Toohey [[hidden email]]
> Sent: Monday, October 10, 2011 5:24 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] Socket timeout terminates COG VM
>
> The exception is not coming from my code, if it was I could trap it.
> Regardless, isn't shutting the VM down a bit of overkill in this case?
>
> On Mon, Oct 10, 2011 at 17:12, Igor Stasenko <[hidden email]> wrote:
>> On 10 October 2011 23:19, John Toohey <[hidden email]> wrote:
>>> Hi,
>>>
>>> I've had a problem since 1.0 with socket timeouts throwing exceptions
>>> and invoking the debugger in my headless images. I don't know why a
>>> socket timeout is considered exceptional, but I've gotten used to
>>> using VNC to log into the server and close the debuger windows.
>>> However, I've moved to COG and the latest one-click images, and now
>>> the error terminates the VM.
>>>
>>> My app is a standard Seaside server, using the streaming connector for
>>> Comet support.
>>>
>>> I've attached the PharoDebug.log. It would be appreciated if anyone
>>> could help me with this problem, as I'm at a loss where to even begin.
>>>
>>
>> So, just put an exception handler, and handle this exception in a
>> manner you want
>> and then your image will keep working! :)
>>
>>>
>>> Using Pharo1.3 #13298 on Lucid32 (Ubuntu)
>>>
>>>
>>> --
>>> ~JT
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>>
>
>
>
> --
> ~JT
>
>
>

--
~JT

Igor Stasenko

Re: Socket timeout terminates COG VM

In reply to this post by Schwab,Wilhelm K

On 11 October 2011 01:27, Schwab,Wilhelm K <[hidden email]> wrote:
> John,
>
> No question, the punishment certainly exceeds the crime :) I was making a general plea for what I really believe is the correct way to build network software.
>
So you prefer leaving an image in some undefined state, potentially
leaking system resources,
because of unhandled exception which nobody cares to handle?
At best what you can have then is, when your critical process will
enter an endless error-producing loop
is just bogging all system resources or hanging an image, without
giving you any idea what's going on.
So , if you prefer such kind of punishment for your crimes, just use
image prior to 1.3 and be happy :)

> Bill
>
>
>
>
> ________________________________________
> From: [hidden email] [[hidden email]] On Behalf Of John Toohey [[hidden email]]
> Sent: Monday, October 10, 2011 5:24 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] Socket timeout terminates COG VM
>
> The exception is not coming from my code, if it was I could trap it.
> Regardless, isn't shutting the VM down a bit of overkill in this case?
>
> On Mon, Oct 10, 2011 at 17:12, Igor Stasenko <[hidden email]> wrote:
>> On 10 October 2011 23:19, John Toohey <[hidden email]> wrote:
>>> Hi,
>>>
>>> I've had a problem since 1.0 with socket timeouts throwing exceptions
>>> and invoking the debugger in my headless images. I don't know why a
>>> socket timeout is considered exceptional, but I've gotten used to
>>> using VNC to log into the server and close the debuger windows.
>>> However, I've moved to COG and the latest one-click images, and now
>>> the error terminates the VM.
>>>
>>> My app is a standard Seaside server, using the streaming connector for
>>> Comet support.
>>>
>>> I've attached the PharoDebug.log. It would be appreciated if anyone
>>> could help me with this problem, as I'm at a loss where to even begin.
>>>
>>
>> So, just put an exception handler, and handle this exception in a
>> manner you want
>> and then your image will keep working! :)
>>
>>>
>>> Using Pharo1.3 #13298 on Lucid32 (Ubuntu)
>>>
>>>
>>> --
>>> ~JT
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko.
>>
>>
>
>
>
> --
> ~JT
>
>
>

--
Best regards,
Igor Stasenko.

Igor Stasenko

Re: Socket timeout terminates COG VM

In reply to this post by John Toohey

On 11 October 2011 02:03, John Toohey <[hidden email]> wrote:
> Yep, now even if I fix this, I'll have to move each of my apps to a
> separate VM. Dynamic typing and Web apps are not always a perfect
> match, and I don't want an error in one bringing everything down.
>
> I'm guessing that this was not a problem for me before, as the older
> images or the squeak VM started the UIManager even in headless mode.
> Therefore when I used VNC to check the servers, I would see the
> debugger windows.
>
You could hack the UnhandledError default action to suit your needs.

There's many ways to force system to behave like you want.

>
> On Mon, Oct 10, 2011 at 18:27, Schwab,Wilhelm K <[hidden email]> wrote:
>> John,
>>
>> No question, the punishment certainly exceeds the crime :) I was making a general plea for what I really believe is the correct way to build network software.
>>
>> Bill
>>
>>
>>
>>
>> ________________________________________
>> From: [hidden email] [[hidden email]] On Behalf Of John Toohey [[hidden email]]
>> Sent: Monday, October 10, 2011 5:24 PM
>> To: [hidden email]
>> Subject: Re: [Pharo-project] Socket timeout terminates COG VM
>>
>> The exception is not coming from my code, if it was I could trap it.
>> Regardless, isn't shutting the VM down a bit of overkill in this case?
>>
>> On Mon, Oct 10, 2011 at 17:12, Igor Stasenko <[hidden email]> wrote:
>>> On 10 October 2011 23:19, John Toohey <[hidden email]> wrote:
>>>> Hi,
>>>>
>>>> I've had a problem since 1.0 with socket timeouts throwing exceptions
>>>> and invoking the debugger in my headless images. I don't know why a
>>>> socket timeout is considered exceptional, but I've gotten used to
>>>> using VNC to log into the server and close the debuger windows.
>>>> However, I've moved to COG and the latest one-click images, and now
>>>> the error terminates the VM.
>>>>
>>>> My app is a standard Seaside server, using the streaming connector for
>>>> Comet support.
>>>>
>>>> I've attached the PharoDebug.log. It would be appreciated if anyone
>>>> could help me with this problem, as I'm at a loss where to even begin.
>>>>
>>>
>>> So, just put an exception handler, and handle this exception in a
>>> manner you want
>>> and then your image will keep working! :)
>>>
>>>>
>>>> Using Pharo1.3 #13298 on Lucid32 (Ubuntu)
>>>>
>>>>
>>>> --
>>>> ~JT
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko.
>>>
>>>
>>
>>
>>
>> --
>> ~JT
>>
>>
>>
>
>
>
> --
> ~JT
>
>

--
Best regards,
Igor Stasenko.

Schwab,Wilhelm K

Re: Socket timeout terminates COG VM

In reply to this post by Igor Stasenko

Not knowing what exception this is, I'm not sure whether to agree or argue. However, given the importance of error handling to robust network apps, it should get handled.

________________________________________
From: [hidden email] [[hidden email]] On Behalf Of Igor Stasenko [[hidden email]]
Sent: Monday, October 10, 2011 7:05 PM
To: [hidden email]
Subject: Re: [Pharo-project] Socket timeout terminates COG VM

On 11 October 2011 01:27, Schwab,Wilhelm K <[hidden email]> wrote:
> John,
>
> No question, the punishment certainly exceeds the crime :) I was making a general plea for what I really believe is the correct way to build network software.
>
So you prefer leaving an image in some undefined state, potentially
leaking system resources,
because of unhandled exception which nobody cares to handle?
At best what you can have then is, when your critical process will
enter an endless error-producing loop
is just bogging all system resources or hanging an image, without
giving you any idea what's going on.
So , if you prefer such kind of punishment for your crimes, just use
image prior to 1.3 and be happy :)

--
Best regards,
Igor Stasenko.

John Toohey

Re: Socket timeout terminates COG VM

I think the main source of the exceptions is in the WAListenerAdapter
in the #process: aNativeRequest (Implemented in WAServerAdapter) My
app uses Comet so I need a streaming server. I've wrapped an exception
handler around this, and am testing now.

Overall I think that the socket code, if it is going to detect
timeouts, it should retry and the just close and cleanup that socket.
If the calling app ever calls on that socket, then an exception should
be thrown, and in this case, the app would be expecting it.

On Mon, Oct 10, 2011 at 21:34, Schwab,Wilhelm K <[hidden email]> wrote:

> Not knowing what exception this is, I'm not sure whether to agree or argue. However, given the importance of error handling to robust network apps, it should get handled.
>
>
>
> ________________________________________
> From: [hidden email] [[hidden email]] On Behalf Of Igor Stasenko [[hidden email]]
> Sent: Monday, October 10, 2011 7:05 PM
> To: [hidden email]
> Subject: Re: [Pharo-project] Socket timeout terminates COG VM
>
> On 11 October 2011 01:27, Schwab,Wilhelm K <[hidden email]> wrote:
>> John,
>>
>> No question, the punishment certainly exceeds the crime :) I was making a general plea for what I really believe is the correct way to build network software.
>>
> So you prefer leaving an image in some undefined state, potentially
> leaking system resources,
> because of unhandled exception which nobody cares to handle?
> At best what you can have then is, when your critical process will
> enter an endless error-producing loop
> is just bogging all system resources or hanging an image, without
> giving you any idea what's going on.
> So , if you prefer such kind of punishment for your crimes, just use
> image prior to 1.3 and be happy :)
>
>> Bill
>>
>>
>>
>>
>> ________________________________________
>> From: [hidden email] [[hidden email]] On Behalf Of John Toohey [[hidden email]]
>> Sent: Monday, October 10, 2011 5:24 PM
>> To: [hidden email]
>> Subject: Re: [Pharo-project] Socket timeout terminates COG VM
>>
>> The exception is not coming from my code, if it was I could trap it.
>> Regardless, isn't shutting the VM down a bit of overkill in this case?
>>
>> On Mon, Oct 10, 2011 at 17:12, Igor Stasenko <[hidden email]> wrote:
>>> On 10 October 2011 23:19, John Toohey <[hidden email]> wrote:
>>>> Hi,
>>>>
>>>> I've had a problem since 1.0 with socket timeouts throwing exceptions
>>>> and invoking the debugger in my headless images. I don't know why a
>>>> socket timeout is considered exceptional, but I've gotten used to
>>>> using VNC to log into the server and close the debuger windows.
>>>> However, I've moved to COG and the latest one-click images, and now
>>>> the error terminates the VM.
>>>>
>>>> My app is a standard Seaside server, using the streaming connector for
>>>> Comet support.
>>>>
>>>> I've attached the PharoDebug.log. It would be appreciated if anyone
>>>> could help me with this problem, as I'm at a loss where to even begin.
>>>>
>>>
>>> So, just put an exception handler, and handle this exception in a
>>> manner you want
>>> and then your image will keep working! :)
>>>
>>>>
>>>> Using Pharo1.3 #13298 on Lucid32 (Ubuntu)
>>>>
>>>>
>>>> --
>>>> ~JT
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko.
>>>
>>>
>>
>>
>>
>> --
>> ~JT
>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
>
>
>

--
~JT

Schwab,Wilhelm K

Re: Socket timeout terminates COG VM

Sockets are low-level beasts and should simply do what they are told and raise errors when the can't do so. Client and server abstractions on top of that are the soonest that one should think about timeouts and retries (and the latter is really an application level decision). These wrappers will indeed want to handle various errors to keep things clean, perhaps subsequently triggering events/notifications that something happened.

________________________________________
From: [hidden email] [[hidden email]] On Behalf Of John Toohey [[hidden email]]
Sent: Monday, October 10, 2011 10:18 PM
To: [hidden email]
Subject: Re: [Pharo-project] Socket timeout terminates COG VM

I think the main source of the exceptions is in the WAListenerAdapter
in the #process: aNativeRequest (Implemented in WAServerAdapter) My
app uses Comet so I need a streaming server. I've wrapped an exception
handler around this, and am testing now.

Overall I think that the socket code, if it is going to detect
timeouts, it should retry and the just close and cleanup that socket.
If the calling app ever calls on that socket, then an exception should
be thrown, and in this case, the app would be expecting it.

On Mon, Oct 10, 2011 at 21:34, Schwab,Wilhelm K <[hidden email]> wrote:

--
~JT

Stéphane Ducasse

Re: Socket timeout terminates COG VM

In reply to this post by Igor Stasenko

Hi igor

I imagine that if the server is not run headless then the screen will be filled up with debuggers and people can try if they succeed to
connect to the image using a remote tools. Even if I prefer a real headless mode, is my sentence correct?

Stef

On Oct 11, 2011, at 1:05 AM, Igor Stasenko wrote:

> On 11 October 2011 01:27, Schwab,Wilhelm K <[hidden email]> wrote:
>> John,
>>
>> No question, the punishment certainly exceeds the crime :) I was making a general plea for what I really believe is the correct way to build network software.
>>
> So you prefer leaving an image in some undefined state, potentially
> leaking system resources,
> because of unhandled exception which nobody cares to handle?
> At best what you can have then is, when your critical process will
> enter an endless error-producing loop
> is just bogging all system resources or hanging an image, without
> giving you any idea what's going on.
> So , if you prefer such kind of punishment for your crimes, just use
> image prior to 1.3 and be happy :)
>
>> Bill
>>
>>
>>
>>
>> ________________________________________
>> From: [hidden email] [[hidden email]] On Behalf Of John Toohey [[hidden email]]
>> Sent: Monday, October 10, 2011 5:24 PM
>> To: [hidden email]
>> Subject: Re: [Pharo-project] Socket timeout terminates COG VM
>>
>> The exception is not coming from my code, if it was I could trap it.
>> Regardless, isn't shutting the VM down a bit of overkill in this case?
>>
>> On Mon, Oct 10, 2011 at 17:12, Igor Stasenko <[hidden email]> wrote:
>>> On 10 October 2011 23:19, John Toohey <[hidden email]> wrote:
>>>> Hi,
>>>>
>>>> I've had a problem since 1.0 with socket timeouts throwing exceptions
>>>> and invoking the debugger in my headless images. I don't know why a
>>>> socket timeout is considered exceptional, but I've gotten used to
>>>> using VNC to log into the server and close the debuger windows.
>>>> However, I've moved to COG and the latest one-click images, and now
>>>> the error terminates the VM.
>>>>
>>>> My app is a standard Seaside server, using the streaming connector for
>>>> Comet support.
>>>>
>>>> I've attached the PharoDebug.log. It would be appreciated if anyone
>>>> could help me with this problem, as I'm at a loss where to even begin.
>>>>
>>>
>>> So, just put an exception handler, and handle this exception in a
>>> manner you want
>>> and then your image will keep working! :)
>>>
>>>>
>>>> Using Pharo1.3 #13298 on Lucid32 (Ubuntu)
>>>>
>>>>
>>>> --
>>>> ~JT
>>>>
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko.
>>>
>>>
>>
>>
>>
>> --
>> ~JT
>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.
>

Sven Van Caekenberghe

Re: Socket timeout terminates COG VM

In reply to this post by John Toohey

On 10 Oct 2011, at 22:19, John Toohey wrote:

> I've had a problem since 1.0 with socket timeouts throwing exceptions
> and invoking the debugger in my headless images. I don't know why a
> socket timeout is considered exceptional

A server should never 'leak' timeout exceptions.
A timeout is very common and should just result in that connection/conversation being cleaned up.

Sven

Henrik Sperre Johansen

Re: Socket timeout terminates COG VM

In reply to this post by John Toohey

On 11.10.2011 01:00, John Toohey wrote:
> Henrik,
>
> Could you explain this in a little more detail for me? Are you saying
> the socket timeout is really a semaphore problem?
>
Yes, in that Sockets block on Semaphores registered in the vm, which are
then signalled from the external plugin.
The number of objects for which this signalling is done does not grow
automatically, see:
http://code.google.com/p/pharo/issues/detail?id=4505
for the discussion/rationale behind now raising an error when there's no
free space anymore, instead of silently losing signals.

The methods (with comments) in image resulting from this issue, and
interesting to read in this context is:
VirtualMachine >> #maxExternalSemaphores:
- you can change inProduction to true, and it will no longer crash, but
write you a warning that you might be losing signals due to too little
default space.
ExternalSemaphoreTable >> #collectionBasedOn:withRoomFor: and
#freedSlotsIn:ratherThanIncreaseSizeTo:
- comments should hopefully be useful

Cheers,
Henry

Henrik Sperre Johansen

Re: Socket timeout terminates COG VM

In reply to this post by John Toohey

On 11.10.2011 14:17, Henrik Sperre Johansen wrote:

> On 11.10.2011 01:00, John Toohey wrote:
>> Henrik,
>>
>> Could you explain this in a little more detail for me? Are you saying
>> the socket timeout is really a semaphore problem?
>>
> Yes, in that Sockets block on Semaphores registered in the vm, which
> are then signalled from the external plugin.
> The number of objects for which this signalling is done does not grow
> automatically, see:
> http://code.google.com/p/pharo/issues/detail?id=4505
> for the discussion/rationale behind now raising an error when there's
> no free space anymore, instead of silently losing signals.
>
> The methods (with comments) in image resulting from this issue, and
> interesting to read in this context is:
> VirtualMachine >> #maxExternalSemaphores:
> - you can change inProduction to true, and it will no longer crash,
> but write you a warning that you might be losing signals due to too
> little default space.
> ExternalSemaphoreTable >> #collectionBasedOn:withRoomFor: and
> #freedSlotsIn:ratherThanIncreaseSizeTo:
> - comments should hopefully be useful
>
> Cheers,
> Henry
>

Reading it over, I see the temporary needToGrow in #freedSlotsIn: ... is
misnamed.
It should be freedSlots.

Cheers,
Henry