[logback-dev] [JIRA] (LOGBACK-1406) Seems all threads blocked
Title: Message Title Joshua Carter commented on LOGBACK-1406 Re: Seems all threads blocked @Alvin, my solution was to merely stop logging so much stuff Luckily for me, there was a significant amount of non-useful DEBUG logging coming from a single class that I simply changed to INFO in my config. Also, I suspect this is related to logging coming from a large number of separate threads concurrently (this was my test case at least), so if there is no way to reduce the amount of logging, perhaps there is some way of reducing the number of concurrent threads. Add Comment This message was sent by Atlassian JIRA (v7.3.1#73012-sha1:68837e3) ___ logback-dev mailing list logback-dev@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-dev
[logback-dev] [JIRA] (LOGBACK-1406) Seems all threads blocked
Title: Message Title Alvin commented on LOGBACK-1406 Re: Seems all threads blocked I just curious if this blocker issue was already resolved or is there any walk-around available to avoid this. Since it is identified as a blocker and had opened for more than a year, i wonder how other managed to get around it! I have similar issue encountered by Joshua and it can happen few times a day as our load is extreme high. Any help will be appreciated. Below is what the thread is waiting for: java.lang.Thread.State: WAITING (parking) at jdk.internal.misc.Unsafe.park(java.base@11.0.5/Native Method) - parking to wait for <0x7f739e995d50> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) at java.util.concurrent.locks.LockSupport.park(java.base@11.0.5/LockSupport.java:194) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.5/AbstractQueuedSynchronizer.java:885) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(java.base@11.0.5/AbstractQueuedSynchronizer.java:917) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base@11.0.5/AbstractQueuedSynchronizer.java:1240) at java.util.concurrent.locks.ReentrantLock.lock(java.base@11.0.5/ReentrantLock.java:267) at ch.qos.logback.core.OutputStreamAppender.writeBytes(OutputStreamAppender.java:197) at ch.qos.logback.core.OutputStreamAppender.subAppend(OutputStreamAppender.java:231) at ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:102) at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:84) at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:51) at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270) at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:421) at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:383) at ch.qos.logback.classic.Logger.debug(Logger.java:482) Add Comment
[logback-dev] [JIRA] (LOGBACK-1508) Dependency check-framework @NotNull conflict with validation-api
seliote created LOGBACK-1508: Summary: Dependency check-framework @NotNull conflict with validation-api Key: LOGBACK-1508 URL: https://jira.qos.ch/browse/LOGBACK-1508 Project: logback Issue Type: Bug Components: logback-classic Affects Versions: 1.3.0-alpha5 Environment: - Maven - Java 8 - SpringMVC Reporter: seliote Assignee: Logback dev list Attachments: IMG_2309.PNG, IMG_2310.PNG Logback import `edu.washington.cs.types.checker` - `checker-framework.1.7.0` but it conflict with `javax.validation` - `validation-api.2.0.1.Final`, when Logback is runtime scope it will pass compile, but it will make error when @NotNull trigger, such as `NotNull defines no attribute 'groups'.` -- This message was sent by Atlassian JIRA (v7.3.1#73012) ___ logback-dev mailing list logback-dev@qos.ch http://mailman.qos.ch/mailman/listinfo/logback-dev
