You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tomee.apache.org by jl...@apache.org on 2018/12/06 08:53:08 UTC
[23/44] tomee git commit: TOMEE-2316 Convert Markdown files to
Asciidoc in the docs folder - 10
http://git-wip-us.apache.org/repos/asf/tomee/blob/de7099c5/docs/statelesscontainer-config.adoc
----------------------------------------------------------------------
diff --git a/docs/statelesscontainer-config.adoc b/docs/statelesscontainer-config.adoc
new file mode 100644
index 0000000..a923fa1
--- /dev/null
+++ b/docs/statelesscontainer-config.adoc
@@ -0,0 +1,441 @@
+# StatelessContainer Configuration
+:index-group: Unrevised
+:jbake-date: 2018-12-05
+:jbake-type: page
+:jbake-status: published
+
+
+A StatelessContainer can be declared via xml in the
+`<tomee-home>/conf/tomee.xml` file or in a `WEB-INF/resources.xml` file
+using a declaration like the following. All properties in the element
+body are optional.
+
+....
+<Container id="myStatelessContainer" type="STATELESS">
+ accessTimeout = 30 seconds
+ callbackThreads = 5
+ closeTimeout = 5 minutes
+ garbageCollection = false
+ idleTimeout = 0 minutes
+ maxAge = 0 hours
+ maxAgeOffset = -1
+ maxSize = 10
+ minSize = 0
+ replaceAged = true
+ replaceFlushed = false
+ strictPooling = true
+ sweepInterval = 5 minutes
+</Container>
+....
+
+Alternatively, a StatelessContainer can be declared via properties in
+the `<tomee-home>/conf/system.properties` file or via Java
+VirtualMachine `-D` properties. The properties can also be used when
+embedding TomEE via the `javax.ejb.embeddable.EJBContainer` API or
+`InitialContext`
+
+....
+myStatelessContainer = new://Container?type=STATELESS
+myStatelessContainer.accessTimeout = 30 seconds
+myStatelessContainer.callbackThreads = 5
+myStatelessContainer.closeTimeout = 5 minutes
+myStatelessContainer.garbageCollection = false
+myStatelessContainer.idleTimeout = 0 minutes
+myStatelessContainer.maxAge = 0 hours
+myStatelessContainer.maxAgeOffset = -1
+myStatelessContainer.maxSize = 10
+myStatelessContainer.minSize = 0
+myStatelessContainer.replaceAged = true
+myStatelessContainer.replaceFlushed = false
+myStatelessContainer.strictPooling = true
+myStatelessContainer.sweepInterval = 5 minutes
+....
+
+Properties and xml can be mixed. Properties will override the xml
+allowing for easy configuration change without the need for $\{} style
+variable substitution. Properties are not case sensitive. If a property
+is specified that is not supported by the declared StatelessContainer a
+warning will be logged. If a StatelessContainer is needed by the
+application and one is not declared, TomEE will create one dynamically
+using default settings. Multiple StatelessContainer declarations are
+allowed. # Supported Properties
+
+Property
+
+Type
+
+Default
+
+Description
+
+accessTimeout
+
+time
+
+30 seconds
+
+Specifies the time an invokation should wait for an instance of the pool
+to become available.
+
+callbackThreads
+
+int
+
+5
+
+The number of threads for constructing and destroying beans.
+
+closeTimeout
+
+time
+
+5 minutes
+
+Maximum time to wait for instances to be destroyed when shutting down
+the pool
+
+garbageCollection
+
+boolean
+
+false
+
+Allows Garbage Collection to be used as a mechanism for shrinking the
+pool.
+
+idleTimeout
+
+time
+
+0 minutes
+
+Specifies the maximum time that an instance should be allowed to sit
+idly in the pool without use before it should be retired and removed.
+
+maxAge
+
+time
+
+0 hours
+
+Specifies the maximum time that an instance should live before it should
+be retired and removed from use.
+
+maxAgeOffset
+
+int
+
+-1
+
+Applies to MaxAge usage and would rarely be changed, but is a nice
+feature to understand.
+
+maxSize
+
+int
+
+10
+
+Specifies the size of the instance pool for this stateless SessionBean
+container.
+
+minSize
+
+int
+
+0
+
+Specifies the minimum number of bean instances that should be in the
+pool for each bean.
+
+replaceAged
+
+boolean
+
+true
+
+When `ReplaceAged` is enabled, any instances in the pool that expire due
+to reaching their `MaxAge` will be replaced immediately so that the pool
+will remain at its current size.
+
+replaceFlushed
+
+boolean
+
+false
+
+When `ReplaceFlushed` is enabled, any instances in the pool that are
+flushed will be replaced immediately so that the pool will remain at its
+current size.
+
+strictPooling
+
+boolean
+
+true
+
+StrictPooling tells the container what to do when the pool reaches it's
+maximum size and there are incoming requests that need instances.
+
+sweepInterval
+
+time
+
+5 minutes
+
+The frequency in which the container will sweep the pool and evict
+expired instances.
+
+== accessTimeout
+
+Specifies the time an invokation should wait for an instance of the pool
+to become available.
+
+After the timeout is reached, if an instance in the pool cannot be
+obtained, the method invocation will fail.
+
+Usable time units: nanoseconds, microsecons, milliseconds, seconds,
+minutes, hours, days. Or any combination such as "1 hour and 27 minutes
+and 10 seconds"
+
+Any usage of the `javax.ejb.AccessTimeout` annotation will override this
+setting for the bean or method where the annotation is used.
+
+== callbackThreads
+
+The number of threads for constructing and destroying beans.
+
+When sweeping the pool for expired instances a thread pool is used to
+process calling `@PreDestroy` on expired instances as well as creating
+new instances as might be required to fill the pool to the minimum after
+a Flush or `MaxAge` expiration. The `CallbackThreads` setting dictates
+the size of the thread pool and is shared by all beans deployed in the
+container.
+
+== closeTimeout
+
+Maximum time to wait for instances to be destroyed when shutting down
+the pool
+
+PostConstruct methods are invoked on all instances in the pool when the
+bean is undeployed and its pool is closed. The `CloseTimeout` specifies
+the maximum time to wait for the pool to close and `PostConstruct`
+methods to be invoked.
+
+Usable time units: nanoseconds, microsecons, milliseconds, seconds,
+minutes, hours, days. Or any combination such as
+`1 hour and 27 minutes and 10 seconds`
+
+== garbageCollection
+
+Allows Garbage Collection to be used as a mechanism for shrinking the
+pool.
+
+When set to true all instances in the pool, excluding the minimum, are
+eligible for garbage collection by the virtual machine as per the rules
+of `java.lang.ref.SoftReference` and can be claimed by the JVM to free
+memory. Instances garbage collected will have their `@PreDestroy`
+methods called during finalization.
+
+In the OpenJDK VM the `-XX:SoftRefLRUPolicyMSPerMB` flag can adjust how
+aggressively SoftReferences are collected. The default OpenJDK setting
+is 1000, resulting in inactive pooled instances living one second of
+lifetime per free megabyte in the heap, which is very aggressive. The
+setting should be increased to get the most out of the
+`GarbageCollection` feature of the pool. Much higher settings are safe.
+Even a setting as high as 3600000 (1 hour per free MB in the heap) does
+not affect the ability for the VM to garbage collect SoftReferences in
+the event that memory is needed to avoid an `OutOfMemoryException`.
+
+== idleTimeout
+
+Specifies the maximum time that an instance should be allowed to sit
+idly in the pool without use before it should be retired and removed.
+
+Only instances in surplus of the pool's `MinSize` are eligible to expire
+via `IdleTimeout` Instances that expire due to `IdleTimeout` will have
+their `@PreDestroy` methods invoked before being completely destroyed.
+
+Usable time units: nanoseconds, microsecons, milliseconds, seconds,
+minutes, hours, days. Or any combination such as "1 hour and 27 minutes
+and 10 seconds"
+
+== maxAge
+
+Specifies the maximum time that an instance should live before it should
+be retired and removed from use.
+
+This will happen gracefully. Useful for situations where bean instances
+are designed to hold potentially expensive resources such as memory or
+file handles and need to be periodically cleared out.
+
+Usable time units: nanoseconds, microsecons, milliseconds, seconds,
+minutes, hours, days. Or any combination such as
+`1 hour and 27 minutes and 10 seconds`
+
+== maxAgeOffset
+
+Applies to MaxAge usage and would rarely be changed, but is a nice
+feature to understand.
+
+When the container first starts and the pool is filled to the minimum
+size, all those "minimum" instances will have the same creation time and
+therefore all expire at the same time dictated by the `MaxAge` setting.
+To protect against this sudden drop scenario and provide a more gradual
+expiration from the start the container will spread out the age of the
+instances that fill the pool to the minimum using an offset.
+
+The `MaxAgeOffset` is not the final value of the offset, but rather it
+is used in creating the offset and allows the spreading to push the
+initial ages into the future or into the past. The pool is filled at
+startup as follows:
+
+....
+for (int i = 0; i < poolMin; i++) {
+ long ageOffset = (maxAge / poolMin * i * maxAgeOffset) % maxAge;
+ pool.add(new Bean(), ageOffset));
+}
+....
+
+The default `MaxAgeOffset` is -1 which causes the initial instances in
+the pool to live a bit longer before expiring. As a concrete example,
+let's say the MinSize is 4 and the MaxAge is 100 years. The generated
+offsets for the four instances created at startup would be 0, -25, -50,
+-75. So the first instance would be "born" at age 0, die at 100, living
+100 years. The second instance would be born at -25, die at 100, living
+a total of 125 years. The third would live 150 years. The fourth 175
+years.
+
+A `MaxAgeOffset` of 1 would cause instances to be "born" older and
+therefore die sooner. Using the same example `MinSize` of 4 and `MaxAge`
+of `100 years`, the life spans of these initial four instances would be
+100, 75, 50, and 25 years respectively.
+
+A `MaxAgeOffset` of 0 will cause no "spreading" of the age of the first
+instances used to fill the pool to the minimum and these instances will
+of course reach their MaxAge at the same time. It is possible to set to
+decimal values such as -0.5, 0.5, -1.2, or 1.2.
+
+== maxSize
+
+Specifies the size of the instance pool for this stateless SessionBean
+container.
+
+Each `@Stateless` bean will get its own instance pool. If StrictPooling
+is not used, instances will still be created beyond this number if there
+is demand, but they will not be returned to the pool and instead will be
+immediately expire.
+
+== minSize
+
+Specifies the minimum number of bean instances that should be in the
+pool for each bean.
+
+Pools are prefilled to the minimum on startup. Note this will create
+start order dependencies between other beans that also eagerly start,
+such as other `@Stateless` beans with a minimum or `@Singleton` beans
+using `@Startup`. The `@DependsOn` annotation can be used to
+appropriately influence start order.
+
+The minimum pool size is rigidly maintained. Instances in the minimum
+side of the pool are not eligible for `IdleTimeout` or
+`GarbageCollection`, but are subject to `MaxAge` and flushing.
+
+If the pool is flushed it is immediately refilled to the minimum size
+with `MaxAgeOffset` applied. If an instance from the minimum side of the
+pool reaches its `MaxAge`, it is also immediately replaced. Replacement
+is done in a background queue using the number of threads specified by
+`CallbackThreads`.
+
+== replaceAged
+
+When `ReplaceAged` is enabled, any instances in the pool that expire due
+to reaching their `MaxAge` will be replaced immediately so that the pool
+will remain at its current size.
+
+Replacement is done in a background queue so that incoming threads will
+not have to wait for instance creation.
+
+The aim of his option is to prevent user requests from paying the
+instance creation cost as `MaxAge` is enforced, potentially while under
+heavy load at peak hours.
+
+Instances from the minimum side of the pool are always replaced when
+they reach their `MaxAge`, this setting dictates the treatment of
+non-minimum instances.
+
+== replaceFlushed
+
+When `ReplaceFlushed` is enabled, any instances in the pool that are
+flushed will be replaced immediately so that the pool will remain at its
+current size.
+
+Replacement is done in a background queue so that incoming threads will
+not have to wait for instance creation.
+
+The aim of his option is to prevent user requests from paying the
+instance creation cost if a flush performed while under heavy load at
+peak hours.
+
+Instances from the minimum side of the pool are always replaced when
+they are flushed, this setting dictates the treatment of non-minimum
+instances.
+
+A bean may flush its pool by casting the `SessionContext` to `Flushable`
+and calling `flush()`. See `SweepInterval` for details on how flush is
+performed.
+
+....
+import javax.annotation.Resource;
+import javax.ejb.SessionContext;
+import javax.ejb.Stateless;
+import java.io.Flushable;
+import java.io.IOException;
+
+public class MyBean {
+
+ private SessionContext sessionContext;
+
+ public void flush() throws IOException {
+
+ ((Flushable) sessionContext).flush();
+ }
+}
+....
+
+== strictPooling
+
+StrictPooling tells the container what to do when the pool reaches it's
+maximum size and there are incoming requests that need instances.
+
+With strict pooling, requests will have to wait for instances to become
+available. The pool size will never grow beyond the the set `MaxSize`
+value. The maximum amount of time a request should wait is specified via
+the `AccessTimeout` setting.
+
+Without strict pooling, the container will create temporary instances to
+meet demand. The instances will last for just one method invocation and
+then are removed.
+
+Setting `StrictPooling` to `false` and `MaxSize` to `0` will result in
+no pooling. Instead instances will be created on demand and live for
+exactly one method call before being removed.
+
+== sweepInterval
+
+The frequency in which the container will sweep the pool and evict
+expired instances.
+
+Eviction is how the `IdleTimeout`, `MaxAge`, and pool "flush"
+functionality is enforced. Higher intervals are better.
+
+Instances in use are excluded from sweeping. Should an instance expire
+while in use it will be evicted immediately upon return to the pool.
+Effectively `MaxAge` and flushes will be enforced as a part of normal
+activity or sweeping, while IdleTimeout is only enforcable via sweeping.
+This makes aggressive sweeping less important for a pool under moderate
+load.
+
+Usable time units: nanoseconds, microsecons, milliseconds, seconds,
+minutes, hours, days. Or any combination such as
+`1 hour and 27 minutes and 10 seconds`
http://git-wip-us.apache.org/repos/asf/tomee/blob/de7099c5/docs/statelesscontainer-config.md
----------------------------------------------------------------------
diff --git a/docs/statelesscontainer-config.md b/docs/statelesscontainer-config.md
deleted file mode 100644
index b89627b..0000000
--- a/docs/statelesscontainer-config.md
+++ /dev/null
@@ -1,461 +0,0 @@
-index-group=Unrevised
-type=page
-status=published
-title=StatelessContainer Configuration
-~~~~~~
-
-
-A StatelessContainer can be declared via xml in the `<tomee-home>/conf/tomee.xml` file or in a `WEB-INF/resources.xml` file using a declaration like the following. All properties in the element body are optional.
-
- <Container id="myStatelessContainer" type="STATELESS">
- accessTimeout = 30 seconds
- callbackThreads = 5
- closeTimeout = 5 minutes
- garbageCollection = false
- idleTimeout = 0 minutes
- maxAge = 0 hours
- maxAgeOffset = -1
- maxSize = 10
- minSize = 0
- replaceAged = true
- replaceFlushed = false
- strictPooling = true
- sweepInterval = 5 minutes
- </Container>
-
-Alternatively, a StatelessContainer can be declared via properties in the `<tomee-home>/conf/system.properties` file or via Java VirtualMachine `-D` properties. The properties can also be used when embedding TomEE via the `javax.ejb.embeddable.EJBContainer` API or `InitialContext`
-
- myStatelessContainer = new://Container?type=STATELESS
- myStatelessContainer.accessTimeout = 30 seconds
- myStatelessContainer.callbackThreads = 5
- myStatelessContainer.closeTimeout = 5 minutes
- myStatelessContainer.garbageCollection = false
- myStatelessContainer.idleTimeout = 0 minutes
- myStatelessContainer.maxAge = 0 hours
- myStatelessContainer.maxAgeOffset = -1
- myStatelessContainer.maxSize = 10
- myStatelessContainer.minSize = 0
- myStatelessContainer.replaceAged = true
- myStatelessContainer.replaceFlushed = false
- myStatelessContainer.strictPooling = true
- myStatelessContainer.sweepInterval = 5 minutes
-
-Properties and xml can be mixed. Properties will override the xml allowing for easy configuration change without the need for ${} style variable substitution. Properties are not case sensitive. If a property is specified that is not supported by the declared StatelessContainer a warning will be logged. If a StatelessContainer is needed by the application and one is not declared, TomEE will create one dynamically using default settings. Multiple StatelessContainer declarations are allowed.
-# Supported Properties
-<table class="mdtable">
-<tr>
-<th>Property</th>
-<th>Type</th>
-<th>Default</th>
-<th>Description</th>
-</tr>
-<tr>
- <td><a href="#accessTimeout">accessTimeout</a></td>
- <td><a href="configuring-durations.html">time</a></td>
- <td>30 seconds</td>
- <td>
-Specifies the time an invokation should wait for an instance
-of the pool to become available.
-</td>
-</tr>
-<tr>
- <td><a href="#callbackThreads">callbackThreads</a></td>
- <td>int</td>
- <td>5</td>
- <td>
-The number of threads for constructing and destroying beans.
-</td>
-</tr>
-<tr>
- <td><a href="#closeTimeout">closeTimeout</a></td>
- <td><a href="configuring-durations.html">time</a></td>
- <td>5 minutes</td>
- <td>
-Maximum time to wait for instances to be destroyed when shutting down the pool
-</td>
-</tr>
-<tr>
- <td><a href="#garbageCollection">garbageCollection</a></td>
- <td>boolean</td>
- <td>false</td>
- <td>
-Allows Garbage Collection to be used as a mechanism for shrinking
-the pool.
-</td>
-</tr>
-<tr>
- <td><a href="#idleTimeout">idleTimeout</a></td>
- <td><a href="configuring-durations.html">time</a></td>
- <td>0 minutes</td>
- <td>
-Specifies the maximum time that an instance should be allowed to
-sit idly in the pool without use before it should be retired and
-removed.
-</td>
-</tr>
-<tr>
- <td><a href="#maxAge">maxAge</a></td>
- <td><a href="configuring-durations.html">time</a></td>
- <td>0 hours</td>
- <td>
-Specifies the maximum time that an instance should live before
-it should be retired and removed from use.
-</td>
-</tr>
-<tr>
- <td><a href="#maxAgeOffset">maxAgeOffset</a></td>
- <td>int</td>
- <td>-1</td>
- <td>
-Applies to MaxAge usage and would rarely be changed, but is a
-nice feature to understand.
-</td>
-</tr>
-<tr>
- <td><a href="#maxSize">maxSize</a></td>
- <td>int</td>
- <td>10</td>
- <td>
-Specifies the size of the instance pool for this stateless
-SessionBean container.
-</td>
-</tr>
-<tr>
- <td><a href="#minSize">minSize</a></td>
- <td>int</td>
- <td>0</td>
- <td>
-Specifies the minimum number of bean instances that should be in
-the pool for each bean.
-</td>
-</tr>
-<tr>
- <td><a href="#replaceAged">replaceAged</a></td>
- <td>boolean</td>
- <td>true</td>
- <td>
-When `ReplaceAged` is enabled, any instances in the pool that
-expire due to reaching their `MaxAge` will be replaced immediately
-so that the pool will remain at its current size.
-</td>
-</tr>
-<tr>
- <td><a href="#replaceFlushed">replaceFlushed</a></td>
- <td>boolean</td>
- <td>false</td>
- <td>
-When `ReplaceFlushed` is enabled, any instances in the pool that
-are flushed will be replaced immediately so that the pool will
-remain at its current size.
-</td>
-</tr>
-<tr>
- <td><a href="#strictPooling">strictPooling</a></td>
- <td>boolean</td>
- <td>true</td>
- <td>
-StrictPooling tells the container what to do when the pool
-reaches it's maximum size and there are incoming requests that
-need instances.
-</td>
-</tr>
-<tr>
- <td><a href="#sweepInterval">sweepInterval</a></td>
- <td><a href="configuring-durations.html">time</a></td>
- <td>5 minutes</td>
- <td>
-The frequency in which the container will sweep the pool and
-evict expired instances.
-</td>
-</tr>
-</table>
-
-
-
-<a name="accessTimeout"></a>
-## accessTimeout
-
-Specifies the time an invokation should wait for an instance
-of the pool to become available.
-
-After the timeout is reached, if an instance in the pool cannot
-be obtained, the method invocation will fail.
-
-Usable time units: nanoseconds, microsecons, milliseconds,
-seconds, minutes, hours, days. Or any combination such as
-"1 hour and 27 minutes and 10 seconds"
-
-Any usage of the `javax.ejb.AccessTimeout` annotation will
-override this setting for the bean or method where the
-annotation is used.
-
-
-<a name="callbackThreads"></a>
-## callbackThreads
-
-The number of threads for constructing and destroying beans.
-
-When sweeping the pool for expired instances a thread pool is
-used to process calling `@PreDestroy` on expired instances as well
-as creating new instances as might be required to fill the pool
-to the minimum after a Flush or `MaxAge` expiration. The
-`CallbackThreads` setting dictates the size of the thread pool and
-is shared by all beans deployed in the container.
-
-
-<a name="closeTimeout"></a>
-## closeTimeout
-
-Maximum time to wait for instances to be destroyed when shutting down the pool
-
-PostConstruct methods are invoked on all instances in the pool
-when the bean is undeployed and its pool is closed. The
-`CloseTimeout` specifies the maximum time to wait for the pool to
-close and `PostConstruct` methods to be invoked.
-
-Usable time units: nanoseconds, microsecons, milliseconds,
-seconds, minutes, hours, days. Or any combination such as
-`1 hour and 27 minutes and 10 seconds`
-
-
-<a name="garbageCollection"></a>
-## garbageCollection
-
-Allows Garbage Collection to be used as a mechanism for shrinking
-the pool.
-
-When set to true all instances in the pool, excluding
-the minimum, are eligible for garbage collection by the virtual
-machine as per the rules of `java.lang.ref.SoftReference` and can be
-claimed by the JVM to free memory. Instances garbage collected
-will have their `@PreDestroy` methods called during finalization.
-
-In the OpenJDK VM the `-XX:SoftRefLRUPolicyMSPerMB` flag can adjust
-how aggressively SoftReferences are collected. The default
-OpenJDK setting is 1000, resulting in inactive pooled instances
-living one second of lifetime per free megabyte in the heap, which
-is very aggressive. The setting should be increased to get the
-most out of the `GarbageCollection` feature of the pool. Much
-higher settings are safe. Even a setting as high as 3600000 (1
-hour per free MB in the heap) does not affect the ability for the
-VM to garbage collect SoftReferences in the event that memory is
-needed to avoid an `OutOfMemoryException`.
-
-
-<a name="idleTimeout"></a>
-## idleTimeout
-
-Specifies the maximum time that an instance should be allowed to
-sit idly in the pool without use before it should be retired and
-removed.
-
-Only instances
-in surplus of the pool's `MinSize` are eligible to expire via `IdleTimeout`
-Instances that expire due to `IdleTimeout` will have their `@PreDestroy`
-methods invoked before being completely destroyed.
-
-Usable time units: nanoseconds, microsecons, milliseconds,
-seconds, minutes, hours, days. Or any combination such as
-"1 hour and 27 minutes and 10 seconds"
-
-
-<a name="maxAge"></a>
-## maxAge
-
-Specifies the maximum time that an instance should live before
-it should be retired and removed from use.
-
-This will happen
-gracefully. Useful for situations where bean instances are
-designed to hold potentially expensive resources such as memory
-or file handles and need to be periodically cleared out.
-
-Usable time units: nanoseconds, microsecons, milliseconds,
-seconds, minutes, hours, days. Or any combination such as
-`1 hour and 27 minutes and 10 seconds`
-
-
-<a name="maxAgeOffset"></a>
-## maxAgeOffset
-
-Applies to MaxAge usage and would rarely be changed, but is a
-nice feature to understand.
-
-When the container first starts and the pool is filled to the
-minimum size, all those "minimum" instances will have the same
-creation time and therefore all expire at the same time dictated
-by the `MaxAge` setting. To protect against this sudden drop
-scenario and provide a more gradual expiration from the start
-the container will spread out the age of the instances that fill
-the pool to the minimum using an offset.
-
-The `MaxAgeOffset` is not the final value of the offset, but
-rather it is used in creating the offset and allows the
-spreading to push the initial ages into the future or into the
-past. The pool is filled at startup as follows:
-
- for (int i = 0; i < poolMin; i++) {
- long ageOffset = (maxAge / poolMin * i * maxAgeOffset) % maxAge;
- pool.add(new Bean(), ageOffset));
- }
-
-The default `MaxAgeOffset` is -1 which causes the initial
-instances in the pool to live a bit longer before expiring. As
-a concrete example, let's say the MinSize is 4 and the MaxAge is
-100 years. The generated offsets for the four instances created
-at startup would be 0, -25, -50, -75. So the first instance
-would be "born" at age 0, die at 100, living 100 years. The
-second instance would be born at -25, die at 100, living a total
-of 125 years. The third would live 150 years. The fourth 175
-years.
-
-A `MaxAgeOffset` of 1 would cause instances to be "born" older
-and therefore die sooner. Using the same example `MinSize` of 4
-and `MaxAge` of `100 years`, the life spans of these initial four
-instances would be 100, 75, 50, and 25 years respectively.
-
-A `MaxAgeOffset` of 0 will cause no "spreading" of the age of the
-first instances used to fill the pool to the minimum and these
-instances will of course reach their MaxAge at the same time.
-It is possible to set to decimal values such as -0.5, 0.5, -1.2,
-or 1.2.
-
-
-<a name="maxSize"></a>
-## maxSize
-
-Specifies the size of the instance pool for this stateless
-SessionBean container.
-
-Each `@Stateless` bean will get its own instance pool.
-If StrictPooling is not used, instances
-will still be created beyond this number if there is demand, but
-they will not be returned to the pool and instead will be
-immediately expire.
-
-
-<a name="minSize"></a>
-## minSize
-
-Specifies the minimum number of bean instances that should be in
-the pool for each bean.
-
-Pools are prefilled to the minimum on
-startup. Note this will create start order dependencies between
-other beans that also eagerly start, such as other `@Stateless`
-beans with a minimum or `@Singleton` beans using `@Startup`. The
-`@DependsOn` annotation can be used to appropriately influence
-start order.
-
-The minimum pool size is rigidly maintained. Instances in the
-minimum side of the pool are not eligible for `IdleTimeout` or
-`GarbageCollection`, but are subject to `MaxAge` and flushing.
-
-If the pool is flushed it is immediately refilled to the minimum
-size with `MaxAgeOffset` applied. If an instance from the minimum
-side of the pool reaches its `MaxAge`, it is also immediately
-replaced. Replacement is done in a background queue using the
-number of threads specified by `CallbackThreads`.
-
-
-<a name="replaceAged"></a>
-## replaceAged
-
-When `ReplaceAged` is enabled, any instances in the pool that
-expire due to reaching their `MaxAge` will be replaced immediately
-so that the pool will remain at its current size.
-
-Replacement
-is done in a background queue so that incoming threads will not
-have to wait for instance creation.
-
-The aim of his option is to prevent user requests from paying
-the instance creation cost as `MaxAge` is enforced, potentially
-while under heavy load at peak hours.
-
-Instances from the minimum side of the pool are always replaced
-when they reach their `MaxAge`, this setting dictates the
-treatment of non-minimum instances.
-
-
-<a name="replaceFlushed"></a>
-## replaceFlushed
-
-When `ReplaceFlushed` is enabled, any instances in the pool that
-are flushed will be replaced immediately so that the pool will
-remain at its current size.
-
-Replacement is done in a background
-queue so that incoming threads will not have to wait for
-instance creation.
-
-The aim of his option is to prevent user requests from paying
-the instance creation cost if a flush performed while under
-heavy load at peak hours.
-
-Instances from the minimum side of the pool are always replaced
-when they are flushed, this setting dictates the treatment of
-non-minimum instances.
-
-A bean may flush its pool by casting the `SessionContext` to
-`Flushable` and calling `flush()`. See `SweepInterval` for details on
-how flush is performed.
-
- import javax.annotation.Resource;
- import javax.ejb.SessionContext;
- import javax.ejb.Stateless;
- import java.io.Flushable;
- import java.io.IOException;
-
- public class MyBean {
-
- private SessionContext sessionContext;
-
- public void flush() throws IOException {
-
- ((Flushable) sessionContext).flush();
- }
- }
-
-
-<a name="strictPooling"></a>
-## strictPooling
-
-StrictPooling tells the container what to do when the pool
-reaches it's maximum size and there are incoming requests that
-need instances.
-
-With strict pooling, requests will have to wait for instances to
-become available. The pool size will never grow beyond the the
-set `MaxSize` value. The maximum amount of time a request should
-wait is specified via the `AccessTimeout` setting.
-
-Without strict pooling, the container will create temporary
-instances to meet demand. The instances will last for just one
-method invocation and then are removed.
-
-Setting `StrictPooling` to `false` and `MaxSize` to `0` will result in
-no pooling. Instead instances will be created on demand and live
-for exactly one method call before being removed.
-
-
-<a name="sweepInterval"></a>
-## sweepInterval
-
-The frequency in which the container will sweep the pool and
-evict expired instances.
-
-Eviction is how the `IdleTimeout`,
-`MaxAge`, and pool "flush" functionality is enforced. Higher
-intervals are better.
-
-Instances in use are excluded from sweeping. Should an instance
-expire while in use it will be evicted immediately upon return
-to the pool. Effectively `MaxAge` and flushes will be enforced as
-a part of normal activity or sweeping, while IdleTimeout is only
-enforcable via sweeping. This makes aggressive sweeping less
-important for a pool under moderate load.
-
-Usable time units: nanoseconds, microsecons, milliseconds,
-seconds, minutes, hours, days. Or any combination such as
-`1 hour and 27 minutes and 10 seconds`
http://git-wip-us.apache.org/repos/asf/tomee/blob/de7099c5/docs/system-properties-files.adoc
----------------------------------------------------------------------
diff --git a/docs/system-properties-files.adoc b/docs/system-properties-files.adoc
new file mode 100644
index 0000000..ec742bf
--- /dev/null
+++ b/docs/system-properties-files.adoc
@@ -0,0 +1,25 @@
+# System Properties Files
+:index-group: Unrevised
+:jbake-date: 2018-12-05
+:jbake-type: page
+:jbake-status: published
+
+
+== OpenEJB System Properties File
+
+OpenEJB and TomEE are really configurable in particular through system
+properties.
+
+What is not so known is these system properties can be read from several
+places. The order is important, it means if the second place provides
+the same property than the first one, the first one will be omitted.
+
+Here how it works:
+
+* JVM system properties: -Dxxx=yyy
+* user system.properties: the file
+$\{user.home}/.openejb/system.properties
+* instance system.properties: conf/system.properties
+
+Note: generally you place in the user system properties file the contant
+configuration (check my openejb version for instance).
http://git-wip-us.apache.org/repos/asf/tomee/blob/de7099c5/docs/system-properties-files.md
----------------------------------------------------------------------
diff --git a/docs/system-properties-files.md b/docs/system-properties-files.md
deleted file mode 100644
index d6902da..0000000
--- a/docs/system-properties-files.md
+++ /dev/null
@@ -1,22 +0,0 @@
-index-group=Unrevised
-type=page
-status=published
-title=System Properties Files
-~~~~~~
-
-# OpenEJB System Properties File
-
-OpenEJB and TomEE are really configurable in particular through system properties.
-
-What is not so known is these system properties can be read from several places. The order is important,
-it means if the second place provides the same property than the first one, the first one will be
-omitted.
-
-Here how it works:
-
-* JVM system properties: -Dxxx=yyy
-* user system.properties: the file ${user.home}/.openejb/system.properties
-* instance system.properties: conf/system.properties
-
-Note: generally you place in the user system properties file the contant configuration (check my openejb
-version for instance).
http://git-wip-us.apache.org/repos/asf/tomee/blob/de7099c5/docs/system-properties.adoc
----------------------------------------------------------------------
diff --git a/docs/system-properties.adoc b/docs/system-properties.adoc
new file mode 100644
index 0000000..f61ea79
--- /dev/null
+++ b/docs/system-properties.adoc
@@ -0,0 +1,68 @@
+# System Properties
+:index-group: Configuration
+:jbake-date: 2018-12-05
+:jbake-type: page
+:jbake-status: published
+
+
+You can find a list of properties link:properties-listing.html[here].
+But read on to understand how these can be used.
+
+== Overriding openejb.xml
+
+Anything in the openejb.xml file can be overridden via system properties
+of the format:
+
+`-D<id>.<property-name>=<property-value>`
+
+..where id is the value in the config file for example:
+
+....
+<Connector id="mysql">
+ JdbcDriver com.mysql.jdbc.Driver
+ JdbcUrl jdbc:mysql://localhost/test
+ UserName test
+</Connector>
+....
+
+Could be overridden as follows via system properties on the command
+line:
+
+______________________________________________________________________________________________________________________________
+./bin/openejb start -Dmysql.JdbcDriver=com.mysql.jdbc.Driver
+-Dmysql.JdbcUrl=jdbc:mysql://localhost/test -Dmysql.UserName=test
+______________________________________________________________________________________________________________________________
+
+== Overriding Server Services
+
+Any server service installed into OpenEJB can be overridden in the same
+fashion as things in the openejb.xml file.
+
+For example, when OpenEJB starts it prints out the following:
+
+....
+ ** Starting Services **
+ NAME IP PORT
+ httpejbd 0.0.0.0 4204
+ telnet 0.0.0.0 4202
+ ejbd 0.0.0.0 4201
+ hsql 0.0.0.0 9001
+ activemq 127.0.0.1 4206
+ derbynet 0.0.0.0 4205
+ admin thread 0.0.0.0 4200
+....
+
+Each of those has the same standard xinet.d-like properties which can
+also be configured as such:
+
+`-D<id>.<property-name>=<property-value>`
+
+... where 'id' is the name of the server service and 'property-name' is
+one of the following: bind, port, threads, disabled, only_from.
+
+So to set the address and port the ejbd service will bind to, simply
+specify this on the command line:
+
+....
+./bin/openejb start -Dejbd.bind=192.168.1.12 -Dejbd.port=9988
+....
http://git-wip-us.apache.org/repos/asf/tomee/blob/de7099c5/docs/system-properties.md
----------------------------------------------------------------------
diff --git a/docs/system-properties.md b/docs/system-properties.md
deleted file mode 100644
index 2c3714b..0000000
--- a/docs/system-properties.md
+++ /dev/null
@@ -1,68 +0,0 @@
-index-group=Configuration
-type=page
-status=published
-title=System Properties
-~~~~~~
-
-<a name="SystemProperties-Overridingopenejb.xml"></a>
-
-You can find a list of properties [here](properties-listing.html). But read on to understand how these can be used.
-
-# Overriding openejb.xml
-
-Anything in the openejb.xml file can be overridden via system properties of
-the format:
-
-
- `-D<id>.<property-name>=<property-value>`
-
-..where id is the value in the config file for example:
-
-
- <Connector id="mysql">
- JdbcDriver com.mysql.jdbc.Driver
- JdbcUrl jdbc:mysql://localhost/test
- UserName test
- </Connector>
-
-
-Could be overridden as follows via system properties on the command line:
-
-> ./bin/openejb start -Dmysql.JdbcDriver=com.mysql.jdbc.Driver
-> -Dmysql.JdbcUrl=jdbc:mysql://localhost/test -Dmysql.UserName=test
-
-<a name="SystemProperties-OverridingServerServices"></a>
-
-# Overriding Server Services
-
-Any server service installed into OpenEJB can be overridden in the same
-fashion as things in the openejb.xml file.
-
-For example, when OpenEJB starts it prints out the following:
-
-
- ** Starting Services **
- NAME IP PORT
- httpejbd 0.0.0.0 4204
- telnet 0.0.0.0 4202
- ejbd 0.0.0.0 4201
- hsql 0.0.0.0 9001
- activemq 127.0.0.1 4206
- derbynet 0.0.0.0 4205
- admin thread 0.0.0.0 4200
-
-
-Each of those has the same standard xinet.d-like properties which can also
-be configured as such:
-
-
- `-D<id>.<property-name>=<property-value>`
-
-
-... where 'id' is the name of the server service and 'property-name' is one
-of the following: bind, port, threads, disabled, only_from.
-
-So to set the address and port the ejbd service will bind to, simply
-specify this on the command line:
-
- ./bin/openejb start -Dejbd.bind=192.168.1.12 -Dejbd.port=9988