Re: No more dependabot
On Mon, Sep 14, 2020 at 9:23 AM sebb wrote: > > On Mon, 14 Sep 2020 at 13:48, Gary Gregory wrote: > > > > - Sebb: The sooner you know something is broken, the better. For > > That is what Gump is for. > > > example: The new release of commons-net breaks commons-vfs (see my > > other email thread). It is purely coincidental that this happened at > > the time I wanted to release VFS. Still, now I don't really want to > > push through a VFS release until NET and VFS can work together again. > > I'd like help to figure out where the problem is: either it's a bug in > > NET or perhaps VFS never used NET properly since day 1. Please help > > figure it out if you are available. > > Wrong thread. I'm bringing this up more since no one replied to the thread "[VFS][NET] Failures when updating VFS from Net 3.6 to 3.7" Gary > > > - Jochen: What you do with your inbox is your business ;-) What is > > the happy compromise here? Do you want a separate email list? > > That would help. > > > Zero > > Dependabot emails anywhere? If you feel strongly about this, please > > create a [POLL] thread for what you propose. My view is that at > > minimum Dependabot should still be enabled; I don't really care about > > the emails one way or another. > > > > Gary > > > > On Mon, Sep 14, 2020 at 7:12 AM sebb wrote: > > > > > > I agree. > > > > > > It would be more useful if there was a report that people could > > > consult when preparing to release a new version. > > > > > > If someone is working on a component, then they may wish to update > > > dependencies as part of that, but these mass updates distract from the > > > day-to-day changes. > > > > > > What is the use case for updating dependencies between releases? > > > > > > AFAICT the reports don't take into account Java version dependencies, > > > nor do they distinguish which updates are necessary for security > > > reasons. > > > But even if they did, I don't think there is a strong use case for > > > updating software between releases. > > > > > > Sebb. > > > > > > On Mon, 14 Sep 2020 at 08:01, Jochen Wiedmann > > > wrote: > > > > > > > > For the record: Mails from dependabot are now being deleted > > > > automatically from my inbox. > > > > > > > > I consider this to be a failed experiment, and would like us to > > > > terminate it. > > > > > > > > Jochen > > > > > > > > > > > > > > > > -- > > > > > > > > Look, that's why there's rules, understand? So that you think before > > > > you break 'em. > > > > > > > > -- (Terry Pratchett, Thief of Time) > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [dbcp][pool] Use abort instead of close for abandoned connections?
On Mon, Sep 14, 2020 at 1:07 PM Phil Steitz wrote: > > > On 9/14/20 9:36 AM, Gary Gregory wrote: > > This feature is now in Pool master. I will prepare an RC soon if you > > all think we are good to go so we can then move on to DBCP. > > I am still working on testing this in the DBCP use case. Probably best > to wait a little for others to review and for me to get the DBCP change > tested against current pool sources. I should be able to finish that > this weekend. Sounds good. Gary > > Phil > > > > > Gary > > > > On Tue, Sep 8, 2020 at 9:16 AM Gary Gregory wrote: > >> FWIW, I like the name "DestroyMode" because it matches the "destroy" in > >> the method name. > >> > >> Gary > >> > >> On Mon, Sep 7, 2020, 19:08 Gary Gregory wrote: > >>> On Mon, Sep 7, 2020 at 6:02 PM Phil Steitz wrote: > > On 9/3/20 2:44 AM, Mark Thomas wrote: > > On 31/08/2020 01:05, Phil Steitz wrote: > > > > > > > >> If others agree it is a good idea for dbcp, I can do it. I can see the > >> argument that its better to stay with close() even for abandoned and I > >> have not been able to get the deadlock to happen, so I would like to > >> wait a bit and allow others to weigh in. Similarly for pool, I would > >> like to get more community feedback before adding to the interface. > > Hmm. > > > > On one hand if the driver deadlocks I don't see how that can be anything > > other than a driver bug. If multiple code paths obtain multiple locks > > then those code paths must always obtain those locks in the same order. > > Anything else is a bug that is likely to result in a deadlock in a > > multithreaded environment. > > > > On the other hand, it could be argued that the situation only arises > > when an application doesn't correctly return connections to the pool > > and/or keeps them for too long and/or doesn't configure the pool > > correctly for their usage pattern. > > > > The approach of adding > > > > PooledObjectFactory.destroyObject(PooledObject,CloseMode) > > > > where CloseMode is an Enum with two values looks reasonable to me. > > I have started to work on the [pool] changes for this. I want to check > two things before completing the PR: > > 1. "Close" is a [dbcp] concept which does not make sense for all pool > factories, so I am going to name the enum "DestroyMode" and the two > modes, "Default" and "Abandoned". That leaves room for other modes like > "Evicted" or "Invalid" later. > > 2. Speaking of later, technically adding modes will not break binary > compatibility. Are we going to be OK adding outside a major release? > If the answer is no, I might argue to include the other natural modes > now. > >>> Yes, IMO, it is OK to add enum values in a minor release since it does > >>> not break binary (or source) compatibility. > >>> > >>> Gary > >>> > Phil > > > I do agree that abort() should only be used in the case of abandoned > > connections. > > > > Mark > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [dbcp][pool] Use abort instead of close for abandoned connections?
On 9/14/20 9:36 AM, Gary Gregory wrote: This feature is now in Pool master. I will prepare an RC soon if you all think we are good to go so we can then move on to DBCP. I am still working on testing this in the DBCP use case. Probably best to wait a little for others to review and for me to get the DBCP change tested against current pool sources. I should be able to finish that this weekend. Phil Gary On Tue, Sep 8, 2020 at 9:16 AM Gary Gregory wrote: FWIW, I like the name "DestroyMode" because it matches the "destroy" in the method name. Gary On Mon, Sep 7, 2020, 19:08 Gary Gregory wrote: On Mon, Sep 7, 2020 at 6:02 PM Phil Steitz wrote: On 9/3/20 2:44 AM, Mark Thomas wrote: On 31/08/2020 01:05, Phil Steitz wrote: If others agree it is a good idea for dbcp, I can do it. I can see the argument that its better to stay with close() even for abandoned and I have not been able to get the deadlock to happen, so I would like to wait a bit and allow others to weigh in. Similarly for pool, I would like to get more community feedback before adding to the interface. Hmm. On one hand if the driver deadlocks I don't see how that can be anything other than a driver bug. If multiple code paths obtain multiple locks then those code paths must always obtain those locks in the same order. Anything else is a bug that is likely to result in a deadlock in a multithreaded environment. On the other hand, it could be argued that the situation only arises when an application doesn't correctly return connections to the pool and/or keeps them for too long and/or doesn't configure the pool correctly for their usage pattern. The approach of adding PooledObjectFactory.destroyObject(PooledObject,CloseMode) where CloseMode is an Enum with two values looks reasonable to me. I have started to work on the [pool] changes for this. I want to check two things before completing the PR: 1. "Close" is a [dbcp] concept which does not make sense for all pool factories, so I am going to name the enum "DestroyMode" and the two modes, "Default" and "Abandoned". That leaves room for other modes like "Evicted" or "Invalid" later. 2. Speaking of later, technically adding modes will not break binary compatibility. Are we going to be OK adding outside a major release? If the answer is no, I might argue to include the other natural modes now. Yes, IMO, it is OK to add enum values in a minor release since it does not break binary (or source) compatibility. Gary Phil I do agree that abort() should only be used in the case of abandoned connections. Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [dbcp][pool] Use abort instead of close for abandoned connections?
This feature is now in Pool master. I will prepare an RC soon if you all think we are good to go so we can then move on to DBCP. Gary On Tue, Sep 8, 2020 at 9:16 AM Gary Gregory wrote: > > FWIW, I like the name "DestroyMode" because it matches the "destroy" in the > method name. > > Gary > > On Mon, Sep 7, 2020, 19:08 Gary Gregory wrote: >> >> On Mon, Sep 7, 2020 at 6:02 PM Phil Steitz wrote: >> > >> > >> > On 9/3/20 2:44 AM, Mark Thomas wrote: >> > > On 31/08/2020 01:05, Phil Steitz wrote: >> > > >> > > >> > > >> > >> If others agree it is a good idea for dbcp, I can do it. I can see the >> > >> argument that its better to stay with close() even for abandoned and I >> > >> have not been able to get the deadlock to happen, so I would like to >> > >> wait a bit and allow others to weigh in. Similarly for pool, I would >> > >> like to get more community feedback before adding to the interface. >> > > Hmm. >> > > >> > > On one hand if the driver deadlocks I don't see how that can be anything >> > > other than a driver bug. If multiple code paths obtain multiple locks >> > > then those code paths must always obtain those locks in the same order. >> > > Anything else is a bug that is likely to result in a deadlock in a >> > > multithreaded environment. >> > > >> > > On the other hand, it could be argued that the situation only arises >> > > when an application doesn't correctly return connections to the pool >> > > and/or keeps them for too long and/or doesn't configure the pool >> > > correctly for their usage pattern. >> > > >> > > The approach of adding >> > > >> > > PooledObjectFactory.destroyObject(PooledObject,CloseMode) >> > > >> > > where CloseMode is an Enum with two values looks reasonable to me. >> > >> > >> > I have started to work on the [pool] changes for this. I want to check >> > two things before completing the PR: >> > >> > 1. "Close" is a [dbcp] concept which does not make sense for all pool >> > factories, so I am going to name the enum "DestroyMode" and the two >> > modes, "Default" and "Abandoned". That leaves room for other modes like >> > "Evicted" or "Invalid" later. >> > >> > 2. Speaking of later, technically adding modes will not break binary >> > compatibility. Are we going to be OK adding outside a major release? >> > If the answer is no, I might argue to include the other natural modes now. >> >> Yes, IMO, it is OK to add enum values in a minor release since it does >> not break binary (or source) compatibility. >> >> Gary >> >> > >> > Phil >> > >> > > >> > > I do agree that abort() should only be used in the case of abandoned >> > > connections. >> > > >> > > Mark >> > > >> > > - >> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > > For additional commands, e-mail: dev-h...@commons.apache.org >> > > >> > >> > - >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: No more dependabot
On Mon, 14 Sep 2020 at 13:48, Gary Gregory wrote: > > - Sebb: The sooner you know something is broken, the better. For That is what Gump is for. > example: The new release of commons-net breaks commons-vfs (see my > other email thread). It is purely coincidental that this happened at > the time I wanted to release VFS. Still, now I don't really want to > push through a VFS release until NET and VFS can work together again. > I'd like help to figure out where the problem is: either it's a bug in > NET or perhaps VFS never used NET properly since day 1. Please help > figure it out if you are available. Wrong thread. > - Jochen: What you do with your inbox is your business ;-) What is > the happy compromise here? Do you want a separate email list? That would help. > Zero > Dependabot emails anywhere? If you feel strongly about this, please > create a [POLL] thread for what you propose. My view is that at > minimum Dependabot should still be enabled; I don't really care about > the emails one way or another. > > Gary > > On Mon, Sep 14, 2020 at 7:12 AM sebb wrote: > > > > I agree. > > > > It would be more useful if there was a report that people could > > consult when preparing to release a new version. > > > > If someone is working on a component, then they may wish to update > > dependencies as part of that, but these mass updates distract from the > > day-to-day changes. > > > > What is the use case for updating dependencies between releases? > > > > AFAICT the reports don't take into account Java version dependencies, > > nor do they distinguish which updates are necessary for security > > reasons. > > But even if they did, I don't think there is a strong use case for > > updating software between releases. > > > > Sebb. > > > > On Mon, 14 Sep 2020 at 08:01, Jochen Wiedmann > > wrote: > > > > > > For the record: Mails from dependabot are now being deleted > > > automatically from my inbox. > > > > > > I consider this to be a failed experiment, and would like us to terminate > > > it. > > > > > > Jochen > > > > > > > > > > > > -- > > > > > > Look, that's why there's rules, understand? So that you think before > > > you break 'em. > > > > > > -- (Terry Pratchett, Thief of Time) > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: No more dependabot
Le lun. 14 sept. 2020 à 14:48, Gary Gregory a écrit : > > [...] > - Jochen: What you do with your inbox is your business ;-) What is > the happy compromise here? Do you want a separate email list? Zero > Dependabot emails anywhere? If you feel strongly about this, please > create a [POLL] thread for what you propose. https://markmail.org/message/7xsy4huc22qe2gly Gilles > My view is that at > minimum Dependabot should still be enabled; I don't really care about > the emails one way or another. > > Gary > > On Mon, Sep 14, 2020 at 7:12 AM sebb wrote: > > > > I agree. > > > > It would be more useful if there was a report that people could > > consult when preparing to release a new version. > > > > If someone is working on a component, then they may wish to update > > dependencies as part of that, but these mass updates distract from the > > day-to-day changes. > > > > What is the use case for updating dependencies between releases? > > > > AFAICT the reports don't take into account Java version dependencies, > > nor do they distinguish which updates are necessary for security > > reasons. > > But even if they did, I don't think there is a strong use case for > > updating software between releases. > > > > Sebb. > > > > On Mon, 14 Sep 2020 at 08:01, Jochen Wiedmann > > wrote: > > > > > > For the record: Mails from dependabot are now being deleted > > > automatically from my inbox. > > > > > > I consider this to be a failed experiment, and would like us to terminate > > > it. > > > > > > Jochen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: No more dependabot
- Sebb: The sooner you know something is broken, the better. For example: The new release of commons-net breaks commons-vfs (see my other email thread). It is purely coincidental that this happened at the time I wanted to release VFS. Still, now I don't really want to push through a VFS release until NET and VFS can work together again. I'd like help to figure out where the problem is: either it's a bug in NET or perhaps VFS never used NET properly since day 1. Please help figure it out if you are available. - Jochen: What you do with your inbox is your business ;-) What is the happy compromise here? Do you want a separate email list? Zero Dependabot emails anywhere? If you feel strongly about this, please create a [POLL] thread for what you propose. My view is that at minimum Dependabot should still be enabled; I don't really care about the emails one way or another. Gary On Mon, Sep 14, 2020 at 7:12 AM sebb wrote: > > I agree. > > It would be more useful if there was a report that people could > consult when preparing to release a new version. > > If someone is working on a component, then they may wish to update > dependencies as part of that, but these mass updates distract from the > day-to-day changes. > > What is the use case for updating dependencies between releases? > > AFAICT the reports don't take into account Java version dependencies, > nor do they distinguish which updates are necessary for security > reasons. > But even if they did, I don't think there is a strong use case for > updating software between releases. > > Sebb. > > On Mon, 14 Sep 2020 at 08:01, Jochen Wiedmann > wrote: > > > > For the record: Mails from dependabot are now being deleted > > automatically from my inbox. > > > > I consider this to be a failed experiment, and would like us to terminate > > it. > > > > Jochen > > > > > > > > -- > > > > Look, that's why there's rules, understand? So that you think before > > you break 'em. > > > > -- (Terry Pratchett, Thief of Time) > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: No more dependabot
I agree. It would be more useful if there was a report that people could consult when preparing to release a new version. If someone is working on a component, then they may wish to update dependencies as part of that, but these mass updates distract from the day-to-day changes. What is the use case for updating dependencies between releases? AFAICT the reports don't take into account Java version dependencies, nor do they distinguish which updates are necessary for security reasons. But even if they did, I don't think there is a strong use case for updating software between releases. Sebb. On Mon, 14 Sep 2020 at 08:01, Jochen Wiedmann wrote: > > For the record: Mails from dependabot are now being deleted > automatically from my inbox. > > I consider this to be a failed experiment, and would like us to terminate it. > > Jochen > > > > -- > > Look, that's why there's rules, understand? So that you think before > you break 'em. > > -- (Terry Pratchett, Thief of Time) > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[ANNOUNCEMENT] Commons Daemon 1.2.3 Released
The Apache Commons Team is pleased to announce the availability of Apache Commons Daemon 1.2.3. The Apache Commons Daemon software library provides a generic Daemon (unix) or Service (Windows) wrapper for Java code. Version 1.2.3 is a bugfix release. A full list of changes can be found at https://commons.apache.org/proper/commons-daemon/changes-report.html Source and binary distributions are available for download from the Apache Commons download site: https://commons.apache.org/proper/commons-daemon/download_daemon.cgi Please verify signatures using the KEYS file available at the above location when downloading the release. For complete information on Commons Daemon, including instructions on how to submit bug reports, patches, or suggestions for improvement, see the Apache Commons Daemon website: https://commons.apache.org/proper/commons-daemon/ Mark on behalf of the Apache Commons community - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
No more dependabot
For the record: Mails from dependabot are now being deleted automatically from my inbox. I consider this to be a failed experiment, and would like us to terminate it. Jochen -- Look, that's why there's rules, understand? So that you think before you break 'em. -- (Terry Pratchett, Thief of Time) - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
