Re: [EMAIL] Serious network crash bug for commons email 2 library
Interesting. Thanks,
Since commons-mail is pure Java, there's no way this can be completely
caused by bugs in commons-mail. though it sounds like some detail in
commons-mail is tickling other bugs elsewhere in the chain. My guess
is the network driver is at fault since that's what crashes and it
only happens in one version of the driver, but it could be the JDK,
the OS, or all three.
On Fri, Jul 26, 2024 at 4:52 AM Adrian Mikula
wrote:
>
> Hi everyone,
>
> I am a senior software engineer working on a TomEE project and as part of our
> recent upgrade to Jakarta 10 and Java 17, we also upgraded the Apache Commons
> email library to version 2 which you just released.
>
> We encountered a very critical bug which only occurs with certain hardware
> and drivers, but it has very serious impacts on the host OS and would be
> catastrophic if it were to happen on production systems. I suggest you look
> into this as a matter of urgency because I would not want anyone else to
> encounter this bug as it is very bad, but also very obscure and could easily
> be missed during testing.
>
>
> PROBLEM DESCRIPTION:
> On certain physical hardware, with a specific OS network driver installed, if
> the Apache commons email2 library is used and an email is sent, the email
> fails to send, and the OS network driver crashes and the computer loses all
> network access. The network access can only be restored by restarting the
> computer, sometimes multiple times.
>
>
> HARDWARE & OS:
> Computer: Optiplex 7000
> Windows 11
> Ethernet driver: Intel 12.19.2.45
>
> SOFTWARE:
> Java 17
> Jakarta 10
> TomEE 9.1.2
>
> These dependencies caused the issue:
> commons-mail = { module = "org.apache.commons:commons-email2-jakarta",
> version = "2.0.0-M1" }
> commons-mail-core = { module = "org.apache.commons:commons-email2-core",
> version = "2.0.0-M1" }
>
> We tried both the snapshot version from a few months ago, and the final
> release version from a few weeks ago.
> Snapshot repo: https://repository.apache.org/content/repositories/snapshots/
> Release repo:
> https://mvnrepository.com/artifact/org.apache.commons/commons-email2-jakarta/2.0.0-M1
>
> In the Java code:
> import org.apache.commons.mail2.core.EmailException;
> import org.apache.commons.mail2.jakarta.HtmlEmail;
>
>
> STEPS TO REPRODUCE:
>
> 1. Make sure you are testing on a computer with the same physical
> hardware/network card
> 2. Install the exact same version of the Intel ethernet driver. This issue
> does not occur for older/newer versions of the Intel driver
> 3. Run TomEE9 with the apache-commons-email2 library in the libs folder of
> a WAR deployment.
> 4. Send an email.
> 5. The email will never get sent across the network.
> 6. The computer will lose all network access.
> 7. Network access will only be restored after restarting the computer.
>
> DEBUG NOTES:
>
> While debugging the Java stack trace, we found that if the commons-email2
> libraries are used, somehow one of the Java classes in geronimo-mail is
> called which is part of the TomEE/libs and this crashes the computer network.
> So it might be an issue with commons-email2 communicating with certain
> 3rd-party libraries in combination with certain hardware/drivers.
>
>
> STEPS TO FIX:
>
> If we add an excludes for the Geronimo library, and swap apache-commons-email
> with a different email implementation library, it seems fine.
>
>
>
> Please also note if I update my network driver to the latest Intel version,
> 2.0.0-M1 doesn't crash my network. It also doesn't crash with older driver
> versions, only version 12.19.2.45. This is not an issue for Linux systems.
>
> Please let me know if you need any more information about how to reproduce
> the issue.
>
> Regards,
> Adrian
--
Elliotte Rusty Harold
elh...@ibiblio.org
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [EMAIL] Serious network crash bug for commons email 2 library
What is the stack trace? That's a critical element you left out. It could
just be a class path entry ordering issue.
Gary
On Fri, Jul 26, 2024, 7:39 AM Elliotte Rusty Harold
wrote:
> Interesting. Thanks,
>
> Since commons-mail is pure Java, there's no way this can be completely
> caused by bugs in commons-mail. though it sounds like some detail in
> commons-mail is tickling other bugs elsewhere in the chain. My guess
> is the network driver is at fault since that's what crashes and it
> only happens in one version of the driver, but it could be the JDK,
> the OS, or all three.
>
>
> On Fri, Jul 26, 2024 at 4:52 AM Adrian Mikula
> wrote:
> >
> > Hi everyone,
> >
> > I am a senior software engineer working on a TomEE project and as part
> of our recent upgrade to Jakarta 10 and Java 17, we also upgraded the
> Apache Commons email library to version 2 which you just released.
> >
> > We encountered a very critical bug which only occurs with certain
> hardware and drivers, but it has very serious impacts on the host OS and
> would be catastrophic if it were to happen on production systems. I
> suggest you look into this as a matter of urgency because I would not want
> anyone else to encounter this bug as it is very bad, but also very obscure
> and could easily be missed during testing.
> >
> >
> > PROBLEM DESCRIPTION:
> > On certain physical hardware, with a specific OS network driver
> installed, if the Apache commons email2 library is used and an email is
> sent, the email fails to send, and the OS network driver crashes and the
> computer loses all network access. The network access can only be restored
> by restarting the computer, sometimes multiple times.
> >
> >
> > HARDWARE & OS:
> > Computer: Optiplex 7000
> > Windows 11
> > Ethernet driver: Intel 12.19.2.45
> >
> > SOFTWARE:
> > Java 17
> > Jakarta 10
> > TomEE 9.1.2
> >
> > These dependencies caused the issue:
> > commons-mail = { module = "org.apache.commons:commons-email2-jakarta",
> version = "2.0.0-M1" }
> > commons-mail-core = { module = "org.apache.commons:commons-email2-core",
> version = "2.0.0-M1" }
> >
> > We tried both the snapshot version from a few months ago, and the final
> release version from a few weeks ago.
> > Snapshot repo:
> https://repository.apache.org/content/repositories/snapshots/
> > Release repo:
> https://mvnrepository.com/artifact/org.apache.commons/commons-email2-jakarta/2.0.0-M1
> >
> > In the Java code:
> > import org.apache.commons.mail2.core.EmailException;
> > import org.apache.commons.mail2.jakarta.HtmlEmail;
> >
> >
> > STEPS TO REPRODUCE:
> >
> > 1. Make sure you are testing on a computer with the same physical
> hardware/network card
> > 2. Install the exact same version of the Intel ethernet driver. This
> issue does not occur for older/newer versions of the Intel driver
> > 3. Run TomEE9 with the apache-commons-email2 library in the libs
> folder of a WAR deployment.
> > 4. Send an email.
> > 5. The email will never get sent across the network.
> > 6. The computer will lose all network access.
> > 7. Network access will only be restored after restarting the computer.
> >
> > DEBUG NOTES:
> >
> > While debugging the Java stack trace, we found that if the
> commons-email2 libraries are used, somehow one of the Java classes in
> geronimo-mail is called which is part of the TomEE/libs and this crashes
> the computer network. So it might be an issue with commons-email2
> communicating with certain 3rd-party libraries in combination with certain
> hardware/drivers.
> >
> >
> > STEPS TO FIX:
> >
> > If we add an excludes for the Geronimo library, and swap
> apache-commons-email with a different email implementation library, it
> seems fine.
> >
> >
> >
> > Please also note if I update my network driver to the latest Intel
> version, 2.0.0-M1 doesn't crash my network. It also doesn't crash with
> older driver versions, only version 12.19.2.45. This is not an issue for
> Linux systems.
> >
> > Please let me know if you need any more information about how to
> reproduce the issue.
> >
> > Regards,
> > Adrian
>
>
>
> --
> Elliotte Rusty Harold
> elh...@ibiblio.org
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
Re: [LAZY][VOTE] Release Apache Commons Parent 72 based on RC1
My +1 Gary On Sun, Jul 21, 2024 at 2:34 PM Gary Gregory wrote: > > We have added enhancements since Apache Commons Parent 71 was > released, so I would like to release Apache Commons Parent 72. > > Apache Commons Parent 72 RC1 is available for review here: > https://dist.apache.org/repos/dist/dev/commons/parent/72-RC1 (svn > revision 70453) > > The Git tag commons-parent-72-RC1 commit for this RC is > 5eb7ad71ec5db46c9e08527969c00bb3bfced5e3 which you can browse here: > > https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=5eb7ad71ec5db46c9e08527969c00bb3bfced5e3 > You may checkout this tag using: > git clone https://gitbox.apache.org/repos/asf/commons-parent.git > --branch commons-parent-72-RC1 commons-parent-72-RC1 > > Maven artifacts are here: > > https://repository.apache.org/content/repositories/orgapachecommons-1761/org/apache/commons/commons-parent/72/ > > These are the artifacts and their hashes: > > #Release SHA-512s > #Sun Jul 21 18:25:27 UTC 2024 > commons-parent-72-bom.json=7d0abc1bf1aacd58aae935d3f89bb87fc2e5d257470da5033fdd055a5ed11a6422e0db2cbac5103e81099853667c17ac7fc79bc8c5d1103257bc0ae46b6dfb56 > commons-parent-72-bom.xml=c51f4b9619b5502fc895ca7b2998dd868115ac16c6547e0a67355160858990f40f4399fd6ef5182cbb6e6d14e65bf91d48da83068a79d1f2808834ce2d89ff22 > commons-parent-72-site.xml=5f045989b2c281c567467548678fe8685efabf5c13104299eea87b6ab6b6a75c9e98b590d7b288b8ec3a06934061709d0851a6dd9d9b45100ee2950908ec2d6c > commons-parent-72-src.tar.gz=5c6e0bd4090906fe0dfef5bc204e0de37f2f6177e30a25f1a292734a41954f992e8ee617bfb25c284e96ca0f0d85285f8138721346a6084b023adf99f3b0d752 > commons-parent-72-src.zip=2e9811baf549e88a94573fd4239e56180a62971af4bbf3d64f47ba37ea4dddf8d36e9074fd8ed9595172acdb35c0cc107ed5e9474756c6675b1d6bdecc49b558 > org.apache.commons_commons-parent-72.spdx.json=6607c088dee95917cf5d06dc51731a6463a6deb66a069f52870d12f3c733b063b142376240829d9afc3356f430d17ba6b8f81bf0a20f418f56365aa2065fea29 > > > > I have tested this with 'mvn' and 'mvn -e -V -Prelease -Ptest-deploy > -P jacoco -P japicmp clean package site deploy' using: > > openjdk version "17.0.12" 2024-07-16 > OpenJDK Runtime Environment Homebrew (build 17.0.12+0) > OpenJDK 64-Bit Server VM Homebrew (build 17.0.12+0, mixed mode, sharing) > > Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256) > Maven home: /usr/local/Cellar/maven/3.9.8/libexec > Java version: 17.0.12, vendor: Homebrew, runtime: > /usr/local/Cellar/openjdk@17/17.0.12/libexec/openjdk.jdk/Contents/Home > Default locale: en_US, platform encoding: UTF-8 > OS name: "mac os x", version: "14.5", arch: "x86_64", family: "mac" > > Darwin 23.5.0 Darwin Kernel Version 23.5.0: Wed May 1 20:09:52 > PDT 2024; root:xnu-10063.121.3~5/RELEASE_X86_64 x86_64 > > Details of changes since 71 are in the release notes: > > https://dist.apache.org/repos/dist/dev/commons/parent/72-RC1/RELEASE-NOTES.txt > > https://dist.apache.org/repos/dist/dev/commons/parent/72-RC1/site/changes-report.html > > Site: > > https://dist.apache.org/repos/dist/dev/commons/parent/72-RC1/site/index.html > (note some *relative* links are broken and the 72 directories are > not yet created - these will be OK once the site is deployed.) > > RAT Report: > > https://dist.apache.org/repos/dist/dev/commons/parent/72-RC1/site/rat-report.html > > KEYS: > https://downloads.apache.org/commons/KEYS > > Please review the release candidate and vote. > This vote will close no sooner than 72 hours from now. > > [ ] +1 Release these artifacts > [ ] +0 OK, but... > [ ] -0 OK, but really should fix... > [ ] -1 I oppose this release because... > > Thank you, > > Gary Gregory, > Release Manager (using key 86fdc7e2a11262cb) > > The following is intended as a helper and refresher for reviewers. > > Validating a release candidate > == > > These guidelines are NOT complete. > > Requirements: Git, Java, Maven. > > You can validate a release from a release candidate (RC) tag as follows. > > 1a) Clone and checkout the RC tag > > git clone https://gitbox.apache.org/repos/asf/commons-parent.git > --branch commons-parent-72-RC1 commons-parent-72-RC1 > cd commons-parent-72-RC1 > > 1b) Download and unpack the source archive from: > > https://dist.apache.org/repos/dist/dev/commons/parent/72-RC1/source > > 2) Check Apache licenses > > This step is not required if the site includes a RAT report page which > you then must check. > > mvn apache-rat:check > > 3) Check binary compatibility > > Older components still use Apache Clirr: > > This step is not required if the site includes a Clirr report page > which you then must check. > > mvn clirr:check > > Newer components use JApiCmp with the japicmp Maven Profile: > > This step is not required if the site includes a JApiCmp report page > which you then must check. > > mvn install -DskipTests -P japicmp japicmp:cmp > > 4) Build the package > > mvn -V clean package > > You can record the Maven an
[RESULT][LAZY][VOTE] Release Apache Commons Parent 72 based on RC1
This lazy vote passes with the following binding +1 vote: - Gary Gregory (ggregory) Gary On Fri, Jul 26, 2024 at 8:04 AM Gary Gregory wrote: > > My +1 > > Gary > > On Sun, Jul 21, 2024 at 2:34 PM Gary Gregory wrote: > > > > We have added enhancements since Apache Commons Parent 71 was > > released, so I would like to release Apache Commons Parent 72. > > > > Apache Commons Parent 72 RC1 is available for review here: > > https://dist.apache.org/repos/dist/dev/commons/parent/72-RC1 (svn > > revision 70453) > > > > The Git tag commons-parent-72-RC1 commit for this RC is > > 5eb7ad71ec5db46c9e08527969c00bb3bfced5e3 which you can browse here: > > > > https://gitbox.apache.org/repos/asf?p=commons-parent.git;a=commit;h=5eb7ad71ec5db46c9e08527969c00bb3bfced5e3 > > You may checkout this tag using: > > git clone https://gitbox.apache.org/repos/asf/commons-parent.git > > --branch commons-parent-72-RC1 commons-parent-72-RC1 > > > > Maven artifacts are here: > > > > https://repository.apache.org/content/repositories/orgapachecommons-1761/org/apache/commons/commons-parent/72/ > > > > These are the artifacts and their hashes: > > > > #Release SHA-512s > > #Sun Jul 21 18:25:27 UTC 2024 > > commons-parent-72-bom.json=7d0abc1bf1aacd58aae935d3f89bb87fc2e5d257470da5033fdd055a5ed11a6422e0db2cbac5103e81099853667c17ac7fc79bc8c5d1103257bc0ae46b6dfb56 > > commons-parent-72-bom.xml=c51f4b9619b5502fc895ca7b2998dd868115ac16c6547e0a67355160858990f40f4399fd6ef5182cbb6e6d14e65bf91d48da83068a79d1f2808834ce2d89ff22 > > commons-parent-72-site.xml=5f045989b2c281c567467548678fe8685efabf5c13104299eea87b6ab6b6a75c9e98b590d7b288b8ec3a06934061709d0851a6dd9d9b45100ee2950908ec2d6c > > commons-parent-72-src.tar.gz=5c6e0bd4090906fe0dfef5bc204e0de37f2f6177e30a25f1a292734a41954f992e8ee617bfb25c284e96ca0f0d85285f8138721346a6084b023adf99f3b0d752 > > commons-parent-72-src.zip=2e9811baf549e88a94573fd4239e56180a62971af4bbf3d64f47ba37ea4dddf8d36e9074fd8ed9595172acdb35c0cc107ed5e9474756c6675b1d6bdecc49b558 > > org.apache.commons_commons-parent-72.spdx.json=6607c088dee95917cf5d06dc51731a6463a6deb66a069f52870d12f3c733b063b142376240829d9afc3356f430d17ba6b8f81bf0a20f418f56365aa2065fea29 > > > > > > > > I have tested this with 'mvn' and 'mvn -e -V -Prelease -Ptest-deploy > > -P jacoco -P japicmp clean package site deploy' using: > > > > openjdk version "17.0.12" 2024-07-16 > > OpenJDK Runtime Environment Homebrew (build 17.0.12+0) > > OpenJDK 64-Bit Server VM Homebrew (build 17.0.12+0, mixed mode, sharing) > > > > Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256) > > Maven home: /usr/local/Cellar/maven/3.9.8/libexec > > Java version: 17.0.12, vendor: Homebrew, runtime: > > /usr/local/Cellar/openjdk@17/17.0.12/libexec/openjdk.jdk/Contents/Home > > Default locale: en_US, platform encoding: UTF-8 > > OS name: "mac os x", version: "14.5", arch: "x86_64", family: "mac" > > > > Darwin 23.5.0 Darwin Kernel Version 23.5.0: Wed May 1 20:09:52 > > PDT 2024; root:xnu-10063.121.3~5/RELEASE_X86_64 x86_64 > > > > Details of changes since 71 are in the release notes: > > > > https://dist.apache.org/repos/dist/dev/commons/parent/72-RC1/RELEASE-NOTES.txt > > > > https://dist.apache.org/repos/dist/dev/commons/parent/72-RC1/site/changes-report.html > > > > Site: > > > > https://dist.apache.org/repos/dist/dev/commons/parent/72-RC1/site/index.html > > (note some *relative* links are broken and the 72 directories are > > not yet created - these will be OK once the site is deployed.) > > > > RAT Report: > > > > https://dist.apache.org/repos/dist/dev/commons/parent/72-RC1/site/rat-report.html > > > > KEYS: > > https://downloads.apache.org/commons/KEYS > > > > Please review the release candidate and vote. > > This vote will close no sooner than 72 hours from now. > > > > [ ] +1 Release these artifacts > > [ ] +0 OK, but... > > [ ] -0 OK, but really should fix... > > [ ] -1 I oppose this release because... > > > > Thank you, > > > > Gary Gregory, > > Release Manager (using key 86fdc7e2a11262cb) > > > > The following is intended as a helper and refresher for reviewers. > > > > Validating a release candidate > > == > > > > These guidelines are NOT complete. > > > > Requirements: Git, Java, Maven. > > > > You can validate a release from a release candidate (RC) tag as follows. > > > > 1a) Clone and checkout the RC tag > > > > git clone https://gitbox.apache.org/repos/asf/commons-parent.git > > --branch commons-parent-72-RC1 commons-parent-72-RC1 > > cd commons-parent-72-RC1 > > > > 1b) Download and unpack the source archive from: > > > > https://dist.apache.org/repos/dist/dev/commons/parent/72-RC1/source > > > > 2) Check Apache licenses > > > > This step is not required if the site includes a RAT report page which > > you then must check. > > > > mvn apache-rat:check > > > > 3) Check binary compatibility > > > > Older components still use Apache Clirr: > > > > This step is not required if t
Re: [ALL] Use of assert checks in code
On Thu, Jul 25, 2024 at 6:56 PM sebb wrote: > > On Thu, 25 Jul 2024 at 17:46, Gary Gregory wrote: > > > > Java assertions only make sense in specific cases. > > > > Never in test code, use JUnit for that (or TestNG). > > > > It might make sense in low level libraries to enable some semantic checking > > which can be enabled on the CLI. This might be more convenient instead of > > "if debug is on AND some condition then throw a runtime exception". > > > > The above would be orthogonal to using a logging framework. > > > > In general though, I don't use Java's assert keyword. > > What about the following? > > https://github.com/apache/commons-io/blob/c155293776f49eef93547aca9cf181c8a0591cad/src/main/java/org/apache/commons/io/input/ReadAheadInputStream.java#L488 > https://github.com/apache/commons-io/blob/c155293776f49eef93547aca9cf181c8a0591cad/src/main/java/org/apache/commons/io/input/ReadAheadInputStream.java#L498 > > https://github.com/apache/commons-io/blob/c155293776f49eef93547aca9cf181c8a0591cad/src/main/java/org/apache/commons/io/input/ThrottledInputStream.java#L130 > https://github.com/apache/commons-io/blob/c155293776f49eef93547aca9cf181c8a0591cad/src/main/java/org/apache/commons/io/input/ThrottledInputStream.java#L150 It looks like some of these could be IllegalArgumentExceptions and some IllegalStateExceptions. Worth experimenting with the changes to see if anything breaks. Gary > > > Gary > > > > On Thu, Jul 25, 2024, 12:24 PM sebb wrote: > > > > > I'm not convinced that it ever makes sense to use assert checks in our > > > code. > > > > > > In the case of test code, it seems to me that a JUnit assertion makes > > > more sense, as it is unconditionally checked. > > > > > > In main code, does it make sense to use a check that is not guaranteed to > > > run? > > > I would expect to see an IllegalStateException instead if the check fails. > > > > > > However, if an assert IS needed, in most cases it needs a message to > > > ensure any failures contain sufficient information to determine the > > > cause of the failure. > > > > > > For example: > > > > > > assert length >= 10; // bad: what is the value of length? > > > > > > assert length >= 10 : "Length: " + length; // good: show unexpected value > > > > > > assert isEmpty; // does not need a message > > > > > > Sebb > > > > > > - > > > 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
