[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
On 10 October 2011 23:19, John Toohey <jt@parspro.com> 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.
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 <siguctua@gmail.com> wrote:
On 10 October 2011 23:19, John Toohey <jt@parspro.com> 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
On 11 October 2011 00:24, John Toohey <jt@parspro.com> 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 <siguctua@gmail.com> wrote:
On 10 October 2011 23:19, John Toohey <jt@parspro.com> 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.
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John Toohey [jt@parspro.com] Sent: Monday, October 10, 2011 5:24 PM To: Pharo-project@lists.gforge.inria.fr 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 <siguctua@gmail.com> wrote:
On 10 October 2011 23:19, John Toohey <jt@parspro.com> 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
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 <bschwab@anest.ufl.edu> 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John Toohey [jt@parspro.com] Sent: Monday, October 10, 2011 5:24 PM To: Pharo-project@lists.gforge.inria.fr 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 <siguctua@gmail.com> wrote:
On 10 October 2011 23:19, John Toohey <jt@parspro.com> 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
On 11 October 2011 02:03, John Toohey <jt@parspro.com> 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 <bschwab@anest.ufl.edu> 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John Toohey [jt@parspro.com] Sent: Monday, October 10, 2011 5:24 PM To: Pharo-project@lists.gforge.inria.fr 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 <siguctua@gmail.com> wrote:
On 10 October 2011 23:19, John Toohey <jt@parspro.com> 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.
On 11 October 2011 01:27, Schwab,Wilhelm K <bschwab@anest.ufl.edu> 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John Toohey [jt@parspro.com] Sent: Monday, October 10, 2011 5:24 PM To: Pharo-project@lists.gforge.inria.fr 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 <siguctua@gmail.com> wrote:
On 10 October 2011 23:19, John Toohey <jt@parspro.com> 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.
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua@gmail.com] Sent: Monday, October 10, 2011 7:05 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Socket timeout terminates COG VM On 11 October 2011 01:27, Schwab,Wilhelm K <bschwab@anest.ufl.edu> 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John Toohey [jt@parspro.com] Sent: Monday, October 10, 2011 5:24 PM To: Pharo-project@lists.gforge.inria.fr 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 <siguctua@gmail.com> wrote:
On 10 October 2011 23:19, John Toohey <jt@parspro.com> 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.
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 <bschwab@anest.ufl.edu> 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua@gmail.com] Sent: Monday, October 10, 2011 7:05 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Socket timeout terminates COG VM
On 11 October 2011 01:27, Schwab,Wilhelm K <bschwab@anest.ufl.edu> 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John Toohey [jt@parspro.com] Sent: Monday, October 10, 2011 5:24 PM To: Pharo-project@lists.gforge.inria.fr 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 <siguctua@gmail.com> wrote:
On 10 October 2011 23:19, John Toohey <jt@parspro.com> 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
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John Toohey [jt@parspro.com] Sent: Monday, October 10, 2011 10:18 PM To: Pharo-project@lists.gforge.inria.fr 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 <bschwab@anest.ufl.edu> 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua@gmail.com] Sent: Monday, October 10, 2011 7:05 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Socket timeout terminates COG VM
On 11 October 2011 01:27, Schwab,Wilhelm K <bschwab@anest.ufl.edu> 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John Toohey [jt@parspro.com] Sent: Monday, October 10, 2011 5:24 PM To: Pharo-project@lists.gforge.inria.fr 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 <siguctua@gmail.com> wrote:
On 10 October 2011 23:19, John Toohey <jt@parspro.com> 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
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 <bschwab@anest.ufl.edu> 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John Toohey [jt@parspro.com] Sent: Monday, October 10, 2011 5:24 PM To: Pharo-project@lists.gforge.inria.fr 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 <siguctua@gmail.com> wrote:
On 10 October 2011 23:19, John Toohey <jt@parspro.com> 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.
On 11 October 2011 09:15, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
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?
Yes. But read the phrase "filled up with debuggers" again: i bet that in 99% cases people just closing debuggers and not wasting time to analyse the cause of every error by opening individual debugger etc. It makes no sense. What makes sense is to add code which doing this automatically + some error logging.
Stef
On Oct 11, 2011, at 1:05 AM, Igor Stasenko wrote:
On 11 October 2011 01:27, Schwab,Wilhelm K <bschwab@anest.ufl.edu> 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John Toohey [jt@parspro.com] Sent: Monday, October 10, 2011 5:24 PM To: Pharo-project@lists.gforge.inria.fr 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 <siguctua@gmail.com> wrote:
On 10 October 2011 23:19, John Toohey <jt@parspro.com> 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.
-- Best regards, Igor Stasenko.
I just wanted to know if I was correct else I agree with you ;D On Oct 11, 2011, at 2:29 PM, Igor Stasenko wrote:
On 11 October 2011 09:15, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
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?
Yes. But read the phrase "filled up with debuggers" again: i bet that in 99% cases people just closing debuggers and not wasting time to analyse the cause of every error by opening individual debugger etc. It makes no sense. What makes sense is to add code which doing this automatically + some error logging.
Stef
On Oct 11, 2011, at 1:05 AM, Igor Stasenko wrote:
On 11 October 2011 01:27, Schwab,Wilhelm K <bschwab@anest.ufl.edu> 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John Toohey [jt@parspro.com] Sent: Monday, October 10, 2011 5:24 PM To: Pharo-project@lists.gforge.inria.fr 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 <siguctua@gmail.com> wrote:
On 10 October 2011 23:19, John Toohey <jt@parspro.com> 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.
-- Best regards, Igor Stasenko.
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John Toohey [jt@parspro.com] Sent: Monday, October 10, 2011 4:19 PM To: pharo-project@lists.gforge.inria.fr 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
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 <bschwab@anest.ufl.edu> 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John Toohey [jt@parspro.com] Sent: Monday, October 10, 2011 4:19 PM To: pharo-project@lists.gforge.inria.fr 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
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
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 <henrik.s.johansen@veloxit.no> 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
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
Thats for this explanation. I can't find the #inProduction method, what class is it in? On Tue, Oct 11, 2011 at 08:17, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> 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
-- ~JT
On 11.10.2011 16:03, John Toohey wrote:
Thats for this explanation. I can't find the #inProduction method, what class is it in? It's a temporary variable in #maxExternalSemaphores for the moment, as no such global switch exist yet. I'd recommend setting the limit higher and save / run the image for awhile to see if the issue persists before deciding to change it to true though. Even if it does persist, I'd check for whether there are references kept to obsolete Sockets before switching though.
Cheers, Henry
YES - EXACTLY !!!!! :) ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John Toohey [jt@parspro.com] Sent: Monday, October 10, 2011 5:28 PM To: Pharo-project@lists.gforge.inria.fr 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 <bschwab@anest.ufl.edu> 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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of John Toohey [jt@parspro.com] Sent: Monday, October 10, 2011 4:19 PM To: pharo-project@lists.gforge.inria.fr 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
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
participants (6)
-
Henrik Sperre Johansen -
Igor Stasenko -
John Toohey -
Schwab,Wilhelm K -
Stéphane Ducasse -
Sven Van Caekenberghe