From bf98fa22e98612ab36583a31d4ea29b1afc53a1f Mon Sep 17 00:00:00 2001 From: Sean Policarpio Date: Fri, 30 Jun 2017 16:06:28 +1000 Subject: [PATCH] updating README + CHANGELOG --- CHANGELOG.md | 9 +++++++++ README.md | 24 +----------------------- 2 files changed, 10 insertions(+), 23 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 792e018..928d64c 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,14 @@ # Changelog +## 1.1.0 +## Fixed +- provides fix for dead-lock caused by unseen synchronized block caused by ch.qos.logback.core.AppenderBase +- the fix for the dead-lock is addressed by removing the use of blocking queue for logging events. As a result, this also removed the need for SplunkHecAppenderStrategy's +## Changed +- additionally, added Monix circuit breakers around consuming the log event stream and pushing data to Splunk via HTTP +- updated Monix to 2.3.0 +- cross compiling to Scala 2.11.11 and 2.12.2 + ## 1.0.3 - Updated dependencies to latest versions. diff --git a/README.md b/README.md index 4c0fe51..dea0afc 100644 --- a/README.md +++ b/README.md @@ -11,7 +11,7 @@ It is implemented using the principles of reactive streams. This was very straig ## Compatability - due to the use of the Skinny Framework's HTTP client, the minimum **Java** version is **8**. However, I haven't tested the appender in a Java project yet. Technically, it should be compatible, but please let me know if it definitely works. -- I have tested the appender against an Enterprise Splunk Cloud HTTP Event Collector (*version 6.6.1*). +- I have tested the appender against the Enterprise Splunk Cloud HTTP Event Collector (*version 6.6.1*). ## Configuration ### Sample XML Configuration @@ -55,9 +55,6 @@ It is implemented using the principles of reactive streams. This was very straig - `` - The token that authorizes posting to the HEC endpoint - e.g. _1234-5678-91011-ABC-321_ -- `` - - A maximum queue size for log messages to be stored in memory. If this fills up and log messages are not posted to Splunk in a timely manner, then the queue will by default cause blocking to occur on subsequent appends (see [alternatives](#splunkhecappenderstrategy) to this below). - - 1000 *(default)* - `` - Log messages are buffered in memory off of the queue. Once a buffer is filled, logs are instantly posted to the HEC endpoint. This size also signifies the maximum payload size sent to the endpoint. - 25 *(default)* @@ -119,25 +116,6 @@ package object json { ####Custom Layout You can override the layout with a class extending either `SplunkHecJsonLayout`,`SplunkHecJsonLayoutBase`, or `LayoutBase[ILoggingEvent]`. Then `` can be specified in the `` section — see the XML example above - -###SplunkHecAppenderStrategy - -By default, `SplunkHecAppender` will use the calling thread (i.e. a thread from your application) when queueing new log messages on to the internal queue. If that queue happens to be full, possibly because the Splunk HEC API requests are taking too long, then blocking can take more time. This default behaviour is defined by the _appender strategy_ `BlockingSplunkHecAppenderStrategy`. There exists two more strategies: - -- `AsyncSplunkHecAppenderStrategy` - - This strategy uses an internal executor service (a `ForkJoinPool`) to asynchronously enqueue new log events. If the queue is full, your applications thread won't block. However, this means that background queue tasks could pile up if the queue is not drained fast enough (again, usually due to slowness with HTTP requests to the Splunk HEC). By default, the executor services parallelism factor is equal to the number of CPU cores available to the VM. This can be overridden with the `parallelism` setting. -```xml - - - 8 - -``` -- `SpillingSplunkHecAppenderStrategy` - - This strategy simply drops logging events when the internal queue has been filled up. Logging events will resume to be streamed to the Splunk HEC once the queue has the capacity again. However, due to the concurrent nature of the internal queue, the capacity check performed can't be guaranteed, so edge cases of the queues capacity can cause some blocking of your applications calling thread. -```xml - - -``` ## HTTP Client The base implementation uses the [skinny-framework's HTTP client](https://github.com/skinny-framework/skinny-framework). It is a tiny library and does not bring with it many dependencies. `SplunkHecAppender` uses `SkinnyHttpHecClient` for HTTP communication.