[Bug 66178] Reduce garbage from strings in AbstractArchiveResourceSet.getResource
https://bz.apache.org/bugzilla/show_bug.cgi?id=66178 Christopher Schultz changed: What|Removed |Added Summary|Garbage from strings in |Reduce garbage from strings |AbstractArchiveResourceSet. |in |getResource |AbstractArchiveResourceSet. ||getResource --- Comment #2 from Christopher Schultz --- Is this patch trying to reduce the use of temporary Strings in the heap? I recently had conversation with someone about string concatenation in Java and it's clear that modern compilers are more efficient when using source-level concatenation instead of programmer-imposed uses of StringBuilder. The code is less clear (to read, and thus less maintainable) when StringBuilder is used and I'm not convinced that this will practically improve anything. I'm a -0 on this for the time being. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat-native] ChristopherSchultz commented on pull request #13: native: Update for libressl 3.5
ChristopherSchultz commented on PR #13: URL: https://github.com/apache/tomcat-native/pull/13#issuecomment-1194779432 > > there would need to be an appropriate Panama module > > What exactly is this? The plan is to migrate to Panama to avoid having to ship libtcnative at all, at which point everything is in Java. Right now, all the glue for the crypto library is in native C code in libtcnative which is potentially dangerous. Moving to Panama allows us to remove all native code that doesn't belong to the crypto library. > There used to be a comparison graph for libressl and openssl security issues showing how many security issues openssl introduced have never affected libressl, but its been years since I seen it and I am not sure where that was. However comparing the number of CVEs for libressl and openssl is a huge difference. I'm going to really need a citation here. Forking a library, removing all the irrelevant code and claiming you have a new product with no security issues isn't really fair from a comparison perspective. If I fork OpenSSL to create ChriSSL tomorrow and just delete all the sources, I guarantee it'll never have any CVEs filed against it. > Arguably more people are submitting them for the latter. Yes, CVEs are typically assigned to a single product. I'd be interested to see how many CVEs from the past few years filed against OpenSSL were also (silently) fixed in LibreSSL who gets a pass for those same issues. > I don't have the qualifications to conclusively argue which one is a better or worse ssl implementation[...] I haven't studied the code, but I know a great deal of effort was put into simply removing code deemed unnecessary by the LibreSSL team. I have no idea how much re-writing of any code they have done since then. My guess is that they are still largely the same (minus the removals, of course). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66178] Garbage from strings in AbstractArchiveResourceSet.getResource
https://bz.apache.org/bugzilla/show_bug.cgi?id=66178 Joe Jackson changed: What|Removed |Added Priority|P2 |P3 OS||All --- Comment #1 from Joe Jackson --- This is most likely happening in the newer versions of tomcat, this just happens to be the one I am using. I believe we are going to 9 soon. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66178] New: Garbage from strings in AbstractArchiveResourceSet.getResource
https://bz.apache.org/bugzilla/show_bug.cgi?id=66178
Bug ID: 66178
Summary: Garbage from strings in
AbstractArchiveResourceSet.getResource
Product: Tomcat 8
Version: 8.5.x-trunk
Hardware: Macintosh
Status: NEW
Severity: normal
Priority: P2
Component: Catalina
Assignee: dev@tomcat.apache.org
Reporter: midnjack...@gmail.com
Target Milestone:
Created attachment 38343
--> https://bz.apache.org/bugzilla/attachment.cgi?id=38343=edit
possible patch to reduce garbage
If you have a large-ish number of jars (something like 1200 in my case) then we
end up calling the getResource method of AbstractArchiveResourceSet for each
jar every time that we load a new resource. This code does a few substrings and
string concatenation that ends up generating a lot of garbage due to the fact
that it's called constantly.
This happens even if the resource is cached because of the code in
Cache.getResource()
If the entry is found in the cache we call it here
if (cacheEntry != null &&
!cacheEntry.validateResource(useClassLoaderResources)) {
Using JFR to capture some profiling data I was able to see that replacing the
string concatenation with a StringBuilder reduced the garbage by about 3x - 4x.
In the original, it created something like 20 mb when loading a page that
serves multiple resources and after the change, it only allocated about 7 mb.
Attached is a git patch showing a possible fix. I'd be happy to make a PR as
well.
--
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat-native] orbea commented on pull request #13: native: Update for libressl 3.5
orbea commented on PR #13: URL: https://github.com/apache/tomcat-native/pull/13#issuecomment-1194648448 > there would need to be an appropriate Panama module What exactly is this? > Really? Mostly what they did was discard old garbage from OpenSSL that may have had bugs lurking in it. Anything which demonstrably improves security should have also been picked-up by OpenSSL. There used to be a comparison graph for libressl and openssl security issues showing how many security issues openssl introduced have never affected libressl, but its been years since I seen it and I am not sure where that was. However comparing the number of CVEs for libressl and openssl is a huge difference. Arguably more people are submitting them for the latter. Also arguably OpenBSD has a reputation for security and being overly cautious maintainers. Other people are welcome to disagree and use what they feel most comfortable with of course. https://www.cvedetails.com/product/30688/Openbsd-Libressl.html?vendor_id=97 https://www.cvedetails.com/product/383/Openssl-Openssl.html?vendor_id=217 I don't have the qualifications to conclusively argue which one is a better or worse ssl implementation, but I entirely agree in avoiding a monoculture. Having more than one C compiler (gcc and clang) has only been a good thing for example. > This is irrelevant, as downstream uses don't worry about build complexity. Build complexity may be a source of other issues, but it's not a good justification for wanting to use one library versus another. As someone involved with maintaining packages for distros I have spent a significant amount of time working on build systems I did not write and this is an very important detail to me personally, but I completely understand that this is not important for most people. Also there are niche cases where the openssl build system is just not adequate for some platforms such as midipix (https://midipix.org/) where I have been told its not easy to fix and that is one of the reasons they use libressl. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat-native] michael-o commented on pull request #13: native: Update for libressl 3.5
michael-o commented on PR #13: URL: https://github.com/apache/tomcat-native/pull/13#issuecomment-1194319846 > > and a significantly better build system. > > This is irrelevant, as downstream uses don't worry about build complexity. Build complexity may be a source of other issues, but it's not a good justification for wanting to use one library versus another. I have built both on many platforms. It was a snap to build OpenSSL even on HP-UX. At runtme, this does not matter. > That being said, **I am a big proponent of LibreSSL support** if for no other reason than than to avoid a monoculture. Unfortunately, OpenSSL vs LibreSSL is a bit like comparing modern MS Edge, Chrome, and Opera and saying they are different browsers when they are significantly identical under the covers. Here I do support @ChristopherSchultz. I want to avoid mono culture as well, but all of them are Chromium in different clothes. From a runtime perspective, what is now better with LibreSSL compared to OpenSSL. @ChristopherSchultz You maybe remember that I have started to improve the LibreSSL intergration, but it requires a lot of a time and I don't use LibreSSL. OpenSSL throughout. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[GitHub] [tomcat-native] ChristopherSchultz commented on pull request #13: native: Update for libressl 3.5
ChristopherSchultz commented on PR #13: URL: https://github.com/apache/tomcat-native/pull/13#issuecomment-1194301634 > My main reasons are that libressl has a better track record with security Really? Mostly what they did was discard old garbage from OpenSSL that may have had bugs lurking in it. Anything which demonstrably improves security should have also been picked-up by OpenSSL. > and a significantly better build system. This is irrelevant, as downstream uses don't worry about build complexity. Build complexity may be a source of other issues, but it's not a good justification for wanting to use one library versus another. That being said, **I am a big proponent of LibreSSL support** if for no other reason than than to avoid a monoculture. Unfortunately, OpenSSL vs LibreSSL is a bit like comparing modern MS Edge, Chrome, and Opera and saying they are different browsers when they are significantly identical under the covers. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66175] Consider changing BasicAuthenticator to default to charset="UTF"
https://bz.apache.org/bugzilla/show_bug.cgi?id=66175 Christopher Schultz changed: What|Removed |Added OS||All --- Comment #1 from Christopher Schultz --- With our recent changes to switch everything to default to UTF-8, I think this makes sense. I'm not sure which version of Tomcat first switched all the defaults. 10? Or was it back to 9? I'm fairly sure 8.5 still has ISO-8859-1 as default for everything to match the HTTP specs. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 66174] Pound sign £ in passwords does not work with LDAP realm
https://bz.apache.org/bugzilla/show_bug.cgi?id=66174 --- Comment #3 from Christopher Schultz --- (In reply to Konstantin Kolinko from comment #2) >charset="UTF-8" /> > > [...] > > I wonder whether better documentation may be needed somewhere. I think this should be added to the FAQ "How do I just use UTF-8 everywhere" because I'm sure it's not in there, and it's an important edge-case. -- You are receiving this mail because: You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
JDK 19: Rampdown Phase 2 + JavaOne
Greetings! JDK 19 is now in Rampdown Phase Two [1]. The overall feature set is frozen. Per the JDK Release Process [2] we now turn our focus to P1 and P2 bugs, which can be fixed with approval [3]. Late enhancements are still possible, with approval, but the bar is now extraordinarily high [4]. Given the current state of affairs, it is a good time to start testing your project(s) on JDK 20 Early-Access builds. To conclude, please make sure to check the heads-up below, including the one covering JavaOne! [1] https://mail.openjdk.org/pipermail/jdk-dev/2022-July/006803.html [2] https://openjdk.org/jeps/3 [3] https://openjdk.org/jeps/3#Fix-Request-Process [4] https://openjdk.org/jeps/3#Late-Enhancement-Request-Process ## Heads-up - JavaOne is back! After a long hiatus, JavaOne is back! From October 17-20 in Las Vegas, JavaOne will be jam-packed with hundreds of valuable and actionable sessions directly from the experts: learning sessions, tutorials, hands-on labs, lightning talks, panels, an unconference, BoF's, etc. The full JavaOne content catalog will be released soon. In the meantime, make sure to check https://inside.java/javaone/ for more updates. And if you are planning to attend JavaOne, please ping me. I'd like to meet you in person to chat over OpenJDK and the Quality Outreach program. And the drinks will be on me! ## Heads-up - JavaFX Media enhancements survey The JavaFX team is conducting a short survey [5] to gather input on potential JavaFX Media enhancements. The process is quite simple as the feedback will be collected via the openjfx-dev [6] mailing list. So if you are using JavaFX, make sure to raise your voice. [5] https://mail.openjdk.org/pipermail/openjfx-dev/2022-July/034949.html [6] https://mail.openjdk.org/mailman/listinfo/openjfx-dev ## JDK 19 JDK 19 Early-Access builds 32 are now available [7], and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [8]. [7] https://jdk.java.net/19/ [8] https://jdk.java.net/19/release-notes ### JEPs integrated to JDK 19: - JEP 405: Record Patterns (Preview) - JEP 422: Linux/RISC-V Port - JEP 424: Foreign Function & Memory API (Preview) - JEP 425: Virtual Threads (Preview) - JEP 426: Vector API (4th Incubator) - JEP 427: Pattern Matching for switch (3rd Preview) - JEP 428: Structured Concurrency (Incubator) ### Recent changes that maybe of interest: - JDK-8289127: Apache Lucene triggers: DEBUG MESSAGE: duplicated predicate failed which is impossible - JDK-8290596: Update java.net.InetAddress to Detect Ambiguous IPv4 Address Literals - JDK-8290615: Remove the Alternate ThreadLocal Implementation of the Subject::current and Subject::callAs APIs - JDK-8290417: CDS cannot archive lamda proxy with useImplMethodHandle - JDK-8287809: Revisit implementation of memory session - JDK-8289278: Suspend/ResumeAllVirtualThreads need both can_suspend and can_support_virtual_threads - JDK-8288589: Files.readString ignores encoding errors for UTF-16 - JDK-8288425: Footprint regression due MH creation when initializing StringConcatFactory ## JDK 20 JDK 20 Early-Access builds 7 are now available [9], and are provided under the GNU General Public License v2, with the Classpath Exception. [9] https://jdk.java.net/20/ ### Recent changes that maybe of interest: - JDK-8264999: GeneralPath.lineTo() to itself produces jagged lines [Logged by Apache PDFBox] - JDK-8284997: arm32 build crashes since JDK-8283326 [Logged by JaCoCo] - JDK-8286101: Support formatting in @value tag - JDK-8289260: BigDecimal movePointLeft() and movePointRight() do not follow their API spec - JDK-8287835: Add support for additional float/double to integral conversion for x86 - JDK-8283091: Support type conversion between different data sizes in SLP - JDK-8288573: Make Executable.getParameterCount() actually abstract - JDK-8266670: Better modeling of access flags in core reflection - JDK-8290601: Update java.net.InetAddress to Detect Ambiguous IPv4 Address Literals - JDK-8290334: Update FreeType to 2.12.1 - JDK-8286030: Avoid JVM crash when containers share the same /tmp dir - JDK-8289743: AArch64: Clean up patching logic - JDK-8288107: Auto-vectorization for integer min/max - JDK-8274235: -Xshare:dump should not call vm_direct_exit ## Topics of Interest: * What is OpenJDK? - Inside Java Newscast https://inside.java/2022/06/30/insidejava-newscast-028/ * “Towards Generational ZGC!” - Inside Java Podcast https://inside.java/2022/06/29/podcast-024/ * HotSpot Deep Dive - Safepoint https://inside.java/2022/07/12/hotspot-deep-dive-safepoint/ * Introduction to Project Panama - Part 2: Variadic Functions https://inside.java/2022/06/27/introduction-to-project-panama-part-2/ * Data-Oriented Programming - Inside Java Newscast https://inside.java/2022/07/14/insidejava-newscast-029/ * Launching 10 millions virtual threads with Loom - JEP Café
Re: [VOTE] Release Apache Tomcat 10.0.23
On 14/07/2022 11:25, Mark Thomas wrote: [X] Stable - go ahead and release as 10.0.23 (stable) Tested on fedora36 -- Cheers Jean-Frederic - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
