- Pharo-users - lists.pharo.org

Re: [Pharo-users] CannotWriteData errors in P3 and Seaside

by Sven Van Caekenberghe

IIUC a socket stream does not automatically/automagically know that the state of the connection changed, unless/until it tries to use it (read or write to it, wait for data, ...). I would recommend using #isWorking to actually test if a connection is good, if you would need to do that. That does an actual query. Did you enable P3 logging as I suggested ? What did you learn ? It feels as if in your particular setup the server eagerly closes connections that are open for too long. P3 was written under the assumption that that does not happen (it does not for me). > On 19 Aug 2020, at 19:48, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > I kept looking into this, and still haven't found what might be causing it. > > However, I was trying to "salvage" that until I find a solution, and > run a "healthcheck" to be sure that the GlorpSession has an active > connection, and then I found that a P3Client reports as connected even > when it's not. > > I connected to a PostgreSQL database running in a Docker container, > stopped the container, and the driver continues to report as > connected, even way after the server was stopped (the timeout is using > the default 10 seconds). > > The ZdcSocketStream reports both ends of the socket as connected, when > the server side certainly isn't. > > I noticed also that in P3Client>>connect it calls #ensureOpen, and it > takes the socket as open when it is not, so as soon as it tries to > flush the data written to it, a `CannotWriteData` exception is > signaled. > > In my case I'm developing on Pharo 8 on Windows with PostgreSQL > running in Docker on WSL2 (ubuntu), but on the server it is a 100% > Linux deployment. > > Any ideas? > > Esteban A. Maringolo > > On Mon, Aug 10, 2020 at 5:44 PM Esteban Maringolo <emaringolo(a)gmail.com> wrote: >> >> Looking at the Postgres side of the log I find that the connection was >> reset from the other side (it is Pharo). >> >> The reason for that is yet unknown to me. Since I don't do anything >> (that I'm aware of). >> >> golfware_database.1.9sl4bt9j6cv5@gw | 2020-08-10 20:02:35.939 UTC >> [132] LOG: could not receive data from client: Connection reset by >> peer >> golfware_database.1.9sl4bt9j6cv5@gw | 2020-08-10 20:06:58.083 UTC >> [139] LOG: could not receive data from client: Connection reset by >> peer >> golfware_database.1.9sl4bt9j6cv5@gw | 2020-08-10 20:06:58.083 UTC >> [137] LOG: could not receive data from client: Connection reset by >> peer >> golfware_database.1.9sl4bt9j6cv5@gw | 2020-08-10 20:33:20.163 UTC >> [166] LOG: could not receive data from client: Connection reset by >> peer >> golfware_database.1.9sl4bt9j6cv5@gw | 2020-08-10 20:35:22.019 UTC >> [168] LOG: could not receive data from client: Connection reset by >> peer >> golfware_database.1.9sl4bt9j6cv5@gw | 2020-08-10 20:37:33.091 UTC >> [177] LOG: could not receive data from client: Connection reset by >> peer >> >> I'll have to keep looking. >> >> Best regards! >> >> Esteban A. Maringolo >> >> >> On Mon, Aug 10, 2020 at 5:35 PM Esteban Maringolo <emaringolo(a)gmail.com> wrote: >>> >>> My Seaside session isn't closing the connection, only when >>> unregistered, but this seems to be something else I don't know. >>> >>> I saw there is logging, and I need to set it up in general (including >>> Fuel serialized stacks). >>> Looking in the web apparently there is the need for a keepalive that >>> is not in place. >>> What disturbs me is that it doesn't happen in development. Making things harder. >>> >>> Regards! >>> >>> Esteban A. Maringolo >>> >>> On Mon, Aug 10, 2020 at 5:02 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> >>>> Hi Esteban, >>>> >>>> I have a web app with P3 under Seaside in production and it works fine. But that is without Glorp, nor any connection pooling. >>>> >>>> You say the connection seems closed, maybe the closing got triggered by your app somehow ? How do you clean up expired sessions ? How do you handle logouts ? >>>> >>>> P3 does normally reconnect automatically, IIRC. >>>> >>>> You could try to enable logging in P3Client, that is a recent addition. It should show you what happens to your connections. >>>> >>>> Sven >>>> >>>>> On 10 Aug 2020, at 21:15, Esteban Maringolo <emaringolo(a)gmail.com> wrote: >>>>> >>>>> Hi all, Sven ;-) >>>>> >>>>> I'm having erratic P3 errors in a recent application I wrote using >>>>> Pharo, Seaside and Glorp with P3 as driver. >>>>> >>>>> Each Seaside session has a GlorpSession, which in turn has a >>>>> P3Connection in its accessor. I don't know why, but sometimes the >>>>> P3Connection socket is closed, and then when trying to read from the >>>>> database, it cannot write the query to the P3 socket and exception is >>>>> raised, and it isn't handled by the P3DatabaseDriver (automatically >>>>> trying to reconnect?). >>>>> >>>>> I don't know if I'm doing something wrong, I plan to migrate the >>>>> GlorpPooledDatabaseAccessor and also use the P3ConnectionPool, but I >>>>> want to be sure that the current setup works of if maybe I'm exceeding >>>>> some limit or timeout that causes the connection to be closed. >>>>> >>>>> Regards! >>>>> >>>>> >>>>> Esteban A. Maringolo >>>>> >>>> >>>>

Aug. 19, 2020

Re: [Pharo-users] CannotWriteData errors in P3 and Seaside

by Esteban Maringolo

I kept looking into this, and still haven't found what might be causing it. However, I was trying to "salvage" that until I find a solution, and run a "healthcheck" to be sure that the GlorpSession has an active connection, and then I found that a P3Client reports as connected even when it's not. I connected to a PostgreSQL database running in a Docker container, stopped the container, and the driver continues to report as connected, even way after the server was stopped (the timeout is using the default 10 seconds). The ZdcSocketStream reports both ends of the socket as connected, when the server side certainly isn't. I noticed also that in P3Client>>connect it calls #ensureOpen, and it takes the socket as open when it is not, so as soon as it tries to flush the data written to it, a `CannotWriteData` exception is signaled. In my case I'm developing on Pharo 8 on Windows with PostgreSQL running in Docker on WSL2 (ubuntu), but on the server it is a 100% Linux deployment. Any ideas? Esteban A. Maringolo On Mon, Aug 10, 2020 at 5:44 PM Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > Looking at the Postgres side of the log I find that the connection was > reset from the other side (it is Pharo). > > The reason for that is yet unknown to me. Since I don't do anything > (that I'm aware of). > > golfware_database.1.9sl4bt9j6cv5@gw | 2020-08-10 20:02:35.939 UTC > [132] LOG: could not receive data from client: Connection reset by > peer > golfware_database.1.9sl4bt9j6cv5@gw | 2020-08-10 20:06:58.083 UTC > [139] LOG: could not receive data from client: Connection reset by > peer > golfware_database.1.9sl4bt9j6cv5@gw | 2020-08-10 20:06:58.083 UTC > [137] LOG: could not receive data from client: Connection reset by > peer > golfware_database.1.9sl4bt9j6cv5@gw | 2020-08-10 20:33:20.163 UTC > [166] LOG: could not receive data from client: Connection reset by > peer > golfware_database.1.9sl4bt9j6cv5@gw | 2020-08-10 20:35:22.019 UTC > [168] LOG: could not receive data from client: Connection reset by > peer > golfware_database.1.9sl4bt9j6cv5@gw | 2020-08-10 20:37:33.091 UTC > [177] LOG: could not receive data from client: Connection reset by > peer > > I'll have to keep looking. > > Best regards! > > Esteban A. Maringolo > > > On Mon, Aug 10, 2020 at 5:35 PM Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > > > My Seaside session isn't closing the connection, only when > > unregistered, but this seems to be something else I don't know. > > > > I saw there is logging, and I need to set it up in general (including > > Fuel serialized stacks). > > Looking in the web apparently there is the need for a keepalive that > > is not in place. > > What disturbs me is that it doesn't happen in development. Making things harder. > > > > Regards! > > > > Esteban A. Maringolo > > > > On Mon, Aug 10, 2020 at 5:02 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > > Hi Esteban, > > > > > > I have a web app with P3 under Seaside in production and it works fine. But that is without Glorp, nor any connection pooling. > > > > > > You say the connection seems closed, maybe the closing got triggered by your app somehow ? How do you clean up expired sessions ? How do you handle logouts ? > > > > > > P3 does normally reconnect automatically, IIRC. > > > > > > You could try to enable logging in P3Client, that is a recent addition. It should show you what happens to your connections. > > > > > > Sven > > > > > > > On 10 Aug 2020, at 21:15, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > > > > > > > Hi all, Sven ;-) > > > > > > > > I'm having erratic P3 errors in a recent application I wrote using > > > > Pharo, Seaside and Glorp with P3 as driver. > > > > > > > > Each Seaside session has a GlorpSession, which in turn has a > > > > P3Connection in its accessor. I don't know why, but sometimes the > > > > P3Connection socket is closed, and then when trying to read from the > > > > database, it cannot write the query to the P3 socket and exception is > > > > raised, and it isn't handled by the P3DatabaseDriver (automatically > > > > trying to reconnect?). > > > > > > > > I don't know if I'm doing something wrong, I plan to migrate the > > > > GlorpPooledDatabaseAccessor and also use the P3ConnectionPool, but I > > > > want to be sure that the current setup works of if maybe I'm exceeding > > > > some limit or timeout that causes the connection to be closed. > > > > > > > > Regards! > > > > > > > > > > > > Esteban A. Maringolo > > > > > > > > > >

Aug. 19, 2020

PostgresV2 Driver available?

by Esteban Maringolo

Hi, Is anybody using the "old" PostgresV2 driver in Pharo 8? I just checked in the pharo-rdbms/garage repository and of course everything is very old there. But I'm having a few issues with P3 that I didn't have before (with the PgV2) and I want to be test whether there is something related with the connection or the problem lies somewhere else. Regards! Esteban A. Maringolo

Aug. 19, 2020

Re: [Pharo-users] Disable halt and breakpoints globally

by Steven Costiou

Le 2020-08-19 15:24, Esteban Maringolo a Ã©crit : > There is a similar view in Pharo 8, the Browse breakpoints show breakpoints and halts as well. The P8 view does not allow for dynamic activation, and that logic is only in P9. Steven. > However, I avoid using breakpoints because you cannot add/remove them within the debugger, and sometimes with nested blocks it is hard to specify which expression should get it. > > Regards! > > Esteban A. Maringolo > > On Wed, Aug 19, 2020 at 5:27 AM Steven Costiou <steven.costiou(a)kloum.io> wrote: > > So, I just checked and we have this view in Pharo 9 with all halts and breakpoints. > > We just need to put a global checkbox to (de)activate everything at once (and polish a little bit the view). > > Le 2020-08-19 10:11, Steven Costiou a Ã©crit : > > Hi, > > in Pharo 9/NewTools we added the possibility to disable a halt or a breakpoint through a checkbox in the inspector or from a view in the debugger. > For example this is an inspector on a test object: > > When a halt is disabled this way, it is still in your code but instead of halting it logs into the Transcript. > We planned to have a global view somewhere with a global "checkbox" to enable/disable them all. > But this will be only for Pharo 9. > > But to me it has interest only if you want to keep dormant debugging capabilities in production, that you awake when you have a problem that you need to debug. > Otherwise, I would do as Tim suggested and make sure there are no halts in the production image. > > Steven. > > Le 2020-08-18 22:46, Esteban Maringolo a Ã©crit : > Hi, > > I was bit by a bug in production I couldn't identify and it ended up > being a lost halt in the code that was hanging my whole image. So no > bug at all, a feature :-) > > Is there a way to disable the #halt and breakpoints? > This way I could add such an expression (if existent) to my server > startup and avoid issues like this. > > Regards! > > Esteban A. Maringolo

Aug. 19, 2020

Re: [Pharo-users] Disable halt and breakpoints globally

by Esteban Maringolo

There is a similar view in Pharo 8, the Browse breakpoints show breakpoints and halts as well. However, I avoid using breakpoints because you cannot add/remove them within the debugger, and sometimes with nested blocks it is hard to specify which expression should get it. Regards! Esteban A. Maringolo On Wed, Aug 19, 2020 at 5:27 AM Steven Costiou <steven.costiou(a)kloum.io> wrote: > So, I just checked and we have this view in Pharo 9 with all halts and > breakpoints. > > We just need to put a global checkbox to (de)activate everything at once > (and polish a little bit the view). > > > > Le 2020-08-19 10:11, Steven Costiou a Ã©crit : > > Hi, > > in Pharo 9/NewTools we added the possibility to disable a halt or a > breakpoint through a checkbox in the inspector or from a view in the > debugger. > For example this is an inspector on a test object: > > When a halt is disabled this way, it is still in your code but instead of > halting it logs into the Transcript. > We planned to have a global view somewhere with a global "checkbox" to > enable/disable them all. > But this will be only for Pharo 9. > > But to me it has interest only if you want to keep dormant debugging > capabilities in production, that you awake when you have a problem that you > need to debug. > Otherwise, I would do as Tim suggested and make sure there are no halts in > the production image. > > Steven. > > > > Le 2020-08-18 22:46, Esteban Maringolo a Ã©crit : > > Hi, > > I was bit by a bug in production I couldn't identify and it ended up > being a lost halt in the code that was hanging my whole image. So no > bug at all, a feature :-) > > Is there a way to disable the #halt and breakpoints? > This way I could add such an expression (if existent) to my server > startup and avoid issues like this. > > Regards! > > Esteban A. Maringolo > > > > >

Aug. 19, 2020

Re: [Pharo-users] Disable halt and breakpoints globally

by Esteban Maringolo

Hi Tim, For production I'm building a new Smalltalk image (and a Docker image as well) on each commit to master in my Gitlab repo. I was suggested to add Lint check to the build process in order to avoid being caught by something like this again. But the halt that got me was a notification from the Glorp cache telling the object that it was removed from it. So it was a particular condition that doesn't happen very often in my development image, and because I'm used to put halts here and there, ended up being commited and pushed to master. Best regards! Esteban A. Maringolo On Wed, Aug 19, 2020 at 3:24 AM Tim Mackinnon <tim(a)testit.works> wrote: > > Hi Esteban - its a good question (and I'm intrigued what can be done) - but for production aren't you automatically building a fresh image with a CI system... its pretty easy to do these days and this would stop that. Additionally you could add something to search for self halt, as a build step and fail your build on a non-zero result as well. > > Tim > > On Tue, 18 Aug 2020, at 9:46 PM, Esteban Maringolo wrote: > > Hi, > > > > I was bit by a bug in production I couldn't identify and it ended up > > being a lost halt in the code that was hanging my whole image. So no > > bug at all, a feature :-) > > > > Is there a way to disable the #halt and breakpoints? > > This way I could add such an expression (if existent) to my server > > startup and avoid issues like this. > > > > Regards! > > > > Esteban A. Maringolo > > > > >

Aug. 19, 2020

Re: [Pharo-users] Disable halt and breakpoints globally

by Steven Costiou

So, I just checked and we have this view in Pharo 9 with all halts and breakpoints. We just need to put a global checkbox to (de)activate everything at once (and polish a little bit the view). Le 2020-08-19 10:11, Steven Costiou a Ã©crit : > Hi, > > in Pharo 9/NewTools we added the possibility to disable a halt or a breakpoint through a checkbox in the inspector or from a view in the debugger. > For example this is an inspector on a test object: > > When a halt is disabled this way, it is still in your code but instead of halting it logs into the Transcript. > We planned to have a global view somewhere with a global "checkbox" to enable/disable them all. > But this will be only for Pharo 9. > > But to me it has interest only if you want to keep dormant debugging capabilities in production, that you awake when you have a problem that you need to debug. > Otherwise, I would do as Tim suggested and make sure there are no halts in the production image. > > Steven. > > Le 2020-08-18 22:46, Esteban Maringolo a Ã©crit : > >> Hi, >> >> I was bit by a bug in production I couldn't identify and it ended up >> being a lost halt in the code that was hanging my whole image. So no >> bug at all, a feature :-) >> >> Is there a way to disable the #halt and breakpoints? >> This way I could add such an expression (if existent) to my server >> startup and avoid issues like this. >> >> Regards! >> >> Esteban A. Maringolo

Aug. 19, 2020

Re: [Pharo-users] Disable halt and breakpoints globally

by StÃ©phane Ducasse

Hi Esteban We worked on being able to turn all the halt into dormant halt. (so that we could put a break point and toggle it when running scenario) Now I do not know the status of it. But the idea was nice. @thomas? @esteban What I would like is a simple widgets showing all the halts of the system package | class | method | and some actions to remove them or do something on them If you want to give a try doing this is Spec2 we will happily improve it and include it in Pharo. S > On 18 Aug 2020, at 22:46, Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > Hi, > > I was bit by a bug in production I couldn't identify and it ended up > being a lost halt in the code that was hanging my whole image. So no > bug at all, a feature :-) > > Is there a way to disable the #halt and breakpoints? > This way I could add such an expression (if existent) to my server > startup and avoid issues like this. > > Regards! > > Esteban A. Maringolo > -------------------------------------------- StÃ©phane Ducasse http://stephane.ducasse.free.fr / http://www.pharo.org 03 59 35 87 52 Assistant: Aurore Dalle FAX 03 59 57 78 50 TEL 03 59 35 86 16 S. Ducasse - Inria 40, avenue Halley, Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza Villeneuve d'Ascq 59650 France

Aug. 19, 2020

Re: [Pharo-users] Disable halt and breakpoints globally

by Steven Costiou

Hi, in Pharo 9/NewTools we added the possibility to disable a halt or a breakpoint through a checkbox in the inspector or from a view in the debugger. For example this is an inspector on a test object: When a halt is disabled this way, it is still in your code but instead of halting it logs into the Transcript. We planned to have a global view somewhere with a global "checkbox" to enable/disable them all. But this will be only for Pharo 9. But to me it has interest only if you want to keep dormant debugging capabilities in production, that you awake when you have a problem that you need to debug. Otherwise, I would do as Tim suggested and make sure there are no halts in the production image. Steven. Le 2020-08-18 22:46, Esteban Maringolo a Ã©crit : > Hi, > > I was bit by a bug in production I couldn't identify and it ended up > being a lost halt in the code that was hanging my whole image. So no > bug at all, a feature :-) > > Is there a way to disable the #halt and breakpoints? > This way I could add such an expression (if existent) to my server > startup and avoid issues like this. > > Regards! > > Esteban A. Maringolo

Aug. 19, 2020

Re: [Pharo-users] Disable halt and breakpoints globally

by hogoww

I never tried it, but doesn't the command debugging >> "remove all breakpoints" fits for this purpose? Pierre On 19/08/2020 08:23, Tim Mackinnon wrote: > Hi Esteban - its a good question (and I'm intrigued what can be done) - but for production aren't you automatically building a fresh image with a CI system... its pretty easy to do these days and this would stop that. Additionally you could add something to search for self halt, as a build step and fail your build on a non-zero result as well. > > Tim > > On Tue, 18 Aug 2020, at 9:46 PM, Esteban Maringolo wrote: >> Hi, >> >> I was bit by a bug in production I couldn't identify and it ended up >> being a lost halt in the code that was hanging my whole image. So no >> bug at all, a feature :-) >> >> Is there a way to disable the #halt and breakpoints? >> This way I could add such an expression (if existent) to my server >> startup and avoid issues like this. >> >> Regards! >> >> Esteban A. Maringolo >> >>

Aug. 19, 2020