Re: Log4Net 2.014
Kevin, I don't work on Log4net, but looking through the recent commits it looks like this may have been fixed: https://github.com/apache/logging-log4net/pull/92 I don't know if there is currently a timeline as to when this might be officially released. -Robert Middleton On Thu, Dec 29, 2022 at 5:17 PM Ralph Goers wrote: > > Rupak and Kevin, > > Please note that your emails contain a classification that these are internal > Schwab emails but that you have sent them to a public mailing list. We > obviously ignore such classifications since there is no way to make them > private once you have done that. > > I can’t comment on your specific issue as I don’t work on Log4Net so I will > leave that to those that do. > > Ralph > > > On Dec 29, 2022, at 1:24 PM, Seal, Rupak > > wrote: > > > > HI @Tools Support<mailto:toolssupp...@schwab.com> is there any ways to have > > this work being escalated as this impacted production stability and > > damaging the logging server in Production SNE environment > > > > From: Gardenhire, Kevin > > Date: Thursday, December 29, 2022 at 2:12 PM > > To: dev@logging.apache.org > > Cc: Joshi, Hemant , Vishwakarma, Amit > > , Seal, Rupak , > > Shambhumane, Meenakshi > > Subject: Log4Net 2.014 > > Hi, > > > > We recently upgraded our Log4Net package from 1.2.13 to 2.0.14 to remediate > > a security flaw found in the old package. After upgrading we have found an > > issue that is not allowing 2 instances of an application to write to the > > same file location. We have a blue/green pool deployment strategy where > > each server has an active and inactive application instance and on the > > first deployment we see that the active version logs as expected, but after > > swapping the pools the new active application is unable to log as the now > > inactive application seems to have a lock on the file. > > > > We were able to make it work with 2.0.3, but 2.0.10 is the oldest version > > that does not have the flaw. Any versions of the library without the flaw > > has this locking issue. > > > > Can you help us to raise an issue to be taken up for development in future > > releases? > > > > Thanks, > > Kevin Gardenhire > > Charles Schwab & Co. | Enterprise Middleware and Online Security > > Technology (EMOST) > > > > > > > > Classification: Schwab Internal > > > > > > Classification: Schwab Internal >
Re: Log4Net 2.014
Rupak and Kevin, Please note that your emails contain a classification that these are internal Schwab emails but that you have sent them to a public mailing list. We obviously ignore such classifications since there is no way to make them private once you have done that. I can’t comment on your specific issue as I don’t work on Log4Net so I will leave that to those that do. Ralph > On Dec 29, 2022, at 1:24 PM, Seal, Rupak > wrote: > > HI @Tools Support<mailto:toolssupp...@schwab.com> is there any ways to have > this work being escalated as this impacted production stability and damaging > the logging server in Production SNE environment > > From: Gardenhire, Kevin > Date: Thursday, December 29, 2022 at 2:12 PM > To: dev@logging.apache.org > Cc: Joshi, Hemant , Vishwakarma, Amit > , Seal, Rupak , > Shambhumane, Meenakshi > Subject: Log4Net 2.014 > Hi, > > We recently upgraded our Log4Net package from 1.2.13 to 2.0.14 to remediate a > security flaw found in the old package. After upgrading we have found an > issue that is not allowing 2 instances of an application to write to the same > file location. We have a blue/green pool deployment strategy where each > server has an active and inactive application instance and on the first > deployment we see that the active version logs as expected, but after > swapping the pools the new active application is unable to log as the now > inactive application seems to have a lock on the file. > > We were able to make it work with 2.0.3, but 2.0.10 is the oldest version > that does not have the flaw. Any versions of the library without the flaw has > this locking issue. > > Can you help us to raise an issue to be taken up for development in future > releases? > > Thanks, > Kevin Gardenhire > Charles Schwab & Co. | Enterprise Middleware and Online Security Technology > (EMOST) > > > > Classification: Schwab Internal > > > Classification: Schwab Internal
Re: Log4Net 2.014
HI @Tools Support<mailto:toolssupp...@schwab.com> is there any ways to have this work being escalated as this impacted production stability and damaging the logging server in Production SNE environment From: Gardenhire, Kevin Date: Thursday, December 29, 2022 at 2:12 PM To: dev@logging.apache.org Cc: Joshi, Hemant , Vishwakarma, Amit , Seal, Rupak , Shambhumane, Meenakshi Subject: Log4Net 2.014 Hi, We recently upgraded our Log4Net package from 1.2.13 to 2.0.14 to remediate a security flaw found in the old package. After upgrading we have found an issue that is not allowing 2 instances of an application to write to the same file location. We have a blue/green pool deployment strategy where each server has an active and inactive application instance and on the first deployment we see that the active version logs as expected, but after swapping the pools the new active application is unable to log as the now inactive application seems to have a lock on the file. We were able to make it work with 2.0.3, but 2.0.10 is the oldest version that does not have the flaw. Any versions of the library without the flaw has this locking issue. Can you help us to raise an issue to be taken up for development in future releases? Thanks, Kevin Gardenhire Charles Schwab & Co. | Enterprise Middleware and Online Security Technology (EMOST) Classification: Schwab Internal Classification: Schwab Internal
Log4Net 2.014
Hi, We recently upgraded our Log4Net package from 1.2.13 to 2.0.14 to remediate a security flaw found in the old package. After upgrading we have found an issue that is not allowing 2 instances of an application to write to the same file location. We have a blue/green pool deployment strategy where each server has an active and inactive application instance and on the first deployment we see that the active version logs as expected, but after swapping the pools the new active application is unable to log as the now inactive application seems to have a lock on the file. We were able to make it work with 2.0.3, but 2.0.10 is the oldest version that does not have the flaw. Any versions of the library without the flaw has this locking issue. Can you help us to raise an issue to be taken up for development in future releases? Thanks, Kevin Gardenhire Charles Schwab & Co. | Enterprise Middleware and Online Security Technology (EMOST) Classification: Schwab Internal
