September 2013 - Pharo-users

Re: [Pharo-users] Image taking up 100% CPU

by Bernat Romagosa

Hmmm something weird just happened. I restarted Komanche, then when I saved the image and the CPU rushed to 100%! 2013/9/25 Janko MivÅ¡ek <janko.mivsek(a)eranova.si> > Hi Bernat, > > I remember once having similar problems on Swazoo. But on image restart. > If Swazoo was not stopped before image shutdown, image went into 100% > CPU after restart. Something like that. It seems therefore that this is > sockets related problem > > What if you stop your web server and start again? > > Best regards > Janko > > Dne 25. 09. 2013 10:03, piÅ¡e Bernat Romagosa: > > Forgot to answer that I'm not using RFB. I had sooo many problems with > > it that since last year I've been using xpra <http://xpra.org/> instead, > > which lets you capture running X windows remotely over SSH. It's kind of > > like screen (not even remotely so powerful) but for GUIs. > > > > Cheers, > > Bernat. > > > > > > 2013/9/25 Bernat Romagosa <tibabenfortlapalanca(a)gmail.com > > <mailto:tibabenfortlapalanca@gmail.com>> > > > > Not really, the image is not being saved regularly... all data is > > stored in a neo4j database, so there's no need to save the image. > > > > It seems like it may have something to do with users uploading files > > in some particular moments, but I'm using GÃ¶ran's file upload > > mechanism, in which files are streamed straight to disk, so there > > shouldn't be any image clogging problems even for huge files... > > > > 2013/9/24 Mariano Martinez Peck <marianopeck(a)gmail.com > > <mailto:marianopeck@gmail.com>> > > > > Bernat, could this be triggered when you SAVE the image? If > > true, do you happen to have RFB running? > > > > > > On Tue, Sep 24, 2013 at 4:45 AM, Bernat Romagosa > > <tibabenfortlapalanca(a)gmail.com > > <mailto:tibabenfortlapalanca@gmail.com>> wrote: > > > > Hi list, > > > > A couple months ago I deployed an Iliad application in a > > Debian VPS, which has been working great except for the fact > > that about every two weeks the image takes up 100% of the > > CPU and, of course, the app becomes unusable. > > > > Does anyone have a method for finding out what's going on? > > I've been trying to debug the problem, but as I don't know > > what triggers it, it's pretty impossible to detect... > > > > I've checked the running threads and nothing seems unusual. > > I've also profiled the app for a whole day of real usage > > with end users and not a single method took more time than > > what I expected, so I'm completely lost here. > > > > Any help will be appreciated! :) > > > -- > Janko MivÅ¡ek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si > > -- Bernat Romagosa.

Sept. 25, 2013

Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed

by Denis Kudriashov

Hi Do you try tODE? (I'm not yet but I really want it) 2013/9/25 Norbert Hartl <norbert(a)hartl.name> > > Am 25.09.2013 um 09:55 schrieb Marcus Denker <marcus.denker(a)inria.fr>: > > > On Sep 25, 2013, at 9:11 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > I use it for remotely deployed images. Whenever a debugger opens I get an > email, connect to the image and examine the problem, fix it and done. > Nothing beats the debugger. > > > Yes, we need remote debugging + Browsing... > > Amen! > > Norbert > > But yes a repl would be useful to for different things. > > Norbert > > Am 25.09.2013 um 03:14 schrieb "Esteban A. Maringolo" < > emaringolo(a)gmail.com>: > > What do people use RFB for? > > A remote interactive REPL could be useful too. > > Regards, > > Esteban A. Maringolo > > > 2013/9/24 Marcus Denker <marcus.denker(a)inria.fr> > >> >> On Sep 24, 2013, at 4:08 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> >> wrote: >> >> Hi guys, >> >> I am having this problem and it is very very easy to reproduce for me. >> And it is in Mac, not Linux. I took a latest Pharo 2.0 image Latest >> update: #20619, and a Mac VM of Mar 13 2013. Open a workspace and >> evaluate: >> >> Gofer it >> smalltalkhubUser: 'PharoExtras' project: 'RFB'; >> configuration; >> load. >> (Smalltalk at: #ConfigurationOfRFB) load. >> (Smalltalk at: #RFBServer) start. >> Smalltalk snapshot: true andQuit: false >> >> And it will freeze. If I save the image with the RFBServer running, my >> image freezes. If the server is stopped while saving, there is no problem. >> The hung seems to be AFTER the image save itself, because if I kill the >> process and start again, the image was saved. Also...if you do SAVE AND >> QUITE, it has NO PROBLEM. If I do Smalltalk snapshot: true andQuit: >> true. the image is saved and when I open it back, it is OK. >> >> >> We need to really re-think if it is a good idea to deploy systems with >> code that is not part of the development cycle of Pharo. >> (read: what people get out of RFB needs to be part of the system itself) >> >> Marcus >> >> > > >

Sept. 25, 2013

Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed

by Norbert Hartl

Am 25.09.2013 um 09:55 schrieb Marcus Denker <marcus.denker(a)inria.fr>: > > On Sep 25, 2013, at 9:11 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> I use it for remotely deployed images. Whenever a debugger opens I get an email, connect to the image and examine the problem, fix it and done. >> Nothing beats the debugger. >> > > Yes, we need remote debugging + Browsing... > Amen! Norbert >> But yes a repl would be useful to for different things. >> >> Norbert >> >> Am 25.09.2013 um 03:14 schrieb "Esteban A. Maringolo" <emaringolo(a)gmail.com>: >> >>> What do people use RFB for? >>> >>> A remote interactive REPL could be useful too. >>> >>> Regards, >>> >>> Esteban A. Maringolo >>> >>> >>> 2013/9/24 Marcus Denker <marcus.denker(a)inria.fr> >>> >>> On Sep 24, 2013, at 4:08 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >>> >>>> Hi guys, >>>> >>>> I am having this problem and it is very very easy to reproduce for me. And it is in Mac, not Linux. I took a latest Pharo 2.0 image Latest update: #20619, and a Mac VM of Mar 13 2013. Open a workspace and evaluate: >>>> >>>> Gofer it >>>> smalltalkhubUser: 'PharoExtras' project: 'RFB'; >>>> configuration; >>>> load. >>>> (Smalltalk at: #ConfigurationOfRFB) load. >>>> (Smalltalk at: #RFBServer) start. >>>> Smalltalk snapshot: true andQuit: false >>>> >>>> And it will freeze. If I save the image with the RFBServer running, my image freezes. If the server is stopped while saving, there is no problem. The hung seems to be AFTER the image save itself, because if I kill the process and start again, the image was saved. Also...if you do SAVE AND QUITE, it has NO PROBLEM. If I do Smalltalk snapshot: true andQuit: true. the image is saved and when I open it back, it is OK. >>> >>> We need to really re-think if it is a good idea to deploy systems with code that is not part of the development cycle of Pharo. >>> (read: what people get out of RFB needs to be part of the system itself) >>> >>> Marcus >>> >>> >

Sept. 25, 2013

Re: [Pharo-users] Image taking up 100% CPU

by Janko MivÅ¡ek

Hi Bernat, I remember once having similar problems on Swazoo. But on image restart. If Swazoo was not stopped before image shutdown, image went into 100% CPU after restart. Something like that. It seems therefore that this is sockets related problem What if you stop your web server and start again? Best regards Janko Dne 25. 09. 2013 10:03, piÅ¡e Bernat Romagosa: > Forgot to answer that I'm not using RFB. I had sooo many problems with > it that since last year I've been using xpra <http://xpra.org/> instead, > which lets you capture running X windows remotely over SSH. It's kind of > like screen (not even remotely so powerful) but for GUIs. > > Cheers, > Bernat. > > > 2013/9/25 Bernat Romagosa <tibabenfortlapalanca(a)gmail.com > <mailto:tibabenfortlapalanca@gmail.com>> > > Not really, the image is not being saved regularly... all data is > stored in a neo4j database, so there's no need to save the image. > > It seems like it may have something to do with users uploading files > in some particular moments, but I'm using GÃ¶ran's file upload > mechanism, in which files are streamed straight to disk, so there > shouldn't be any image clogging problems even for huge files... > > 2013/9/24 Mariano Martinez Peck <marianopeck(a)gmail.com > <mailto:marianopeck@gmail.com>> > > Bernat, could this be triggered when you SAVE the image? If > true, do you happen to have RFB running? > > > On Tue, Sep 24, 2013 at 4:45 AM, Bernat Romagosa > <tibabenfortlapalanca(a)gmail.com > <mailto:tibabenfortlapalanca@gmail.com>> wrote: > > Hi list, > > A couple months ago I deployed an Iliad application in a > Debian VPS, which has been working great except for the fact > that about every two weeks the image takes up 100% of the > CPU and, of course, the app becomes unusable. > > Does anyone have a method for finding out what's going on? > I've been trying to debug the problem, but as I don't know > what triggers it, it's pretty impossible to detect... > > I've checked the running threads and nothing seems unusual. > I've also profiled the app for a whole day of real usage > with end users and not a single method took more time than > what I expected, so I'm completely lost here. > > Any help will be appreciated! :) -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

Sept. 25, 2013

Re: [Pharo-users] Image taking up 100% CPU

by Bernat Romagosa

Forgot to answer that I'm not using RFB. I had sooo many problems with it that since last year I've been using xpra <http://xpra.org/> instead, which lets you capture running X windows remotely over SSH. It's kind of like screen (not even remotely so powerful) but for GUIs. Cheers, Bernat. 2013/9/25 Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> > Not really, the image is not being saved regularly... all data is stored > in a neo4j database, so there's no need to save the image. > > It seems like it may have something to do with users uploading files in > some particular moments, but I'm using GÃ¶ran's file upload mechanism, in > which files are streamed straight to disk, so there shouldn't be any image > clogging problems even for huge files... > > 2013/9/24 Mariano Martinez Peck <marianopeck(a)gmail.com> > >> Bernat, could this be triggered when you SAVE the image? If true, do you >> happen to have RFB running? >> >> >> On Tue, Sep 24, 2013 at 4:45 AM, Bernat Romagosa < >> tibabenfortlapalanca(a)gmail.com> wrote: >> >>> Hi list, >>> >>> A couple months ago I deployed an Iliad application in a Debian VPS, >>> which has been working great except for the fact that about every two weeks >>> the image takes up 100% of the CPU and, of course, the app becomes unusable. >>> >>> Does anyone have a method for finding out what's going on? I've been >>> trying to debug the problem, but as I don't know what triggers it, it's >>> pretty impossible to detect... >>> >>> I've checked the running threads and nothing seems unusual. I've also >>> profiled the app for a whole day of real usage with end users and not a >>> single method took more time than what I expected, so I'm completely lost >>> here. >>> >>> Any help will be appreciated! :) >>> >>> Cheers, >>> >>> Bernat. >>> >>> -- >>> Bernat Romagosa. >>> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > -- > Bernat Romagosa. > -- Bernat Romagosa.

Sept. 25, 2013

Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed

by Marcus Denker

On Sep 25, 2013, at 9:11 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > I use it for remotely deployed images. Whenever a debugger opens I get an email, connect to the image and examine the problem, fix it and done. > Nothing beats the debugger. > Yes, we need remote debugging + Browsing... > But yes a repl would be useful to for different things. > > Norbert > > Am 25.09.2013 um 03:14 schrieb "Esteban A. Maringolo" <emaringolo(a)gmail.com>: > >> What do people use RFB for? >> >> A remote interactive REPL could be useful too. >> >> Regards, >> >> Esteban A. Maringolo >> >> >> 2013/9/24 Marcus Denker <marcus.denker(a)inria.fr> >> >> On Sep 24, 2013, at 4:08 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> >>> Hi guys, >>> >>> I am having this problem and it is very very easy to reproduce for me. And it is in Mac, not Linux. I took a latest Pharo 2.0 image Latest update: #20619, and a Mac VM of Mar 13 2013. Open a workspace and evaluate: >>> >>> Gofer it >>> smalltalkhubUser: 'PharoExtras' project: 'RFB'; >>> configuration; >>> load. >>> (Smalltalk at: #ConfigurationOfRFB) load. >>> (Smalltalk at: #RFBServer) start. >>> Smalltalk snapshot: true andQuit: false >>> >>> And it will freeze. If I save the image with the RFBServer running, my image freezes. If the server is stopped while saving, there is no problem. The hung seems to be AFTER the image save itself, because if I kill the process and start again, the image was saved. Also...if you do SAVE AND QUITE, it has NO PROBLEM. If I do Smalltalk snapshot: true andQuit: true. the image is saved and when I open it back, it is OK. >> >> We need to really re-think if it is a good idea to deploy systems with code that is not part of the development cycle of Pharo. >> (read: what people get out of RFB needs to be part of the system itself) >> >> Marcus >> >>

Sept. 25, 2013

Re: [Pharo-users] Image taking up 100% CPU

by Bernat Romagosa

Not really, the image is not being saved regularly... all data is stored in a neo4j database, so there's no need to save the image. It seems like it may have something to do with users uploading files in some particular moments, but I'm using GÃ¶ran's file upload mechanism, in which files are streamed straight to disk, so there shouldn't be any image clogging problems even for huge files... 2013/9/24 Mariano Martinez Peck <marianopeck(a)gmail.com> > Bernat, could this be triggered when you SAVE the image? If true, do you > happen to have RFB running? > > > On Tue, Sep 24, 2013 at 4:45 AM, Bernat Romagosa < > tibabenfortlapalanca(a)gmail.com> wrote: > >> Hi list, >> >> A couple months ago I deployed an Iliad application in a Debian VPS, >> which has been working great except for the fact that about every two weeks >> the image takes up 100% of the CPU and, of course, the app becomes unusable. >> >> Does anyone have a method for finding out what's going on? I've been >> trying to debug the problem, but as I don't know what triggers it, it's >> pretty impossible to detect... >> >> I've checked the running threads and nothing seems unusual. I've also >> profiled the app for a whole day of real usage with end users and not a >> single method took more time than what I expected, so I'm completely lost >> here. >> >> Any help will be appreciated! :) >> >> Cheers, >> >> Bernat. >> >> -- >> Bernat Romagosa. >> > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Bernat Romagosa.

Sept. 25, 2013

Semantic web packages

by Norbert Hartl

Looking for semantic web tools I found http://www.squeaksource.com/TripleStore/ Are there other resources for the semantic web in pharo? smalltalk? Norbert

Sept. 25, 2013

Re: [Pharo-users] How to load seaside currently?

by Esteban Lorenzano

yes, but the configurations should be also copied into the catalog repositories (I hate that, we need a better way). also AFAIK, the new shiny way of loading Seaside is not to use ConfigurationOfSeaside30, but ConfigurationOfSeaside3 (which is confuse too... :( ) Esteban On Sep 25, 2013, at 8:01 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > in fact grease should be loaded from > > SmHUB/Seaside/MetacelloConfigurations/ > > then the stable version loads version but still have dirty package because the configurations do not load the package where > the trrimboth are removed from grease. > I reported that to Stefan Eggermont and waiting for his answer. > I thought that damien cassou addressed this because we had that problem in Moose. > > > Stef > >> I can confirm the problem with #trimBoth, strange though that it does not simply override the system version but removes it. >> >> On 2013-09-24, at 19:35, Norbert Hartl <norbert(a)hartl.name> wrote: >> >>> Ok, the cause should be that a project I loaded pulled in Grease from squeaksource/Seaside30. In the package Grease-Core-NickAger.70 there are method extensions for String>>#trimBoth et al. For the current pharo these are overrides. So probably seaside tried to update grease and thus removing the methods from the system. As this is a image for playing I loaded all kinds of stuff so I need some time to figure out which package it was. >>> >>> Norbert >>> >>> Am 25.09.2013 um 00:09 schrieb Camillo Bruni <camillobruni(a)gmail.com>: >>> >>>> Strange the build is green: >>>> >>>> https://ci.inria.fr/pharo-contribution/job/Seaside/ >>>> >>>> What kind of error do you get? >>>> Does it happen the same way when you download on of the images from Jenkins? >>>> >>>> On 2013-09-24, at 19:03, Norbert Hartl <norbert(a)hartl.name> wrote: >>>> >>>>> When loading seaside3 from the configuration browser it will break the image badly. It isn't even possible to open a system browser after that. What is the best way to load it manually? Or better is there something new so the configuration browser can be directed to a better config? >>>>> >>>>> Norbert >>>> >>> >>> >> > >

Sept. 25, 2013

Re: [Pharo-users] Pharo 2 problems that prevent me from using it in production was Re: RFB on 2.0 + linux - semaphore primitive failed

by Norbert Hartl

I use it for remotely deployed images. Whenever a debugger opens I get an email, connect to the image and examine the problem, fix it and done. Nothing beats the debugger. But yes a repl would be useful to for different things. Norbert Am 25.09.2013 um 03:14 schrieb "Esteban A. Maringolo" <emaringolo(a)gmail.com>: > What do people use RFB for? > > A remote interactive REPL could be useful too. > > Regards, > > Esteban A. Maringolo > > > 2013/9/24 Marcus Denker <marcus.denker(a)inria.fr> >> >> On Sep 24, 2013, at 4:08 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> >>> Hi guys, >>> >>> I am having this problem and it is very very easy to reproduce for me. And it is in Mac, not Linux. I took a latest Pharo 2.0 image Latest update: #20619, and a Mac VM of Mar 13 2013. Open a workspace and evaluate: >>> >>> Gofer it >>> smalltalkhubUser: 'PharoExtras' project: 'RFB'; >>> configuration; >>> load. >>> (Smalltalk at: #ConfigurationOfRFB) load. >>> (Smalltalk at: #RFBServer) start. >>> Smalltalk snapshot: true andQuit: false >>> >>> And it will freeze. If I save the image with the RFBServer running, my image freezes. If the server is stopped while saving, there is no problem. The hung seems to be AFTER the image save itself, because if I kill the process and start again, the image was saved. Also...if you do SAVE AND QUITE, it has NO PROBLEM. If I do Smalltalk snapshot: true andQuit: true. the image is saved and when I open it back, it is OK. >> >> We need to really re-think if it is a good idea to deploy systems with code that is not part of the development cycle of Pharo. >> (read: what people get out of RFB needs to be part of the system itself) >> >> Marcus >

Sept. 25, 2013