Hi Sonya, You're right, it doesn't look like queueSize or discardingThreshold are documented in the configuration reference in 0.8.4 :/
It does look like they're documented in the javadoc[0] and available in the source[1] for 0.8.4 in case those help to get you started. They also seem to match up with what's in the 1.0 configuration reference, so it's probably safe to use that as a guide too. The default queue size of 256 seems to be the same in both versions as well. -Dimas [0] http://www.dropwizard.io/0.8.4/dropwizard-logging/apidocs/io/dropwizard/logging/AbstractAppenderFactory.html [1] https://github.com/dropwizard/dropwizard/blob/v0.8.4/dropwizard-logging/src/main/java/io/dropwizard/logging/AbstractAppenderFactory.java On Thursday, April 20, 2017 at 9:59:43 AM UTC-4, [email protected] wrote: > > Hi Artem, > > Actually the yml provided in my previous reply was for DW6. > The correct DW8 yml is pasted below. I also don't see queueSize and > discardingThreshold as configuration options in DW0.8.4 the version we're > trying to upgrade to. But I see they're available in DW 1.0 > > server: > applicationConnectors: > - type: http > port: 8080 > adminConnectors: > - type: http > port: 8081 > requestLog: > appenders: > - type: file > timeZone: UTC > logFormat: null > currentLogFilename: /var/log/rtr/dfs/requests.log > archive: true > archivedLogFilenamePattern: > /var/log/rtr/dfs/archived/requests-%d.log.gz > archivedFileCount: 5 > > logging: > appenders: > - type: file > threshold: INFO > currentLogFilename: /var/log/rtr/dfs/dfs.log > archivedLogFilenamePattern: /var/log/rtr/dfs/dfs-%d.log.gz > archivedFileCount: 5 > timeZone: UTC > > > On Tuesday, April 18, 2017 at 4:57:02 PM UTC-4, [email protected] > wrote: >> >> Hi Dropwizard Users, >> >> We recently upgraded one of our query services to Dropwizard 0.8.4. >> Previously we were on Dropwizard6. >> With an increased load on the service, the # of waiting threads continued >> to increase beyond the set default limit of 1024. Eventually our >> application tipped over and resulted in a *java.lang.OutOfMemoryError: >> unable to create new native thread*. This was expected as the dw-* >> thread count was increasing when I checked via curl *http://localhost >> <http://localhost>:<admin port>/threads *and the number of dw-* threads >> and WAITING threads increased. >> >> I have shared the thread dumps below.. >> >> 1. https://drive.google.com/open?id=0B2IzsO0HbvslYzhBT3RvUG5WOWc >> >> 2. https://drive.google.com/open?id=0B2IzsO0HbvslODVlNUFweGpsREk >> >> It seems like quite a few threads are waiting on the log.info statement >> and we suspect it could be the culprit here. >> >> at ch.qos.logback.classic.Logger.info(Logger.java:608) >> >> >> Has anyone else come across this issue with an upgrade? It looks http >> request specific (and not really database related) Any insights or tips >> would greatly help us as we continue to investigate the issue. >> Another observation - don't see any 500 http error codes in the stage >> requests.log. In the QA environment, we do see many 500s as expected for >> bad requests. >> >> Thanks >> Sonya >> > -- You received this message because you are subscribed to the Google Groups "dropwizard-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
