@@ -338,48 +338,6 @@ JsonTemplateLayout:
338
338
}
339
339
----
340
340
341
- [#recycling-strategy]
342
- === Recycling strategy
343
-
344
- `RecyclerFactory` plays a crucial role for determining the memory footprint of
345
- the layout. Template resolvers employ it to create recyclers for objects that
346
- they can reuse. The behavior of each `RecyclerFactory` and when one should
347
- prefer one over another is explained below:
348
-
349
- * `dummy` performs no recycling, hence each recycling attempt will result in a
350
- new instance. This will obviously create a load on the garbage-collector. It
351
- is a good choice for applications with low and medium log rate.
352
-
353
- * `threadLocal` performs the best, since every instance is stored in
354
- ``ThreadLocal``s and accessed without any synchronization cost. Though this
355
- might not be a desirable option for applications running with hundreds of
356
- threads or more, e.g., a web servlet.
357
-
358
- * `queue` is the best of both worlds. It allows recycling of objects up to a
359
- certain number (`capacity`). When this limit is exceeded due to excessive
360
- concurrent load (e.g., `capacity` is 50 but there are 51 threads concurrently
361
- trying to log), it starts allocating. `queue` is a good strategy where
362
- `threadLocal` is not desirable.
363
- +
364
- `queue` also accepts optional `supplier` (of type `java.util.Queue`, defaults to
365
- `org.jctools.queues.MpmcArrayQueue.new` if JCTools is in the classpath;
366
- otherwise `java.util.concurrent.ArrayBlockingQueue.new`) and `capacity` (of
367
- type `int`, defaults to `max(8,2*cpuCount+1)`) parameters:
368
- +
369
- .Example configurations of `queue` recycling strategy
370
- [source]
371
- ----
372
- queue:supplier=org.jctools.queues.MpmcArrayQueue.new
373
- queue:capacity=10
374
- queue:supplier=java.util.concurrent.ArrayBlockingQueue.new,capacity=50
375
- ----
376
-
377
- The default `RecyclerFactory` is `threadLocal`, if
378
- `log4j2.enable.threadlocals=true`; otherwise, `queue`.
379
-
380
- See <<extending-recycler>> for details on how to introduce custom
381
- `RecyclerFactory` implementations.
382
-
383
341
[#template-config]
384
342
== Template Configuration
385
343
@@ -1082,8 +1040,7 @@ Resolves `logEvent.getMessage().getParameters()`.
1082
1040
====
1083
1041
Regarding garbage footprint, `stringified` flag translates to
1084
1042
`String.valueOf(value)`, hence mind not-`String`-typed values. Further,
1085
- `logEvent.getMessage()` is expected to implement `ParameterVisitable` interface,
1086
- which is the case if `log4j2.enableThreadLocals` property set to true.
1043
+ `logEvent.getMessage()` is expected to implement `ParameterVisitable` interface.
1087
1044
====
1088
1045
1089
1046
====== Examples
@@ -1590,7 +1547,6 @@ plugins:
1590
1547
1591
1548
* Event template resolvers (e.g., `exception`, `message`, `level` event template resolvers)
1592
1549
* Event template interceptors (e.g., injection of `eventTemplateAdditionalField`)
1593
- * Recycler factories
1594
1550
1595
1551
Following sections cover these in detail.
1596
1552
@@ -1829,44 +1785,6 @@ provided an `eventTemplateRootObjectKey`. If so, it wraps the root `node` with a
1829
1785
new object; otherwise, returns the `node` as is. Note that `node` refers to the
1830
1786
root Java object of the event template read by `JsonReader`.
1831
1787
1832
- [#extending-recycler]
1833
- === Extending Recycler Factories
1834
-
1835
- `recyclerFactory` input `String` read from the layout configuration is converted
1836
- to a `RecyclerFactory` using the default `RecyclerFactoryConverter` extending
1837
- from `TypeConverter<RecyclerFactory>`. If one wants to change this behavior,
1838
- they simply need to add their own `TypeConverter<RecyclerFactory>` implementing
1839
- `Comparable<TypeConverter<?>>` to prioritize their custom converter.
1840
-
1841
- [source,java]
1842
- .Custom `TypeConverter` for `RecyclerFactory`
1843
- ----
1844
- package com.acme.logging.log4j.layout.template.json;
1845
-
1846
- import org.apache.logging.log4j.plugins.Plugin;
1847
- import org.apache.logging.log4j.plugins.convert.TypeConverter;
1848
-
1849
- @Category(TypeConverter.CATEGORY)
1850
- @Plugin("AcmeRecyclerFactoryConverter")
1851
- public final class AcmeRecyclerFactoryConverter
1852
- implements TypeConverter<RecyclerFactory>, Comparable<TypeConverter<?>> {
1853
-
1854
- @Override
1855
- public RecyclerFactory convert(final String recyclerFactorySpec) {
1856
- return AcmeRecyclerFactory.ofSpec(recyclerFactorySpec);
1857
- }
1858
-
1859
- @Override
1860
- public int compareTo(final TypeConverter<?> ignored) {
1861
- return -1;
1862
- }
1863
-
1864
- }
1865
- ----
1866
-
1867
- Here note that `compareTo()` always returns -1 to rank it higher compared to
1868
- other matching converters.
1869
-
1870
1788
[#features]
1871
1789
== Features
1872
1790
@@ -1966,7 +1884,7 @@ Yes, if the garbage-free layout behaviour toggling properties
1966
1884
`log4j2.enableDirectEncoders` and `log4j2.garbagefreeThreadContextMap` are
1967
1885
enabled. Take into account the following caveats:
1968
1886
1969
- * The configured link:# recycling-strategy[recycling strategy] might not be
1887
+ * The configured recycling strategy might not be
1970
1888
garbage-free.
1971
1889
1972
1890
* Since `Throwable#getStackTrace()` clones the original `StackTraceElement[]`,
0 commit comments