Turning off Spotter using internet!
Hi guys This is hyper annoying that Spotter look for the net by default. We should turn it off. We should also improve the comment of the catalog setting because it is unclear that this is this setting that should be turned off. Stef
On 19 May 2016, at 13:41, stepharo <stepharo@free.fr> wrote:
Hi guys
This is hyper annoying that Spotter look for the net by default.
We should turn it off.
This was 'fixed' in the sense that it now only gets it once every 24 hours and then caches it in the image. The real problem is that NetNameResolver (dns name -> IP address resolution, using of course opaque primitives) sometimes hangs. This makes it very hard for the image to decide if it has network connection or not. And thus hard to react in an intelligent way. This situation is also hard to debug, because if I turn off my wireless network, NetNameResolver fails immediately (which is perfect). It is hard to reproduce the case where it hangs, at least for me. That is the issue that we should fix. Assuming someone has no internet, and force them to manage the connection state themselves manually, seems very backward to me - in this century. So I vote against turning it off.
We should also improve the comment of the catalog setting because it is unclear
that this is this setting that should be turned off.
Yes that would be good.
Stef
On Thu, May 19, 2016 at 1:53 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
This situation is also hard to debug, because if I turn off my wireless network, NetNameResolver fails immediately (which is perfect). It is hard to reproduce the case where it hangs, at least for me.
What about instead of turning off the network just open and listen on a local port and direct DNS there? And because there will be no response it might hang⦠just an idea⦠Peter
https://pharo.fogbugz.com/f/cases/18281/NetNameResolver-class-addressForName...
On 19 May 2016, at 14:07, Peter Uhnák <i.uhnak@gmail.com> wrote:
On Thu, May 19, 2016 at 1:53 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
This situation is also hard to debug, because if I turn off my wireless network, NetNameResolver fails immediately (which is perfect). It is hard to reproduce the case where it hangs, at least for me.
What about instead of turning off the network just open and listen on a local port and direct DNS there? And because there will be no response it might hangâ¦
just an ideaâ¦
Peter
Actually the problem is even worse, NetNameResolver class>>#addressForName: not just hangs for at least its timeout period, during that time the whole image seems to be blocked (as it is a primitive). That is why this is so annoying (spotter goes to great length to work in a background thread, but that does not seem to help here).
On 19 May 2016, at 13:53, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 19 May 2016, at 13:41, stepharo <stepharo@free.fr> wrote:
Hi guys
This is hyper annoying that Spotter look for the net by default.
We should turn it off.
This was 'fixed' in the sense that it now only gets it once every 24 hours and then caches it in the image.
The real problem is that NetNameResolver (dns name -> IP address resolution, using of course opaque primitives) sometimes hangs. This makes it very hard for the image to decide if it has network connection or not. And thus hard to react in an intelligent way.
This situation is also hard to debug, because if I turn off my wireless network, NetNameResolver fails immediately (which is perfect). It is hard to reproduce the case where it hangs, at least for me.
That is the issue that we should fix.
Assuming someone has no internet, and force them to manage the connection state themselves manually, seems very backward to me - in this century.
So I vote against turning it off.
We should also improve the comment of the catalog setting because it is unclear
that this is this setting that should be turned off.
Yes that would be good.
Stef
On Thu, May 19, 2016 at 01:53:04PM +0200, Sven Van Caekenberghe wrote:
On 19 May 2016, at 13:41, stepharo <stepharo@free.fr> wrote:
Hi guys
This is hyper annoying that Spotter look for the net by default.
We should turn it off.
This was 'fixed' in the sense that it now only gets it once every 24 hours and then caches it in the image.
The real problem is that NetNameResolver (dns name -> IP address resolution, using of course opaque primitives) sometimes hangs. This makes it very hard for the image to decide if it has network connection or not. And thus hard to react in an intelligent way.
This situation is also hard to debug, because if I turn off my wireless network, NetNameResolver fails immediately (which is perfect). It is hard to reproduce the case where it hangs, at least for me.
I think this can be "easily" reproduced by leaving Pharo running while switching networks. I haven't tested this explicitly, but my working assumption at the moment is that if I suspend my laptop with Pharo running and connect to a different network then Pharo will hang on the first network access. I'll try and track this down further if someone wants. Cheers, Alistair
On 19 May 2016, at 19:36, Alistair Grant <akgrant0710@gmail.com> wrote:
On Thu, May 19, 2016 at 01:53:04PM +0200, Sven Van Caekenberghe wrote:
On 19 May 2016, at 13:41, stepharo <stepharo@free.fr> wrote:
Hi guys
This is hyper annoying that Spotter look for the net by default.
We should turn it off.
This was 'fixed' in the sense that it now only gets it once every 24 hours and then caches it in the image.
The real problem is that NetNameResolver (dns name -> IP address resolution, using of course opaque primitives) sometimes hangs. This makes it very hard for the image to decide if it has network connection or not. And thus hard to react in an intelligent way.
This situation is also hard to debug, because if I turn off my wireless network, NetNameResolver fails immediately (which is perfect). It is hard to reproduce the case where it hangs, at least for me.
I think this can be "easily" reproduced by leaving Pharo running while switching networks.
I haven't tested this explicitly, but my working assumption at the moment is that if I suspend my laptop with Pharo running and connect to a different network then Pharo will hang on the first network access.
I do this every day twice (home > work > home) and it never fails.
I'll try and track this down further if someone wants.
Yes please, but include details (platform, OS, versions).
Cheers, Alistair
Hi Sven, On Thu, May 19, 2016 at 08:42:36PM +0200, Sven Van Caekenberghe wrote:
On 19 May 2016, at 19:36, Alistair Grant <akgrant0710@gmail.com> wrote:
On Thu, May 19, 2016 at 01:53:04PM +0200, Sven Van Caekenberghe wrote:
On 19 May 2016, at 13:41, stepharo <stepharo@free.fr> wrote:
Hi guys
This is hyper annoying that Spotter look for the net by default.
We should turn it off.
This was 'fixed' in the sense that it now only gets it once every 24 hours and then caches it in the image.
The real problem is that NetNameResolver (dns name -> IP address resolution, using of course opaque primitives) sometimes hangs. This makes it very hard for the image to decide if it has network connection or not. And thus hard to react in an intelligent way.
This situation is also hard to debug, because if I turn off my wireless network, NetNameResolver fails immediately (which is perfect). It is hard to reproduce the case where it hangs, at least for me.
I think this can be "easily" reproduced by leaving Pharo running while switching networks.
I haven't tested this explicitly, but my working assumption at the moment is that if I suspend my laptop with Pharo running and connect to a different network then Pharo will hang on the first network access.
I do this every day twice (home > work > home) and it never fails.
I'll try and track this down further if someone wants.
Yes please, but include details (platform, OS, versions).
My apologies for the slow reply, it has been a busy few days, and will continue for the next few. I'll try and track this down further. FYI: OS: Arch Linux (4.5.4-1-ARCH) Pharo 5.0 various beta versions since early April, currently on 50757. Cheers, Alistair
Thanks sven. I'm working on image without personal setting and often in places with no internet (or full of wifis but that I cannot connect to :). Stef
On 19 May 2016, at 13:41, stepharo <stepharo@free.fr> wrote:
Hi guys
This is hyper annoying that Spotter look for the net by default.
We should turn it off. This was 'fixed' in the sense that it now only gets it once every 24 hours and then caches it in the image.
The real problem is that NetNameResolver (dns name -> IP address resolution, using of course opaque primitives) sometimes hangs. This makes it very hard for the image to decide if it has network connection or not. And thus hard to react in an intelligent way.
This situation is also hard to debug, because if I turn off my wireless network, NetNameResolver fails immediately (which is perfect). It is hard to reproduce the case where it hangs, at least for me.
That is the issue that we should fix.
Assuming someone has no internet, and force them to manage the connection state themselves manually, seems very backward to me - in this century.
So I vote against turning it off.
We should also improve the comment of the catalog setting because it is unclear
that this is this setting that should be turned off. Yes that would be good.
Stef
On 21 May 2016, at 08:43, stepharo <stepharo@free.fr> wrote:
Thanks sven.
I'm working on image without personal setting and often in places with no internet (or full of wifis but that I cannot connect to :).
Stef
On 19 May 2016, at 13:41, stepharo <stepharo@free.fr> wrote:
Hi guys
This is hyper annoying that Spotter look for the net by default.
We should turn it off. This was 'fixed' in the sense that it now only gets it once every 24 hours and then caches it in the image.
The real problem is that NetNameResolver (dns name -> IP address resolution, using of course opaque primitives) sometimes hangs. This makes it very hard for the image to decide if it has network connection or not. And thus hard to react in an intelligent way.
this means we need better support for networking, I think :) Esteban
This situation is also hard to debug, because if I turn off my wireless network, NetNameResolver fails immediately (which is perfect). It is hard to reproduce the case where it hangs, at least for me.
That is the issue that we should fix.
Assuming someone has no internet, and force them to manage the connection state themselves manually, seems very backward to me - in this century.
So I vote against turning it off.
We should also improve the comment of the catalog setting because it is unclear
that this is this setting that should be turned off. Yes that would be good.
Stef
On Thu, May 19, 2016 at 12:41 PM, stepharo <stepharo@free.fr> wrote:
Hi guys
This is hyper annoying that Spotter look for the net by default.
We should turn it off. We should also improve the comment of the catalog setting because it is unclear
that this is this setting that should be turned off.
Yes agree especially in country in Cameroon with low internet bandwith ... this is not good. -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
Or at a conference when the keynote is very boring and everybody is checking email or Facebook⦠:-) Alexandre
On May 19, 2016, at 10:01 AM, Serge Stinckwich <serge.stinckwich@gmail.com> wrote:
On Thu, May 19, 2016 at 12:41 PM, stepharo <stepharo@free.fr> wrote:
Hi guys
This is hyper annoying that Spotter look for the net by default.
We should turn it off. We should also improve the comment of the catalog setting because it is unclear
that this is this setting that should be turned off.
Yes agree especially in country in Cameroon with low internet bandwith ... this is not good.
-- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
participants (7)
-
Alexandre Bergel -
Alistair Grant -
Esteban Lorenzano -
Peter Uhnák -
Serge Stinckwich -
stepharo -
Sven Van Caekenberghe