Race condition in slf4j-simple
Hi Ceki, We have observed a strange behavior of the logger slf4j-simple when two or more parallel Maven modules log the exceptions and the messages. It produces corrupted lines in the log and they are partially mixed with other lines. The lines look like this and they are obviously not expected in the log. [ERROR] R] *.util.json.formatter.JsonFormatterTest [ERROR] Process Exit Code: 0 [ERROR] *.util.json.formatter.JsonFormatterTest After our analysis we found the place in SLF4J code which seems to be the root cause. The method [1] is a critical section and must be synchronized with a singleton lock which avoids reordering of the nested method calls across multiple Threads. Without it, the normal messages and stack trace may mix especially if two parallel Maven modules print the stacktrace. [1]: https://github.com/qos-ch/slf4j/blob/39e3b81e5ea69c6610c8d5fd57fd974e090d9fc1/slf4j-simple/src/main/java/org/slf4j/simple/SimpleLogger.java#L243 Pls analyse the class SimpleLogger.java and answer with your opinion about this issue and a proposal with the fix. If there are more other critical sections which need to have some concurrency treatments, we can talk about it in this mailing list. -- Cheers Tibor
Re: I can cannot execute my SolrJ application
mh, ok, that's a nice report, and now please tell us what you are aiming for? Can you extract it to a reproducible project at Github? cheers Tibor17 On Fri, Oct 23, 2020 at 12:50 PM Raivo Rebane wrote: > > > > Forwarded Message > Subject:I can cannot execute my SolrJ application > Date: Wed, 21 Oct 2020 09:55:01 +0300 > From: Raivo Rebane > To: users@maven.apache.org > > > > Hello > > I can compile my project properliy; > > But problems arise when I execute it: > > Apache Maven 3.6.3 (cecedd343002696d0abb50b32b541b8a6ba2883f) > Maven home: /home/hydra/workspace1/test/EMBEDDED > Java version: 11.0.8, vendor: Ubuntu, runtime: > /usr/lib/jvm/java-11-openjdk-amd64 > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "5.4.0-51-generic", arch: "amd64", family: > "unix" > [DEBUG] Created new class realm maven.api > [DEBUG] Importing foreign packages into class realm maven.api > [DEBUG] Imported: javax.annotation.* < plexus.core > [DEBUG] Imported: javax.annotation.security.* < plexus.core > [DEBUG] Imported: javax.enterprise.inject.* < plexus.core > [DEBUG] Imported: javax.enterprise.util.* < plexus.core > [DEBUG] Imported: javax.inject.* < plexus.core > [DEBUG] Imported: org.apache.maven.* < plexus.core > [DEBUG] Imported: org.apache.maven.artifact < plexus.core > [DEBUG] Imported: org.apache.maven.classrealm < plexus.core > [DEBUG] Imported: org.apache.maven.cli < plexus.core > [DEBUG] Imported: org.apache.maven.configuration < plexus.core > [DEBUG] Imported: org.apache.maven.exception < plexus.core > [DEBUG] Imported: org.apache.maven.execution < plexus.core > [DEBUG] Imported: org.apache.maven.execution.scope < plexus.core > [DEBUG] Imported: org.apache.maven.lifecycle < plexus.core > [DEBUG] Imported: org.apache.maven.model < plexus.core > [DEBUG] Imported: org.apache.maven.monitor < plexus.core > [DEBUG] Imported: org.apache.maven.plugin < plexus.core > [DEBUG] Imported: org.apache.maven.profiles < plexus.core > [DEBUG] Imported: org.apache.maven.project < plexus.core > [DEBUG] Imported: org.apache.maven.reporting < plexus.core > [DEBUG] Imported: org.apache.maven.repository < plexus.core > [DEBUG] Imported: org.apache.maven.rtinfo < plexus.core > [DEBUG] Imported: org.apache.maven.settings < plexus.core > [DEBUG] Imported: org.apache.maven.toolchain < plexus.core > [DEBUG] Imported: org.apache.maven.usability < plexus.core > [DEBUG] Imported: org.apache.maven.wagon.* < plexus.core > [DEBUG] Imported: org.apache.maven.wagon.authentication < plexus.core > [DEBUG] Imported: org.apache.maven.wagon.authorization < plexus.core > [DEBUG] Imported: org.apache.maven.wagon.events < plexus.core > [DEBUG] Imported: org.apache.maven.wagon.observers < plexus.core > [DEBUG] Imported: org.apache.maven.wagon.proxy < plexus.core > [DEBUG] Imported: org.apache.maven.wagon.repository < plexus.core > [DEBUG] Imported: org.apache.maven.wagon.resource < plexus.core > [DEBUG] Imported: org.codehaus.classworlds < plexus.core > [DEBUG] Imported: org.codehaus.plexus.* < plexus.core > [DEBUG] Imported: org.codehaus.plexus.classworlds < plexus.core > [DEBUG] Imported: org.codehaus.plexus.component < plexus.core > [DEBUG] Imported: org.codehaus.plexus.configuration < plexus.core > [DEBUG] Imported: org.codehaus.plexus.container < plexus.core > [DEBUG] Imported: org.codehaus.plexus.context < plexus.core > [DEBUG] Imported: org.codehaus.plexus.lifecycle < plexus.core > [DEBUG] Imported: org.codehaus.plexus.logging < plexus.core > [DEBUG] Imported: org.codehaus.plexus.personality < plexus.core > [DEBUG] Imported: org.codehaus.plexus.util.xml.Xpp3Dom < plexus.core > [DEBUG] Imported: org.codehaus.plexus.util.xml.pull.XmlPullParser < > plexus.core > [DEBUG] Imported: > org.codehaus.plexus.util.xml.pull.XmlPullParserException < plexus.core > [DEBUG] Imported: org.codehaus.plexus.util.xml.pull.XmlSerializer < > plexus.core > [DEBUG] Imported: org.eclipse.aether.* < plexus.core > [DEBUG] Imported: org.eclipse.aether.artifact < plexus.core > [DEBUG] Imported: org.eclipse.aether.collection < plexus.core > [DEBUG] Imported: org.eclipse.aether.deployment < plexus.core > [DEBUG] Imported: org.eclipse.aether.graph < plexus.core > [DEBUG] Imported: org.eclipse.aether.impl < plexus.core > [DEBUG] Imported: org.eclipse.aether.installation < plexus.core > [DEBUG] Imported: org.eclipse.aether.internal.impl < plexus.core > [DEBUG] Imported: org.eclipse.aether.metadata < plexus.core > [DEBUG] Imported: org.eclipse.aether.repository < plexus.core > [DEBUG] Imported: org.eclipse.aether.resolution < plexus.core > [DEBUG] Imported: org.eclipse.aether.spi < plexus.core > [DEBUG] Imported: org.eclipse.aether.transfer < plexus.core > [DEBUG] Imported: org.eclipse.aether.version < plexus.core > [DEBUG] Imported: org.fusesource.jansi.* < plexus.core > [DEBUG] Imported:
Re: 'mvn clean test' crashes
Hi Mukul, the problem with System.exit() can be in a library - dependency,
not only in your code and therefore the system manager has to be configured
in system property in order to find and confirm the hypothesis. T
Dňa pi 9. 10. 2020, 18:01 Enrico Olivelli napísal(a):
> Something like this:
>
> public class NoExitSecurityManager extends SecurityManager {
>
> private final SecurityManager wrapped;
>
> public static void setup() {
> Policy.setPolicy(new Policy() {
>
> final Permissions pc = new Permissions();
>
> {
> pc.add(new AllPermission());
> }
>
> @Override
> public boolean implies(ProtectionDomain domain, Permission
> permission) {
> return true;
> }
>
> @Override
> public PermissionCollection getPermissions(ProtectionDomain
> domain) {
> return pc;
> }
>
> @Override
> public PermissionCollection getPermissions(CodeSource
> codesource) {
> return pc;
> }
>
> });
> System.setSecurityManager(new NoExitSecurityManager());
> }
>
> public NoExitSecurityManager() {
> wrapped = new SecurityManager();
> }
>
> public NoExitSecurityManager(SecurityManager wrapped) {
> this.wrapped = wrapped;
> }
>
> @Override
> public void checkExit(int status) {
> StackTraceElement[] stackTrace =
> Thread.currentThread().getStackTrace();
> if (stackTrace != null) {
> for (StackTraceElement el : stackTrace) {
> String className = el.getClassName();
> if (className != null
> &&
> className.startsWith("org.apache.maven.surefire.booter.ForkedBooter")
> && ("acknowledgedExit".equals(el.getMethodName())
> || "exit".equals(el.getMethodName( {
> return;
> }
> }
> }
> throw new SecurityException("System.exit is disabled on unit
> tests");
>
> }
>
> @Override
> public void checkPermission(Permission perm) {
> if (wrapped == null) {
> return;
> }
> if (perm instanceof FilePermission) {
> // preveniamo errori su Jenkins
> return;
> }
> if (perm instanceof ReflectPermission) {
> return;
> }
> wrapped.checkPermission(perm);
> }
>
> }
>
> Il giorno ven 9 ott 2020 alle ore 09:19 Mukul Gandhi <
> gandhi.mu...@gmail.com>
> ha scritto:
>
> > On Wed, Oct 7, 2020 at 9:09 PM Enrico Olivelli
> > wrote:
> >
> > > A good approach to workaround the presence of third party libraries
> that
> > > call System.exit is to set a SecurityManager that prevents calls to
> > > System.exit.
> >
> >
> > I'll find it helpful, if you may share any code sample how to do this?
> >
> >
> >
> > --
> > Regards,
> > Mukul Gandhi
> >
>
Re: Surefire 3.0.0-M4 not failing build on errors
yes, the reproducible project would be great to have. Thx On Sat, Jun 13, 2020 at 4:04 PM Jeff Jensen wrote: > Thank you Enrico and Tibor for verifying it is a probable new issue. > > I cannot upload this project (customer product/private repo) but will make > a project that reproduces it and reply again. > > > On Sat, Jun 13, 2020 at 8:24 AM Enrico Olivelli > wrote: > > > Il Sab 13 Giu 2020, 15:07 Jeff Jensen ha scritto: > > > > > Hi Enrico, > > > Thanks for the reply. > > > > > > Surefire 2.22.2 correctly fails the build. This is with Java 8 and > JUnit > > > 5. > > > > > > > > > This sounds interesting. > > > > It looks like a big bug to me and it is worth a JIRA > > > > It would help a lot if you could attach a simple reproducer for the > > problem. > > If you know surefire codebase it would also help a lot to create the > > reproducer as an integration test > > > > Thanks > > > > Enrico > > > > > > > > > > On Sat, Jun 13, 2020 at 12:41 AM Enrico Olivelli > > > wrote: > > > > > > > Jeff > > > > > > > > Il Sab 13 Giu 2020, 00:15 Jeff Jensen < > > jeffjen...@upstairstechnology.com > > > > > > > > ha scritto: > > > > > > > > > I looked for this issue in JIRA but haven't found anything yet. > > Anyone > > > > > know if this has been reported and/or fixed? > > > > > > > > > > Our scenario is a failure occurs at startup of tests but Surefire > > > doesn't > > > > > fail the build. Specifically, Spring controller tests aren't > failing > > > > when > > > > > there is a Spring configuration problem. > > > > > > > > > > Spring top-level thrown exception is: > > > > > java.lang.IllegalStateException: Failed to load > ApplicationContext > > > > > > > > > > but Surefire doesn't report fail. Surefire output results is: > > > > > Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, > > > > > > > > > > Running the tests in an IDE correctly fail for the setup problem. > > > > > > > > > > > > > Which IDE? > > > > > > > > Did you try other versions of surefire? Like the latest from 2.x > > release > > > > line? > > > > > > > > Regards > > > > Enrico > > > > > > > > > > -- Cheers Tibor
Re: Failsafe: Killing self fork JVM. PING timeout elapsed.
Alonso Isidoro Roman, why you are telling me " unsubscribe", hm? On Sat, Feb 23, 2019 at 2:07 PM Alonso Isidoro Roman wrote: > unsubscribe > > El sáb., 23 feb. 2019 a las 13:36, Tibor Digana () > escribió: > > > Hi Jason, > > > > We spoke about this issue on our chat in ASF Slack: > > "I think his tests have been paused for a long GC periods and timed out > 3x > > PING period = 30 seconds. After this period forked JVM supposed the Maven > > process was killed by JenkinsCI and therefore all surefire processes are > > killed as well and all the file handlers and memory consumptions are > > freed." > > > > "But I have to say that `-Xmx3g` may cause long GC cycles, see > > > > > https://maven.apache.org/surefire/maven-surefire-plugin/examples/shutdown.html > > " > > > > You are using java-1.8-openjdk. I guess you should use Shenandoah GC > which > > is an experimental algorithm in JVM 1.8. This would significantly short > > the GC cycles. > > > > We should of cource provide a new configuration parameter to give you a > > chance to prolong the PING. > > > > Cheers > > Tibor > > > > > -- > Alonso Isidoro Roman > [image: https://]about.me/alonso.isidoro.roman > < > https://about.me/alonso.isidoro.roman?promo=email_sig_source=email_sig_medium=email_sig_campaign=external_links > > > -- Cheers Tibor
