You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@logging.apache.org by rp...@apache.org on 2014/09/17 17:45:28 UTC

[1/3] git commit: LOG4J2-431 MemoryMappedFileAppender manual page

Repository: logging-log4j2
Updated Branches:
  refs/heads/LOG4J2-431 64369f3d7 -> 63aed83d6


LOG4J2-431 MemoryMappedFileAppender manual page

Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/80dafe9e
Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/80dafe9e
Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/80dafe9e

Branch: refs/heads/LOG4J2-431
Commit: 80dafe9e85c28f89d5b4d411d8b28c33642f411f
Parents: 64369f3
Author: rpopma <rp...@apache.org>
Authored: Thu Sep 18 00:42:50 2014 +0900
Committer: rpopma <rp...@apache.org>
Committed: Thu Sep 18 00:42:50 2014 +0900

----------------------------------------------------------------------
 src/site/xdoc/manual/appenders.xml | 131 ++++++++++++++++++++++++++++++++
 1 file changed, 131 insertions(+)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/80dafe9e/src/site/xdoc/manual/appenders.xml
----------------------------------------------------------------------
diff --git a/src/site/xdoc/manual/appenders.xml b/src/site/xdoc/manual/appenders.xml
index 032983b..7d47f78 100644
--- a/src/site/xdoc/manual/appenders.xml
+++ b/src/site/xdoc/manual/appenders.xml
@@ -1320,6 +1320,137 @@ public class JpaLogEntity extends AbstractLogEventWrapperEntity {
     ...
 }]]></pre>
         </subsection>
+      <a name="MemoryMappedFileAppender" />
+      <subsection name="MemoryMappedFileAppender">
+        <p><i>Experimental. This has been tested on several platforms, but this is
+          a new component (since 2.1) and does not yet have much track record.</i></p>
+        <p>
+          The MemoryMappedFileAppender maps a part of the specified file into memory
+          and writes log events to this memory, relying on the operating system's
+          virtual memory manager to synchronize the changes to the storage device.
+          The main benefit of doing this is I/O performance. Instead of making system
+          calls to write to disk, this appender can simply change the program's local memory,
+          which is orders of magnitude faster. Also, in most operating systems the memory
+          region mapped actually is the kernel's <a href="http://en.wikipedia.org/wiki/Page_cache">page
+          cache</a> (file cache), meaning that no copies need to be created in user space.
+          (TODO: performance tests that compare performance of this appender to
+          RandomAccessFileAppender and FileAppender.)
+        </p>
+        <p>
+          There is some overhead with mapping a file region into memory,
+          especially very large regions (half a gigabyte or more).
+          The default region size is 32 MB, which should strike a reasonable balance
+          between the frequency and the duration of remap operations.
+          (TODO: performance test remapping various sizes.)
+        </p>
+        <p>
+          Similar to the FileAppender and the RandomAccessFileAppender,
+          MemoryMappedFileAppender uses a MemoryMappedFileManager to actually perform the
+          file I/O. While MemoryMappedFileAppender from different Configurations
+          cannot be shared, the MemoryMappedFileManagers can be if the Manager is
+          accessible. For example, two web applications in a servlet container can have
+          their own configuration and safely write to the same file if Log4j
+          is in a ClassLoader that is common to both of them.
+        </p>
+        <table>
+          <caption align="top">MemoryMappedFileAppender Parameters</caption>
+          <tr>
+            <th>Parameter Name</th>
+            <th>Type</th>
+            <th>Description</th>
+          </tr>
+          <tr>
+            <td>append</td>
+            <td>boolean</td>
+            <td>When true - the default, records will be appended to the end
+              of the file. When set to false, the file will be cleared before
+              new records are written.
+            </td>
+          </tr>
+          <tr>
+            <td>fileName</td>
+            <td>String</td>
+            <td>The name of the file to write to. If the file, or any of its
+              parent directories, do not exist, they will be created.
+            </td>
+          </tr>
+          <tr>
+            <td>filters</td>
+            <td>Filter</td>
+            <td>A Filter to determine if the event should be handled by this
+              Appender. More than one Filter may be used by using a CompositeFilter.
+            </td>
+          </tr>
+          <tr>
+            <td>immediateFlush</td>
+            <td>boolean</td>
+            <td>
+              <p>When set to true, each write will be followed by a
+                call to <a href="http://docs.oracle.com/javase/7/docs/api/java/nio/MappedByteBuffer.html#force()">MappedByteBuffer.force()</a>.
+            This will guarantee the data is written to the storage device.
+              </p>
+              <p>The default for this parameter is <code>false</code>.
+                This means that the data is written to the storage device even
+                if the Java process crashes, but there may be data loss if the
+                operating system crashes. Note that manually forcing a sync on every
+                log event loses most of the performance benefits of using a memory mapped file.</p>
+              <p>Flushing after every write is only useful when using this
+              appender with synchronous loggers. Asynchronous loggers and
+              appenders will automatically flush at the end of a batch of events,
+              even if immediateFlush is set to false. This also guarantees
+              the data is written to disk but is more efficient.
+              </p>
+            </td>
+          </tr>
+          <tr>
+            <td>regionLength</td>
+            <td>int</td>
+            <td>The length of the mapped region, defaults to 32 MB 
+              (32 * 1024 * 1024 bytes). This parameter must be a value
+              between 256 and 1,073,741,824 (1 GB or 2^30);
+              values outside this range will be adjusted to the closest valid
+              value.
+              Log4j will round the specified value up to the nearest power of two.</td>
+          </tr>
+          <tr>
+            <td>layout</td>
+            <td>Layout</td>
+            <td>The Layout to use to format the LogEvent</td>
+          </tr>
+          <tr>
+            <td>name</td>
+            <td>String</td>
+            <td>The name of the Appender.</td>
+          </tr>
+          <tr>
+            <td>ignoreExceptions</td>
+            <td>boolean</td>
+            <td>The default is <code>true</code>, causing exceptions encountered while appending events to be
+              internally logged and then ignored. When set to <code>false</code> exceptions will be propagated to the
+              caller, instead. You must set this to <code>false</code> when wrapping this Appender in a
+              <a href="#FailoverAppender">FailoverAppender</a>.</td>
+          </tr>
+        </table>
+        <p>
+          Here is a sample MemoryMappedFile configuration:
+        </p>
+
+          <pre class="prettyprint linenums"><![CDATA[<?xml version="1.0" encoding="UTF-8"?>
+<Configuration status="warn" name="MyApp" packages="">
+  <Appenders>
+    <MemoryMappedFile name="MyFile" fileName="logs/app.log">
+      <PatternLayout>
+        <Pattern>%d %p %c{1.} [%t] %m%n</Pattern>
+      </PatternLayout>
+    </MemoryMappedFile>
+  </Appenders>
+  <Loggers>
+    <Root level="error">
+      <AppenderRef ref="MyFile"/>
+    </Root>
+  </Loggers>
+</Configuration>]]></pre>
+      </subsection>
         <a name="NoSQLAppender"/>
         <subsection name="NoSQLAppender">
           <p>The NoSQLAppender writes log events to a NoSQL database using an internal lightweight provider interface.


[3/3] git commit: LOG4J2-431 small fix to prevent spurious buffer.force() calls

Posted by rp...@apache.org.
LOG4J2-431 small fix to prevent spurious buffer.force() calls

Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/63aed83d
Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/63aed83d
Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/63aed83d

Branch: refs/heads/LOG4J2-431
Commit: 63aed83d6abb149935954370341f4d0beab85440
Parents: a5325b3
Author: rpopma <rp...@apache.org>
Authored: Thu Sep 18 00:44:47 2014 +0900
Committer: rpopma <rp...@apache.org>
Committed: Thu Sep 18 00:44:47 2014 +0900

----------------------------------------------------------------------
 .../log4j/core/appender/MemoryMappedFileManager.java  | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/63aed83d/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/MemoryMappedFileManager.java
----------------------------------------------------------------------
diff --git a/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/MemoryMappedFileManager.java b/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/MemoryMappedFileManager.java
index 29f8c54..04d4ef1 100644
--- a/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/MemoryMappedFileManager.java
+++ b/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/MemoryMappedFileManager.java
@@ -111,9 +111,8 @@ public class MemoryMappedFileManager extends OutputStreamManager {
         }
         mappedBuffer.put(bytes, offset, length);
 
-        if (isForce) {
-            flush();
-        }
+        // no need to call flush() if force is true,
+        // already done in AbstractOutputStreamAppender.append
     }
 
     private synchronized void remap() {
@@ -205,6 +204,15 @@ public class MemoryMappedFileManager extends OutputStreamManager {
     public int getRegionLength() {
         return regionLength;
     }
+    
+    /**
+     * Returns {@code true} if the content of the buffer should be forced to the storage device on every write,
+     * {@code false} otherwise.
+     * @return whether each write should be force-sync'ed
+     */
+    public boolean isImmediateFlush() {
+        return isForce;
+    }
 
     /** {@code OutputStream} subclass that does not write anything. */
     static class DummyOutputStream extends OutputStream {


Re: [1/3] git commit: LOG4J2-431 MemoryMappedFileAppender manual page

Posted by Remko Popma <re...@gmail.com>.
Thanks for the clarification. 
I thought I knew that, but apparently I didn't. Still learning...
Next step: deleting branch LOG4J2-431. (It's not easy from EGit, I got that far...)

Sent from my iPhone

> On 2014/09/19, at 6:49, Matt Sicker <bo...@gmail.com> wrote:
> 
> You should on rebase to the branch point that you may have that hasn't been pushed anywhere. So for instance, if you have your own local branch and never push it, it works just fine to keep doing rebase. However, if you push out your branch like I've done a few times so far, then you need to merge instead of rebase.
> 
>> On 17 September 2014 18:49, Remko Popma <re...@gmail.com> wrote:
>> I wonder what I did wrong... I did:
>> * change appenders.xml and changes.xml
>> * commit locally (not commit and push)
>> * rebase with origin/master
>> ...and got a lot of conflicts. 
>> 
>> The changes.xml conflict is expected, but it's marking all files I added (MemoryMappedFileAppender.java, etc) as conflicting additions now...
>> 
>> Should I have pushed my local changes to the remote 431 branch before rebasing with origin/master?
>> 
>> 
>>> On Thursday, September 18, 2014, Remko Popma <re...@gmail.com> wrote:
>>> I rephrased it but when I tried to rebase the branch I got tons of conflicts and got stuck. I'll try again tonight. 
>>> 
>>> Sent from my iPhone
>>> 
>>>> On 2014/09/18, at 1:55, Matt Sicker <bo...@gmail.com> wrote:
>>>> 
>>>> I think it would definitely be a good idea to mention "since 2.1" or a similar message. That's rather important since we don't maintain past versions of the website manual.
>>>> 
>>>>> On 17 September 2014 11:13, Gary Gregory <ga...@gmail.com> wrote:
>>>>> I would say nothing, otherwise, we should go around all of the docs and put "beta" on all the new stuff. I think the docs maybe could say "since 2.1" or "new" for the new stuff. But it is says "new" or "beta" you have to go edit that again when we release. I think it is best to have a "what's new section" that tracks what was added in each version.
>>>>> 
>>>>> Gary
>>>>> 
>>>>>> On Wed, Sep 17, 2014 at 12:02 PM, Remko Popma <re...@gmail.com> wrote:
>>>>>> Shall I replace "Experimental" with "Beta" in the docs for this component then until 2.1 final? I'm fine with that.
>>>>>> 
>>>>>>> On Thu, Sep 18, 2014 at 12:48 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>>> I do not think this should be marker "experimental".
>>>>>>> 
>>>>>>> If it is brought into trunk for 2.1 and we have a beta, we can say, this and that are new, it's a beta.
>>>>>>> 
>>>>>>> Gary
>>>>>>> 
>>>>>>> ---------- Forwarded message ----------
>>>>>>> From: <rp...@apache.org>
>>>>>>> Date: Wed, Sep 17, 2014 at 11:45 AM
>>>>>>> Subject: [1/3] git commit: LOG4J2-431 MemoryMappedFileAppender manual page
>>>>>>> To: commits@logging.apache.org
>>>>>>> 
>>>>>>> 
>>>>>>> Repository: logging-log4j2
>>>>>>> Updated Branches:
>>>>>>>   refs/heads/LOG4J2-431 64369f3d7 -> 63aed83d6
>>>>>>> 
>>>>>>> 
>>>>>>> LOG4J2-431 MemoryMappedFileAppender manual page
>>>>>>> 
>>>>>>> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
>>>>>>> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/80dafe9e
>>>>>>> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/80dafe9e
>>>>>>> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/80dafe9e
>>>>>>> 
>>>>>>> Branch: refs/heads/LOG4J2-431
>>>>>>> Commit: 80dafe9e85c28f89d5b4d411d8b28c33642f411f
>>>>>>> Parents: 64369f3
>>>>>>> Author: rpopma <rp...@apache.org>
>>>>>>> Authored: Thu Sep 18 00:42:50 2014 +0900
>>>>>>> Committer: rpopma <rp...@apache.org>
>>>>>>> Committed: Thu Sep 18 00:42:50 2014 +0900
>>>>>>> 
>>>>>>> ----------------------------------------------------------------------
>>>>>>>  src/site/xdoc/manual/appenders.xml | 131 ++++++++++++++++++++++++++++++++
>>>>>>>  1 file changed, 131 insertions(+)
>>>>>>> ----------------------------------------------------------------------
>>>>>>> 
>>>>>>> 
>>>>>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/80dafe9e/src/site/xdoc/manual/appenders.xml
>>>>>>> ----------------------------------------------------------------------
>>>>>>> diff --git a/src/site/xdoc/manual/appenders.xml b/src/site/xdoc/manual/appenders.xml
>>>>>>> index 032983b..7d47f78 100644
>>>>>>> --- a/src/site/xdoc/manual/appenders.xml
>>>>>>> +++ b/src/site/xdoc/manual/appenders.xml
>>>>>>> @@ -1320,6 +1320,137 @@ public class JpaLogEntity extends AbstractLogEventWrapperEntity {
>>>>>>>      ...
>>>>>>>  }]]></pre>
>>>>>>>          </subsection>
>>>>>>> +      <a name="MemoryMappedFileAppender" />
>>>>>>> +      <subsection name="MemoryMappedFileAppender">
>>>>>>> +        <p><i>Experimental. This has been tested on several platforms, but this is
>>>>>>> +          a new component (since 2.1) and does not yet have much track record.</i></p>
>>>>>>> +        <p>
>>>>>>> +          The MemoryMappedFileAppender maps a part of the specified file into memory
>>>>>>> +          and writes log events to this memory, relying on the operating system's
>>>>>>> +          virtual memory manager to synchronize the changes to the storage device.
>>>>>>> +          The main benefit of doing this is I/O performance. Instead of making system
>>>>>>> +          calls to write to disk, this appender can simply change the program's local memory,
>>>>>>> +          which is orders of magnitude faster. Also, in most operating systems the memory
>>>>>>> +          region mapped actually is the kernel's <a href="http://en.wikipedia.org/wiki/Page_cache">page
>>>>>>> +          cache</a> (file cache), meaning that no copies need to be created in user space.
>>>>>>> +          (TODO: performance tests that compare performance of this appender to
>>>>>>> +          RandomAccessFileAppender and FileAppender.)
>>>>>>> +        </p>
>>>>>>> +        <p>
>>>>>>> +          There is some overhead with mapping a file region into memory,
>>>>>>> +          especially very large regions (half a gigabyte or more).
>>>>>>> +          The default region size is 32 MB, which should strike a reasonable balance
>>>>>>> +          between the frequency and the duration of remap operations.
>>>>>>> +          (TODO: performance test remapping various sizes.)
>>>>>>> +        </p>
>>>>>>> +        <p>
>>>>>>> +          Similar to the FileAppender and the RandomAccessFileAppender,
>>>>>>> +          MemoryMappedFileAppender uses a MemoryMappedFileManager to actually perform the
>>>>>>> +          file I/O. While MemoryMappedFileAppender from different Configurations
>>>>>>> +          cannot be shared, the MemoryMappedFileManagers can be if the Manager is
>>>>>>> +          accessible. For example, two web applications in a servlet container can have
>>>>>>> +          their own configuration and safely write to the same file if Log4j
>>>>>>> +          is in a ClassLoader that is common to both of them.
>>>>>>> +        </p>
>>>>>>> +        <table>
>>>>>>> +          <caption align="top">MemoryMappedFileAppender Parameters</caption>
>>>>>>> +          <tr>
>>>>>>> +            <th>Parameter Name</th>
>>>>>>> +            <th>Type</th>
>>>>>>> +            <th>Description</th>
>>>>>>> +          </tr>
>>>>>>> +          <tr>
>>>>>>> +            <td>append</td>
>>>>>>> +            <td>boolean</td>
>>>>>>> +            <td>When true - the default, records will be appended to the end
>>>>>>> +              of the file. When set to false, the file will be cleared before
>>>>>>> +              new records are written.
>>>>>>> +            </td>
>>>>>>> +          </tr>
>>>>>>> +          <tr>
>>>>>>> +            <td>fileName</td>
>>>>>>> +            <td>String</td>
>>>>>>> +            <td>The name of the file to write to. If the file, or any of its
>>>>>>> +              parent directories, do not exist, they will be created.
>>>>>>> +            </td>
>>>>>>> +          </tr>
>>>>>>> +          <tr>
>>>>>>> +            <td>filters</td>
>>>>>>> +            <td>Filter</td>
>>>>>>> +            <td>A Filter to determine if the event should be handled by this
>>>>>>> +              Appender. More than one Filter may be used by using a CompositeFilter.
>>>>>>> +            </td>
>>>>>>> +          </tr>
>>>>>>> +          <tr>
>>>>>>> +            <td>immediateFlush</td>
>>>>>>> +            <td>boolean</td>
>>>>>>> +            <td>
>>>>>>> +              <p>When set to true, each write will be followed by a
>>>>>>> +                call to <a href="http://docs.oracle.com/javase/7/docs/api/java/nio/MappedByteBuffer.html#force()">MappedByteBuffer.force()</a>.
>>>>>>> +            This will guarantee the data is written to the storage device.
>>>>>>> +              </p>
>>>>>>> +              <p>The default for this parameter is <code>false</code>.
>>>>>>> +                This means that the data is written to the storage device even
>>>>>>> +                if the Java process crashes, but there may be data loss if the
>>>>>>> +                operating system crashes. Note that manually forcing a sync on every
>>>>>>> +                log event loses most of the performance benefits of using a memory mapped file.</p>
>>>>>>> +              <p>Flushing after every write is only useful when using this
>>>>>>> +              appender with synchronous loggers. Asynchronous loggers and
>>>>>>> +              appenders will automatically flush at the end of a batch of events,
>>>>>>> +              even if immediateFlush is set to false. This also guarantees
>>>>>>> +              the data is written to disk but is more efficient.
>>>>>>> +              </p>
>>>>>>> +            </td>
>>>>>>> +          </tr>
>>>>>>> +          <tr>
>>>>>>> +            <td>regionLength</td>
>>>>>>> +            <td>int</td>
>>>>>>> +            <td>The length of the mapped region, defaults to 32 MB
>>>>>>> +              (32 * 1024 * 1024 bytes). This parameter must be a value
>>>>>>> +              between 256 and 1,073,741,824 (1 GB or 2^30);
>>>>>>> +              values outside this range will be adjusted to the closest valid
>>>>>>> +              value.
>>>>>>> +              Log4j will round the specified value up to the nearest power of two.</td>
>>>>>>> +          </tr>
>>>>>>> +          <tr>
>>>>>>> +            <td>layout</td>
>>>>>>> +            <td>Layout</td>
>>>>>>> +            <td>The Layout to use to format the LogEvent</td>
>>>>>>> +          </tr>
>>>>>>> +          <tr>
>>>>>>> +            <td>name</td>
>>>>>>> +            <td>String</td>
>>>>>>> +            <td>The name of the Appender.</td>
>>>>>>> +          </tr>
>>>>>>> +          <tr>
>>>>>>> +            <td>ignoreExceptions</td>
>>>>>>> +            <td>boolean</td>
>>>>>>> +            <td>The default is <code>true</code>, causing exceptions encountered while appending events to be
>>>>>>> +              internally logged and then ignored. When set to <code>false</code> exceptions will be propagated to the
>>>>>>> +              caller, instead. You must set this to <code>false</code> when wrapping this Appender in a
>>>>>>> +              <a href="#FailoverAppender">FailoverAppender</a>.</td>
>>>>>>> +          </tr>
>>>>>>> +        </table>
>>>>>>> +        <p>
>>>>>>> +          Here is a sample MemoryMappedFile configuration:
>>>>>>> +        </p>
>>>>>>> +
>>>>>>> +          <pre class="prettyprint linenums"><![CDATA[<?xml version="1.0" encoding="UTF-8"?>
>>>>>>> +<Configuration status="warn" name="MyApp" packages="">
>>>>>>> +  <Appenders>
>>>>>>> +    <MemoryMappedFile name="MyFile" fileName="logs/app.log">
>>>>>>> +      <PatternLayout>
>>>>>>> +        <Pattern>%d %p %c{1.} [%t] %m%n</Pattern>
>>>>>>> +      </PatternLayout>
>>>>>>> +    </MemoryMappedFile>
>>>>>>> +  </Appenders>
>>>>>>> +  <Loggers>
>>>>>>> +    <Root level="error">
>>>>>>> +      <AppenderRef ref="MyFile"/>
>>>>>>> +    </Root>
>>>>>>> +  </Loggers>
>>>>>>> +</Configuration>]]></pre>
>>>>>>> +      </subsection>
>>>>>>>          <a name="NoSQLAppender"/>
>>>>>>>          <subsection name="NoSQLAppender">
>>>>>>>            <p>The NoSQLAppender writes log events to a NoSQL database using an internal lightweight provider interface.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> -- 
>>>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org 
>>>>>>> Java Persistence with Hibernate, Second Edition
>>>>>>> JUnit in Action, Second Edition
>>>>>>> Spring Batch in Action
>>>>>>> Blog: http://garygregory.wordpress.com 
>>>>>>> Home: http://garygregory.com/
>>>>>>> Tweet! http://twitter.com/GaryGregory
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org 
>>>>> Java Persistence with Hibernate, Second Edition
>>>>> JUnit in Action, Second Edition
>>>>> Spring Batch in Action
>>>>> Blog: http://garygregory.wordpress.com 
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Matt Sicker <bo...@gmail.com>
> 
> 
> 
> -- 
> Matt Sicker <bo...@gmail.com>

Re: [1/3] git commit: LOG4J2-431 MemoryMappedFileAppender manual page

Posted by Matt Sicker <bo...@gmail.com>.
You should on rebase to the branch point that you may have that hasn't been
pushed anywhere. So for instance, if you have your own local branch and
never push it, it works just fine to keep doing rebase. However, if you
push out your branch like I've done a few times so far, then you need to
merge instead of rebase.

On 17 September 2014 18:49, Remko Popma <re...@gmail.com> wrote:

> I wonder what I did wrong... I did:
> * change appenders.xml and changes.xml
> * commit locally (not commit and push)
> * rebase with origin/master
> ...and got a lot of conflicts.
>
> The changes.xml conflict is expected, but it's marking all files I added
> (MemoryMappedFileAppender.java, etc) as conflicting additions now...
>
> Should I have pushed my local changes to the remote 431 branch before
> rebasing with origin/master?
>
>
> On Thursday, September 18, 2014, Remko Popma <re...@gmail.com>
> wrote:
>
>> I rephrased it but when I tried to rebase the branch I got tons of
>> conflicts and got stuck. I'll try again tonight.
>>
>> Sent from my iPhone
>>
>> On 2014/09/18, at 1:55, Matt Sicker <bo...@gmail.com> wrote:
>>
>> I think it would definitely be a good idea to mention "since 2.1" or a
>> similar message. That's rather important since we don't maintain past
>> versions of the website manual.
>>
>> On 17 September 2014 11:13, Gary Gregory <ga...@gmail.com> wrote:
>>
>>> I would say nothing, otherwise, we should go around all of the docs and
>>> put "beta" on all the new stuff. I think the docs maybe could say "since
>>> 2.1" or "new" for the new stuff. But it is says "new" or "beta" you have to
>>> go edit that again when we release. I think it is best to have a "what's
>>> new section" that tracks what was added in each version.
>>>
>>> Gary
>>>
>>> On Wed, Sep 17, 2014 at 12:02 PM, Remko Popma <re...@gmail.com>
>>> wrote:
>>>
>>>> Shall I replace "Experimental" with "Beta" in the docs for this
>>>> component then until 2.1 final? I'm fine with that.
>>>>
>>>> On Thu, Sep 18, 2014 at 12:48 AM, Gary Gregory <ga...@gmail.com>
>>>> wrote:
>>>>
>>>>> I do not think this should be marker "experimental".
>>>>>
>>>>> If it is brought into trunk for 2.1 and we have a beta, we can say,
>>>>> this and that are new, it's a beta.
>>>>>
>>>>> Gary
>>>>>
>>>>> ---------- Forwarded message ----------
>>>>> From: <rp...@apache.org>
>>>>> Date: Wed, Sep 17, 2014 at 11:45 AM
>>>>> Subject: [1/3] git commit: LOG4J2-431 MemoryMappedFileAppender manual
>>>>> page
>>>>> To: commits@logging.apache.org
>>>>>
>>>>>
>>>>> Repository: logging-log4j2
>>>>> Updated Branches:
>>>>>   refs/heads/LOG4J2-431 64369f3d7 -> 63aed83d6
>>>>>
>>>>>
>>>>> LOG4J2-431 MemoryMappedFileAppender manual page
>>>>>
>>>>> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
>>>>> Commit:
>>>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/80dafe9e
>>>>> Tree:
>>>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/80dafe9e
>>>>> Diff:
>>>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/80dafe9e
>>>>>
>>>>> Branch: refs/heads/LOG4J2-431
>>>>> Commit: 80dafe9e85c28f89d5b4d411d8b28c33642f411f
>>>>> Parents: 64369f3
>>>>> Author: rpopma <rp...@apache.org>
>>>>> Authored: Thu Sep 18 00:42:50 2014 +0900
>>>>> Committer: rpopma <rp...@apache.org>
>>>>> Committed: Thu Sep 18 00:42:50 2014 +0900
>>>>>
>>>>> ----------------------------------------------------------------------
>>>>>  src/site/xdoc/manual/appenders.xml | 131
>>>>> ++++++++++++++++++++++++++++++++
>>>>>  1 file changed, 131 insertions(+)
>>>>> ----------------------------------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/80dafe9e/src/site/xdoc/manual/appenders.xml
>>>>> ----------------------------------------------------------------------
>>>>> diff --git a/src/site/xdoc/manual/appenders.xml
>>>>> b/src/site/xdoc/manual/appenders.xml
>>>>> index 032983b..7d47f78 100644
>>>>> --- a/src/site/xdoc/manual/appenders.xml
>>>>> +++ b/src/site/xdoc/manual/appenders.xml
>>>>> @@ -1320,6 +1320,137 @@ public class JpaLogEntity extends
>>>>> AbstractLogEventWrapperEntity {
>>>>>      ...
>>>>>  }]]></pre>
>>>>>          </subsection>
>>>>> +      <a name="MemoryMappedFileAppender" />
>>>>> +      <subsection name="MemoryMappedFileAppender">
>>>>> +        <p><i>Experimental. This has been tested on several
>>>>> platforms, but this is
>>>>> +          a new component (since 2.1) and does not yet have much
>>>>> track record.</i></p>
>>>>> +        <p>
>>>>> +          The MemoryMappedFileAppender maps a part of the specified
>>>>> file into memory
>>>>> +          and writes log events to this memory, relying on the
>>>>> operating system's
>>>>> +          virtual memory manager to synchronize the changes to the
>>>>> storage device.
>>>>> +          The main benefit of doing this is I/O performance. Instead
>>>>> of making system
>>>>> +          calls to write to disk, this appender can simply change the
>>>>> program's local memory,
>>>>> +          which is orders of magnitude faster. Also, in most
>>>>> operating systems the memory
>>>>> +          region mapped actually is the kernel's <a href="
>>>>> http://en.wikipedia.org/wiki/Page_cache">page
>>>>> +          cache</a> (file cache), meaning that no copies need to be
>>>>> created in user space.
>>>>> +          (TODO: performance tests that compare performance of this
>>>>> appender to
>>>>> +          RandomAccessFileAppender and FileAppender.)
>>>>> +        </p>
>>>>> +        <p>
>>>>> +          There is some overhead with mapping a file region into
>>>>> memory,
>>>>> +          especially very large regions (half a gigabyte or more).
>>>>> +          The default region size is 32 MB, which should strike a
>>>>> reasonable balance
>>>>> +          between the frequency and the duration of remap operations.
>>>>> +          (TODO: performance test remapping various sizes.)
>>>>> +        </p>
>>>>> +        <p>
>>>>> +          Similar to the FileAppender and the
>>>>> RandomAccessFileAppender,
>>>>> +          MemoryMappedFileAppender uses a MemoryMappedFileManager to
>>>>> actually perform the
>>>>> +          file I/O. While MemoryMappedFileAppender from different
>>>>> Configurations
>>>>> +          cannot be shared, the MemoryMappedFileManagers can be if
>>>>> the Manager is
>>>>> +          accessible. For example, two web applications in a servlet
>>>>> container can have
>>>>> +          their own configuration and safely write to the same file
>>>>> if Log4j
>>>>> +          is in a ClassLoader that is common to both of them.
>>>>> +        </p>
>>>>> +        <table>
>>>>> +          <caption align="top">MemoryMappedFileAppender
>>>>> Parameters</caption>
>>>>> +          <tr>
>>>>> +            <th>Parameter Name</th>
>>>>> +            <th>Type</th>
>>>>> +            <th>Description</th>
>>>>> +          </tr>
>>>>> +          <tr>
>>>>> +            <td>append</td>
>>>>> +            <td>boolean</td>
>>>>> +            <td>When true - the default, records will be appended to
>>>>> the end
>>>>> +              of the file. When set to false, the file will be
>>>>> cleared before
>>>>> +              new records are written.
>>>>> +            </td>
>>>>> +          </tr>
>>>>> +          <tr>
>>>>> +            <td>fileName</td>
>>>>> +            <td>String</td>
>>>>> +            <td>The name of the file to write to. If the file, or any
>>>>> of its
>>>>> +              parent directories, do not exist, they will be created.
>>>>> +            </td>
>>>>> +          </tr>
>>>>> +          <tr>
>>>>> +            <td>filters</td>
>>>>> +            <td>Filter</td>
>>>>> +            <td>A Filter to determine if the event should be handled
>>>>> by this
>>>>> +              Appender. More than one Filter may be used by using a
>>>>> CompositeFilter.
>>>>> +            </td>
>>>>> +          </tr>
>>>>> +          <tr>
>>>>> +            <td>immediateFlush</td>
>>>>> +            <td>boolean</td>
>>>>> +            <td>
>>>>> +              <p>When set to true, each write will be followed by a
>>>>> +                call to <a href="
>>>>> http://docs.oracle.com/javase/7/docs/api/java/nio/MappedByteBuffer.html#force()
>>>>> ">MappedByteBuffer.force()</a>.
>>>>> +            This will guarantee the data is written to the storage
>>>>> device.
>>>>> +              </p>
>>>>> +              <p>The default for this parameter is <code>false</code>.
>>>>> +                This means that the data is written to the storage
>>>>> device even
>>>>> +                if the Java process crashes, but there may be data
>>>>> loss if the
>>>>> +                operating system crashes. Note that manually forcing
>>>>> a sync on every
>>>>> +                log event loses most of the performance benefits of
>>>>> using a memory mapped file.</p>
>>>>> +              <p>Flushing after every write is only useful when using
>>>>> this
>>>>> +              appender with synchronous loggers. Asynchronous loggers
>>>>> and
>>>>> +              appenders will automatically flush at the end of a
>>>>> batch of events,
>>>>> +              even if immediateFlush is set to false. This also
>>>>> guarantees
>>>>> +              the data is written to disk but is more efficient.
>>>>> +              </p>
>>>>> +            </td>
>>>>> +          </tr>
>>>>> +          <tr>
>>>>> +            <td>regionLength</td>
>>>>> +            <td>int</td>
>>>>> +            <td>The length of the mapped region, defaults to 32 MB
>>>>> +              (32 * 1024 * 1024 bytes). This parameter must be a value
>>>>> +              between 256 and 1,073,741,824 (1 GB or 2^30);
>>>>> +              values outside this range will be adjusted to the
>>>>> closest valid
>>>>> +              value.
>>>>> +              Log4j will round the specified value up to the nearest
>>>>> power of two.</td>
>>>>> +          </tr>
>>>>> +          <tr>
>>>>> +            <td>layout</td>
>>>>> +            <td>Layout</td>
>>>>> +            <td>The Layout to use to format the LogEvent</td>
>>>>> +          </tr>
>>>>> +          <tr>
>>>>> +            <td>name</td>
>>>>> +            <td>String</td>
>>>>> +            <td>The name of the Appender.</td>
>>>>> +          </tr>
>>>>> +          <tr>
>>>>> +            <td>ignoreExceptions</td>
>>>>> +            <td>boolean</td>
>>>>> +            <td>The default is <code>true</code>, causing exceptions
>>>>> encountered while appending events to be
>>>>> +              internally logged and then ignored. When set to
>>>>> <code>false</code> exceptions will be propagated to the
>>>>> +              caller, instead. You must set this to
>>>>> <code>false</code> when wrapping this Appender in a
>>>>> +              <a href="#FailoverAppender">FailoverAppender</a>.</td>
>>>>> +          </tr>
>>>>> +        </table>
>>>>> +        <p>
>>>>> +          Here is a sample MemoryMappedFile configuration:
>>>>> +        </p>
>>>>> +
>>>>> +          <pre class="prettyprint linenums"><![CDATA[<?xml
>>>>> version="1.0" encoding="UTF-8"?>
>>>>> +<Configuration status="warn" name="MyApp" packages="">
>>>>> +  <Appenders>
>>>>> +    <MemoryMappedFile name="MyFile" fileName="logs/app.log">
>>>>> +      <PatternLayout>
>>>>> +        <Pattern>%d %p %c{1.} [%t] %m%n</Pattern>
>>>>> +      </PatternLayout>
>>>>> +    </MemoryMappedFile>
>>>>> +  </Appenders>
>>>>> +  <Loggers>
>>>>> +    <Root level="error">
>>>>> +      <AppenderRef ref="MyFile"/>
>>>>> +    </Root>
>>>>> +  </Loggers>
>>>>> +</Configuration>]]></pre>
>>>>> +      </subsection>
>>>>>          <a name="NoSQLAppender"/>
>>>>>          <subsection name="NoSQLAppender">
>>>>>            <p>The NoSQLAppender writes log events to a NoSQL database
>>>>> using an internal lightweight provider interface.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>>>> Java Persistence with Hibernate, Second Edition
>>>>> <http://www.manning.com/bauer3/>
>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>>> Blog: http://garygregory.wordpress.com
>>>>> Home: http://garygregory.com/
>>>>> Tweet! http://twitter.com/GaryGregory
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> <http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>>


-- 
Matt Sicker <bo...@gmail.com>

Re: [1/3] git commit: LOG4J2-431 MemoryMappedFileAppender manual page

Posted by Remko Popma <re...@gmail.com>.
I wonder what I did wrong... I did:
* change appenders.xml and changes.xml
* commit locally (not commit and push)
* rebase with origin/master
...and got a lot of conflicts.

The changes.xml conflict is expected, but it's marking all files I added
(MemoryMappedFileAppender.java, etc) as conflicting additions now...

Should I have pushed my local changes to the remote 431 branch before
rebasing with origin/master?

On Thursday, September 18, 2014, Remko Popma <re...@gmail.com> wrote:

> I rephrased it but when I tried to rebase the branch I got tons of
> conflicts and got stuck. I'll try again tonight.
>
> Sent from my iPhone
>
> On 2014/09/18, at 1:55, Matt Sicker <boards@gmail.com
> <javascript:_e(%7B%7D,'cvml','boards@gmail.com');>> wrote:
>
> I think it would definitely be a good idea to mention "since 2.1" or a
> similar message. That's rather important since we don't maintain past
> versions of the website manual.
>
> On 17 September 2014 11:13, Gary Gregory <garydgregory@gmail.com
> <javascript:_e(%7B%7D,'cvml','garydgregory@gmail.com');>> wrote:
>
>> I would say nothing, otherwise, we should go around all of the docs and
>> put "beta" on all the new stuff. I think the docs maybe could say "since
>> 2.1" or "new" for the new stuff. But it is says "new" or "beta" you have to
>> go edit that again when we release. I think it is best to have a "what's
>> new section" that tracks what was added in each version.
>>
>> Gary
>>
>> On Wed, Sep 17, 2014 at 12:02 PM, Remko Popma <remko.popma@gmail.com
>> <javascript:_e(%7B%7D,'cvml','remko.popma@gmail.com');>> wrote:
>>
>>> Shall I replace "Experimental" with "Beta" in the docs for this
>>> component then until 2.1 final? I'm fine with that.
>>>
>>> On Thu, Sep 18, 2014 at 12:48 AM, Gary Gregory <garydgregory@gmail.com
>>> <javascript:_e(%7B%7D,'cvml','garydgregory@gmail.com');>> wrote:
>>>
>>>> I do not think this should be marker "experimental".
>>>>
>>>> If it is brought into trunk for 2.1 and we have a beta, we can say,
>>>> this and that are new, it's a beta.
>>>>
>>>> Gary
>>>>
>>>> ---------- Forwarded message ----------
>>>> From: <rpopma@apache.org
>>>> <javascript:_e(%7B%7D,'cvml','rpopma@apache.org');>>
>>>> Date: Wed, Sep 17, 2014 at 11:45 AM
>>>> Subject: [1/3] git commit: LOG4J2-431 MemoryMappedFileAppender manual
>>>> page
>>>> To: commits@logging.apache.org
>>>> <javascript:_e(%7B%7D,'cvml','commits@logging.apache.org');>
>>>>
>>>>
>>>> Repository: logging-log4j2
>>>> Updated Branches:
>>>>   refs/heads/LOG4J2-431 64369f3d7 -> 63aed83d6
>>>>
>>>>
>>>> LOG4J2-431 MemoryMappedFileAppender manual page
>>>>
>>>> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
>>>> Commit:
>>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/80dafe9e
>>>> Tree:
>>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/80dafe9e
>>>> Diff:
>>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/80dafe9e
>>>>
>>>> Branch: refs/heads/LOG4J2-431
>>>> Commit: 80dafe9e85c28f89d5b4d411d8b28c33642f411f
>>>> Parents: 64369f3
>>>> Author: rpopma <rpopma@apache.org
>>>> <javascript:_e(%7B%7D,'cvml','rpopma@apache.org');>>
>>>> Authored: Thu Sep 18 00:42:50 2014 +0900
>>>> Committer: rpopma <rpopma@apache.org
>>>> <javascript:_e(%7B%7D,'cvml','rpopma@apache.org');>>
>>>> Committed: Thu Sep 18 00:42:50 2014 +0900
>>>>
>>>> ----------------------------------------------------------------------
>>>>  src/site/xdoc/manual/appenders.xml | 131
>>>> ++++++++++++++++++++++++++++++++
>>>>  1 file changed, 131 insertions(+)
>>>> ----------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/80dafe9e/src/site/xdoc/manual/appenders.xml
>>>> ----------------------------------------------------------------------
>>>> diff --git a/src/site/xdoc/manual/appenders.xml
>>>> b/src/site/xdoc/manual/appenders.xml
>>>> index 032983b..7d47f78 100644
>>>> --- a/src/site/xdoc/manual/appenders.xml
>>>> +++ b/src/site/xdoc/manual/appenders.xml
>>>> @@ -1320,6 +1320,137 @@ public class JpaLogEntity extends
>>>> AbstractLogEventWrapperEntity {
>>>>      ...
>>>>  }]]></pre>
>>>>          </subsection>
>>>> +      <a name="MemoryMappedFileAppender" />
>>>> +      <subsection name="MemoryMappedFileAppender">
>>>> +        <p><i>Experimental. This has been tested on several platforms,
>>>> but this is
>>>> +          a new component (since 2.1) and does not yet have much track
>>>> record.</i></p>
>>>> +        <p>
>>>> +          The MemoryMappedFileAppender maps a part of the specified
>>>> file into memory
>>>> +          and writes log events to this memory, relying on the
>>>> operating system's
>>>> +          virtual memory manager to synchronize the changes to the
>>>> storage device.
>>>> +          The main benefit of doing this is I/O performance. Instead
>>>> of making system
>>>> +          calls to write to disk, this appender can simply change the
>>>> program's local memory,
>>>> +          which is orders of magnitude faster. Also, in most operating
>>>> systems the memory
>>>> +          region mapped actually is the kernel's <a href="
>>>> http://en.wikipedia.org/wiki/Page_cache">page
>>>> +          cache</a> (file cache), meaning that no copies need to be
>>>> created in user space.
>>>> +          (TODO: performance tests that compare performance of this
>>>> appender to
>>>> +          RandomAccessFileAppender and FileAppender.)
>>>> +        </p>
>>>> +        <p>
>>>> +          There is some overhead with mapping a file region into
>>>> memory,
>>>> +          especially very large regions (half a gigabyte or more).
>>>> +          The default region size is 32 MB, which should strike a
>>>> reasonable balance
>>>> +          between the frequency and the duration of remap operations.
>>>> +          (TODO: performance test remapping various sizes.)
>>>> +        </p>
>>>> +        <p>
>>>> +          Similar to the FileAppender and the RandomAccessFileAppender,
>>>> +          MemoryMappedFileAppender uses a MemoryMappedFileManager to
>>>> actually perform the
>>>> +          file I/O. While MemoryMappedFileAppender from different
>>>> Configurations
>>>> +          cannot be shared, the MemoryMappedFileManagers can be if the
>>>> Manager is
>>>> +          accessible. For example, two web applications in a servlet
>>>> container can have
>>>> +          their own configuration and safely write to the same file if
>>>> Log4j
>>>> +          is in a ClassLoader that is common to both of them.
>>>> +        </p>
>>>> +        <table>
>>>> +          <caption align="top">MemoryMappedFileAppender
>>>> Parameters</caption>
>>>> +          <tr>
>>>> +            <th>Parameter Name</th>
>>>> +            <th>Type</th>
>>>> +            <th>Description</th>
>>>> +          </tr>
>>>> +          <tr>
>>>> +            <td>append</td>
>>>> +            <td>boolean</td>
>>>> +            <td>When true - the default, records will be appended to
>>>> the end
>>>> +              of the file. When set to false, the file will be cleared
>>>> before
>>>> +              new records are written.
>>>> +            </td>
>>>> +          </tr>
>>>> +          <tr>
>>>> +            <td>fileName</td>
>>>> +            <td>String</td>
>>>> +            <td>The name of the file to write to. If the file, or any
>>>> of its
>>>> +              parent directories, do not exist, they will be created.
>>>> +            </td>
>>>> +          </tr>
>>>> +          <tr>
>>>> +            <td>filters</td>
>>>> +            <td>Filter</td>
>>>> +            <td>A Filter to determine if the event should be handled
>>>> by this
>>>> +              Appender. More than one Filter may be used by using a
>>>> CompositeFilter.
>>>> +            </td>
>>>> +          </tr>
>>>> +          <tr>
>>>> +            <td>immediateFlush</td>
>>>> +            <td>boolean</td>
>>>> +            <td>
>>>> +              <p>When set to true, each write will be followed by a
>>>> +                call to <a href="
>>>> http://docs.oracle.com/javase/7/docs/api/java/nio/MappedByteBuffer.html#force()
>>>> ">MappedByteBuffer.force()</a>.
>>>> +            This will guarantee the data is written to the storage
>>>> device.
>>>> +              </p>
>>>> +              <p>The default for this parameter is <code>false</code>.
>>>> +                This means that the data is written to the storage
>>>> device even
>>>> +                if the Java process crashes, but there may be data
>>>> loss if the
>>>> +                operating system crashes. Note that manually forcing a
>>>> sync on every
>>>> +                log event loses most of the performance benefits of
>>>> using a memory mapped file.</p>
>>>> +              <p>Flushing after every write is only useful when using
>>>> this
>>>> +              appender with synchronous loggers. Asynchronous loggers
>>>> and
>>>> +              appenders will automatically flush at the end of a batch
>>>> of events,
>>>> +              even if immediateFlush is set to false. This also
>>>> guarantees
>>>> +              the data is written to disk but is more efficient.
>>>> +              </p>
>>>> +            </td>
>>>> +          </tr>
>>>> +          <tr>
>>>> +            <td>regionLength</td>
>>>> +            <td>int</td>
>>>> +            <td>The length of the mapped region, defaults to 32 MB
>>>> +              (32 * 1024 * 1024 bytes). This parameter must be a value
>>>> +              between 256 and 1,073,741,824 (1 GB or 2^30);
>>>> +              values outside this range will be adjusted to the
>>>> closest valid
>>>> +              value.
>>>> +              Log4j will round the specified value up to the nearest
>>>> power of two.</td>
>>>> +          </tr>
>>>> +          <tr>
>>>> +            <td>layout</td>
>>>> +            <td>Layout</td>
>>>> +            <td>The Layout to use to format the LogEvent</td>
>>>> +          </tr>
>>>> +          <tr>
>>>> +            <td>name</td>
>>>> +            <td>String</td>
>>>> +            <td>The name of the Appender.</td>
>>>> +          </tr>
>>>> +          <tr>
>>>> +            <td>ignoreExceptions</td>
>>>> +            <td>boolean</td>
>>>> +            <td>The default is <code>true</code>, causing exceptions
>>>> encountered while appending events to be
>>>> +              internally logged and then ignored. When set to
>>>> <code>false</code> exceptions will be propagated to the
>>>> +              caller, instead. You must set this to <code>false</code>
>>>> when wrapping this Appender in a
>>>> +              <a href="#FailoverAppender">FailoverAppender</a>.</td>
>>>> +          </tr>
>>>> +        </table>
>>>> +        <p>
>>>> +          Here is a sample MemoryMappedFile configuration:
>>>> +        </p>
>>>> +
>>>> +          <pre class="prettyprint linenums"><![CDATA[<?xml
>>>> version="1.0" encoding="UTF-8"?>
>>>> +<Configuration status="warn" name="MyApp" packages="">
>>>> +  <Appenders>
>>>> +    <MemoryMappedFile name="MyFile" fileName="logs/app.log">
>>>> +      <PatternLayout>
>>>> +        <Pattern>%d %p %c{1.} [%t] %m%n</Pattern>
>>>> +      </PatternLayout>
>>>> +    </MemoryMappedFile>
>>>> +  </Appenders>
>>>> +  <Loggers>
>>>> +    <Root level="error">
>>>> +      <AppenderRef ref="MyFile"/>
>>>> +    </Root>
>>>> +  </Loggers>
>>>> +</Configuration>]]></pre>
>>>> +      </subsection>
>>>>          <a name="NoSQLAppender"/>
>>>>          <subsection name="NoSQLAppender">
>>>>            <p>The NoSQLAppender writes log events to a NoSQL database
>>>> using an internal lightweight provider interface.
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgregory@gmail.com
>>>> <javascript:_e(%7B%7D,'cvml','garydgregory@gmail.com');> | ggregory@apache.org
>>>> <javascript:_e(%7B%7D,'cvml','ggregory@apache.org');>
>>>> Java Persistence with Hibernate, Second Edition
>>>> <http://www.manning.com/bauer3/>
>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>>> Spring Batch in Action <http://www.manning.com/templier/>
>>>> Blog: http://garygregory.wordpress.com
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>>>>
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com
>> <javascript:_e(%7B%7D,'cvml','garydgregory@gmail.com');> | ggregory@apache.org
>> <javascript:_e(%7B%7D,'cvml','ggregory@apache.org');>
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> Matt Sicker <boards@gmail.com
> <javascript:_e(%7B%7D,'cvml','boards@gmail.com');>>
>
>

Re: [1/3] git commit: LOG4J2-431 MemoryMappedFileAppender manual page

Posted by Remko Popma <re...@gmail.com>.
I rephrased it but when I tried to rebase the branch I got tons of conflicts and got stuck. I'll try again tonight. 

Sent from my iPhone

> On 2014/09/18, at 1:55, Matt Sicker <bo...@gmail.com> wrote:
> 
> I think it would definitely be a good idea to mention "since 2.1" or a similar message. That's rather important since we don't maintain past versions of the website manual.
> 
>> On 17 September 2014 11:13, Gary Gregory <ga...@gmail.com> wrote:
>> I would say nothing, otherwise, we should go around all of the docs and put "beta" on all the new stuff. I think the docs maybe could say "since 2.1" or "new" for the new stuff. But it is says "new" or "beta" you have to go edit that again when we release. I think it is best to have a "what's new section" that tracks what was added in each version.
>> 
>> Gary
>> 
>>> On Wed, Sep 17, 2014 at 12:02 PM, Remko Popma <re...@gmail.com> wrote:
>>> Shall I replace "Experimental" with "Beta" in the docs for this component then until 2.1 final? I'm fine with that.
>>> 
>>>> On Thu, Sep 18, 2014 at 12:48 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>> I do not think this should be marker "experimental".
>>>> 
>>>> If it is brought into trunk for 2.1 and we have a beta, we can say, this and that are new, it's a beta.
>>>> 
>>>> Gary
>>>> 
>>>> ---------- Forwarded message ----------
>>>> From: <rp...@apache.org>
>>>> Date: Wed, Sep 17, 2014 at 11:45 AM
>>>> Subject: [1/3] git commit: LOG4J2-431 MemoryMappedFileAppender manual page
>>>> To: commits@logging.apache.org
>>>> 
>>>> 
>>>> Repository: logging-log4j2
>>>> Updated Branches:
>>>>   refs/heads/LOG4J2-431 64369f3d7 -> 63aed83d6
>>>> 
>>>> 
>>>> LOG4J2-431 MemoryMappedFileAppender manual page
>>>> 
>>>> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
>>>> Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/80dafe9e
>>>> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/80dafe9e
>>>> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/80dafe9e
>>>> 
>>>> Branch: refs/heads/LOG4J2-431
>>>> Commit: 80dafe9e85c28f89d5b4d411d8b28c33642f411f
>>>> Parents: 64369f3
>>>> Author: rpopma <rp...@apache.org>
>>>> Authored: Thu Sep 18 00:42:50 2014 +0900
>>>> Committer: rpopma <rp...@apache.org>
>>>> Committed: Thu Sep 18 00:42:50 2014 +0900
>>>> 
>>>> ----------------------------------------------------------------------
>>>>  src/site/xdoc/manual/appenders.xml | 131 ++++++++++++++++++++++++++++++++
>>>>  1 file changed, 131 insertions(+)
>>>> ----------------------------------------------------------------------
>>>> 
>>>> 
>>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/80dafe9e/src/site/xdoc/manual/appenders.xml
>>>> ----------------------------------------------------------------------
>>>> diff --git a/src/site/xdoc/manual/appenders.xml b/src/site/xdoc/manual/appenders.xml
>>>> index 032983b..7d47f78 100644
>>>> --- a/src/site/xdoc/manual/appenders.xml
>>>> +++ b/src/site/xdoc/manual/appenders.xml
>>>> @@ -1320,6 +1320,137 @@ public class JpaLogEntity extends AbstractLogEventWrapperEntity {
>>>>      ...
>>>>  }]]></pre>
>>>>          </subsection>
>>>> +      <a name="MemoryMappedFileAppender" />
>>>> +      <subsection name="MemoryMappedFileAppender">
>>>> +        <p><i>Experimental. This has been tested on several platforms, but this is
>>>> +          a new component (since 2.1) and does not yet have much track record.</i></p>
>>>> +        <p>
>>>> +          The MemoryMappedFileAppender maps a part of the specified file into memory
>>>> +          and writes log events to this memory, relying on the operating system's
>>>> +          virtual memory manager to synchronize the changes to the storage device.
>>>> +          The main benefit of doing this is I/O performance. Instead of making system
>>>> +          calls to write to disk, this appender can simply change the program's local memory,
>>>> +          which is orders of magnitude faster. Also, in most operating systems the memory
>>>> +          region mapped actually is the kernel's <a href="http://en.wikipedia.org/wiki/Page_cache">page
>>>> +          cache</a> (file cache), meaning that no copies need to be created in user space.
>>>> +          (TODO: performance tests that compare performance of this appender to
>>>> +          RandomAccessFileAppender and FileAppender.)
>>>> +        </p>
>>>> +        <p>
>>>> +          There is some overhead with mapping a file region into memory,
>>>> +          especially very large regions (half a gigabyte or more).
>>>> +          The default region size is 32 MB, which should strike a reasonable balance
>>>> +          between the frequency and the duration of remap operations.
>>>> +          (TODO: performance test remapping various sizes.)
>>>> +        </p>
>>>> +        <p>
>>>> +          Similar to the FileAppender and the RandomAccessFileAppender,
>>>> +          MemoryMappedFileAppender uses a MemoryMappedFileManager to actually perform the
>>>> +          file I/O. While MemoryMappedFileAppender from different Configurations
>>>> +          cannot be shared, the MemoryMappedFileManagers can be if the Manager is
>>>> +          accessible. For example, two web applications in a servlet container can have
>>>> +          their own configuration and safely write to the same file if Log4j
>>>> +          is in a ClassLoader that is common to both of them.
>>>> +        </p>
>>>> +        <table>
>>>> +          <caption align="top">MemoryMappedFileAppender Parameters</caption>
>>>> +          <tr>
>>>> +            <th>Parameter Name</th>
>>>> +            <th>Type</th>
>>>> +            <th>Description</th>
>>>> +          </tr>
>>>> +          <tr>
>>>> +            <td>append</td>
>>>> +            <td>boolean</td>
>>>> +            <td>When true - the default, records will be appended to the end
>>>> +              of the file. When set to false, the file will be cleared before
>>>> +              new records are written.
>>>> +            </td>
>>>> +          </tr>
>>>> +          <tr>
>>>> +            <td>fileName</td>
>>>> +            <td>String</td>
>>>> +            <td>The name of the file to write to. If the file, or any of its
>>>> +              parent directories, do not exist, they will be created.
>>>> +            </td>
>>>> +          </tr>
>>>> +          <tr>
>>>> +            <td>filters</td>
>>>> +            <td>Filter</td>
>>>> +            <td>A Filter to determine if the event should be handled by this
>>>> +              Appender. More than one Filter may be used by using a CompositeFilter.
>>>> +            </td>
>>>> +          </tr>
>>>> +          <tr>
>>>> +            <td>immediateFlush</td>
>>>> +            <td>boolean</td>
>>>> +            <td>
>>>> +              <p>When set to true, each write will be followed by a
>>>> +                call to <a href="http://docs.oracle.com/javase/7/docs/api/java/nio/MappedByteBuffer.html#force()">MappedByteBuffer.force()</a>.
>>>> +            This will guarantee the data is written to the storage device.
>>>> +              </p>
>>>> +              <p>The default for this parameter is <code>false</code>.
>>>> +                This means that the data is written to the storage device even
>>>> +                if the Java process crashes, but there may be data loss if the
>>>> +                operating system crashes. Note that manually forcing a sync on every
>>>> +                log event loses most of the performance benefits of using a memory mapped file.</p>
>>>> +              <p>Flushing after every write is only useful when using this
>>>> +              appender with synchronous loggers. Asynchronous loggers and
>>>> +              appenders will automatically flush at the end of a batch of events,
>>>> +              even if immediateFlush is set to false. This also guarantees
>>>> +              the data is written to disk but is more efficient.
>>>> +              </p>
>>>> +            </td>
>>>> +          </tr>
>>>> +          <tr>
>>>> +            <td>regionLength</td>
>>>> +            <td>int</td>
>>>> +            <td>The length of the mapped region, defaults to 32 MB
>>>> +              (32 * 1024 * 1024 bytes). This parameter must be a value
>>>> +              between 256 and 1,073,741,824 (1 GB or 2^30);
>>>> +              values outside this range will be adjusted to the closest valid
>>>> +              value.
>>>> +              Log4j will round the specified value up to the nearest power of two.</td>
>>>> +          </tr>
>>>> +          <tr>
>>>> +            <td>layout</td>
>>>> +            <td>Layout</td>
>>>> +            <td>The Layout to use to format the LogEvent</td>
>>>> +          </tr>
>>>> +          <tr>
>>>> +            <td>name</td>
>>>> +            <td>String</td>
>>>> +            <td>The name of the Appender.</td>
>>>> +          </tr>
>>>> +          <tr>
>>>> +            <td>ignoreExceptions</td>
>>>> +            <td>boolean</td>
>>>> +            <td>The default is <code>true</code>, causing exceptions encountered while appending events to be
>>>> +              internally logged and then ignored. When set to <code>false</code> exceptions will be propagated to the
>>>> +              caller, instead. You must set this to <code>false</code> when wrapping this Appender in a
>>>> +              <a href="#FailoverAppender">FailoverAppender</a>.</td>
>>>> +          </tr>
>>>> +        </table>
>>>> +        <p>
>>>> +          Here is a sample MemoryMappedFile configuration:
>>>> +        </p>
>>>> +
>>>> +          <pre class="prettyprint linenums"><![CDATA[<?xml version="1.0" encoding="UTF-8"?>
>>>> +<Configuration status="warn" name="MyApp" packages="">
>>>> +  <Appenders>
>>>> +    <MemoryMappedFile name="MyFile" fileName="logs/app.log">
>>>> +      <PatternLayout>
>>>> +        <Pattern>%d %p %c{1.} [%t] %m%n</Pattern>
>>>> +      </PatternLayout>
>>>> +    </MemoryMappedFile>
>>>> +  </Appenders>
>>>> +  <Loggers>
>>>> +    <Root level="error">
>>>> +      <AppenderRef ref="MyFile"/>
>>>> +    </Root>
>>>> +  </Loggers>
>>>> +</Configuration>]]></pre>
>>>> +      </subsection>
>>>>          <a name="NoSQLAppender"/>
>>>>          <subsection name="NoSQLAppender">
>>>>            <p>The NoSQLAppender writes log events to a NoSQL database using an internal lightweight provider interface.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org 
>>>> Java Persistence with Hibernate, Second Edition
>>>> JUnit in Action, Second Edition
>>>> Spring Batch in Action
>>>> Blog: http://garygregory.wordpress.com 
>>>> Home: http://garygregory.com/
>>>> Tweet! http://twitter.com/GaryGregory
>> 
>> 
>> 
>> -- 
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org 
>> Java Persistence with Hibernate, Second Edition
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> Blog: http://garygregory.wordpress.com 
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
> 
> 
> 
> -- 
> Matt Sicker <bo...@gmail.com>

Re: [1/3] git commit: LOG4J2-431 MemoryMappedFileAppender manual page

Posted by Matt Sicker <bo...@gmail.com>.
I think it would definitely be a good idea to mention "since 2.1" or a
similar message. That's rather important since we don't maintain past
versions of the website manual.

On 17 September 2014 11:13, Gary Gregory <ga...@gmail.com> wrote:

> I would say nothing, otherwise, we should go around all of the docs and
> put "beta" on all the new stuff. I think the docs maybe could say "since
> 2.1" or "new" for the new stuff. But it is says "new" or "beta" you have to
> go edit that again when we release. I think it is best to have a "what's
> new section" that tracks what was added in each version.
>
> Gary
>
> On Wed, Sep 17, 2014 at 12:02 PM, Remko Popma <re...@gmail.com>
> wrote:
>
>> Shall I replace "Experimental" with "Beta" in the docs for this component
>> then until 2.1 final? I'm fine with that.
>>
>> On Thu, Sep 18, 2014 at 12:48 AM, Gary Gregory <ga...@gmail.com>
>> wrote:
>>
>>> I do not think this should be marker "experimental".
>>>
>>> If it is brought into trunk for 2.1 and we have a beta, we can say, this
>>> and that are new, it's a beta.
>>>
>>> Gary
>>>
>>> ---------- Forwarded message ----------
>>> From: <rp...@apache.org>
>>> Date: Wed, Sep 17, 2014 at 11:45 AM
>>> Subject: [1/3] git commit: LOG4J2-431 MemoryMappedFileAppender manual
>>> page
>>> To: commits@logging.apache.org
>>>
>>>
>>> Repository: logging-log4j2
>>> Updated Branches:
>>>   refs/heads/LOG4J2-431 64369f3d7 -> 63aed83d6
>>>
>>>
>>> LOG4J2-431 MemoryMappedFileAppender manual page
>>>
>>> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
>>> Commit:
>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/80dafe9e
>>> Tree:
>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/80dafe9e
>>> Diff:
>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/80dafe9e
>>>
>>> Branch: refs/heads/LOG4J2-431
>>> Commit: 80dafe9e85c28f89d5b4d411d8b28c33642f411f
>>> Parents: 64369f3
>>> Author: rpopma <rp...@apache.org>
>>> Authored: Thu Sep 18 00:42:50 2014 +0900
>>> Committer: rpopma <rp...@apache.org>
>>> Committed: Thu Sep 18 00:42:50 2014 +0900
>>>
>>> ----------------------------------------------------------------------
>>>  src/site/xdoc/manual/appenders.xml | 131
>>> ++++++++++++++++++++++++++++++++
>>>  1 file changed, 131 insertions(+)
>>> ----------------------------------------------------------------------
>>>
>>>
>>>
>>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/80dafe9e/src/site/xdoc/manual/appenders.xml
>>> ----------------------------------------------------------------------
>>> diff --git a/src/site/xdoc/manual/appenders.xml
>>> b/src/site/xdoc/manual/appenders.xml
>>> index 032983b..7d47f78 100644
>>> --- a/src/site/xdoc/manual/appenders.xml
>>> +++ b/src/site/xdoc/manual/appenders.xml
>>> @@ -1320,6 +1320,137 @@ public class JpaLogEntity extends
>>> AbstractLogEventWrapperEntity {
>>>      ...
>>>  }]]></pre>
>>>          </subsection>
>>> +      <a name="MemoryMappedFileAppender" />
>>> +      <subsection name="MemoryMappedFileAppender">
>>> +        <p><i>Experimental. This has been tested on several platforms,
>>> but this is
>>> +          a new component (since 2.1) and does not yet have much track
>>> record.</i></p>
>>> +        <p>
>>> +          The MemoryMappedFileAppender maps a part of the specified
>>> file into memory
>>> +          and writes log events to this memory, relying on the
>>> operating system's
>>> +          virtual memory manager to synchronize the changes to the
>>> storage device.
>>> +          The main benefit of doing this is I/O performance. Instead of
>>> making system
>>> +          calls to write to disk, this appender can simply change the
>>> program's local memory,
>>> +          which is orders of magnitude faster. Also, in most operating
>>> systems the memory
>>> +          region mapped actually is the kernel's <a href="
>>> http://en.wikipedia.org/wiki/Page_cache">page
>>> +          cache</a> (file cache), meaning that no copies need to be
>>> created in user space.
>>> +          (TODO: performance tests that compare performance of this
>>> appender to
>>> +          RandomAccessFileAppender and FileAppender.)
>>> +        </p>
>>> +        <p>
>>> +          There is some overhead with mapping a file region into memory,
>>> +          especially very large regions (half a gigabyte or more).
>>> +          The default region size is 32 MB, which should strike a
>>> reasonable balance
>>> +          between the frequency and the duration of remap operations.
>>> +          (TODO: performance test remapping various sizes.)
>>> +        </p>
>>> +        <p>
>>> +          Similar to the FileAppender and the RandomAccessFileAppender,
>>> +          MemoryMappedFileAppender uses a MemoryMappedFileManager to
>>> actually perform the
>>> +          file I/O. While MemoryMappedFileAppender from different
>>> Configurations
>>> +          cannot be shared, the MemoryMappedFileManagers can be if the
>>> Manager is
>>> +          accessible. For example, two web applications in a servlet
>>> container can have
>>> +          their own configuration and safely write to the same file if
>>> Log4j
>>> +          is in a ClassLoader that is common to both of them.
>>> +        </p>
>>> +        <table>
>>> +          <caption align="top">MemoryMappedFileAppender
>>> Parameters</caption>
>>> +          <tr>
>>> +            <th>Parameter Name</th>
>>> +            <th>Type</th>
>>> +            <th>Description</th>
>>> +          </tr>
>>> +          <tr>
>>> +            <td>append</td>
>>> +            <td>boolean</td>
>>> +            <td>When true - the default, records will be appended to
>>> the end
>>> +              of the file. When set to false, the file will be cleared
>>> before
>>> +              new records are written.
>>> +            </td>
>>> +          </tr>
>>> +          <tr>
>>> +            <td>fileName</td>
>>> +            <td>String</td>
>>> +            <td>The name of the file to write to. If the file, or any
>>> of its
>>> +              parent directories, do not exist, they will be created.
>>> +            </td>
>>> +          </tr>
>>> +          <tr>
>>> +            <td>filters</td>
>>> +            <td>Filter</td>
>>> +            <td>A Filter to determine if the event should be handled by
>>> this
>>> +              Appender. More than one Filter may be used by using a
>>> CompositeFilter.
>>> +            </td>
>>> +          </tr>
>>> +          <tr>
>>> +            <td>immediateFlush</td>
>>> +            <td>boolean</td>
>>> +            <td>
>>> +              <p>When set to true, each write will be followed by a
>>> +                call to <a href="
>>> http://docs.oracle.com/javase/7/docs/api/java/nio/MappedByteBuffer.html#force()
>>> ">MappedByteBuffer.force()</a>.
>>> +            This will guarantee the data is written to the storage
>>> device.
>>> +              </p>
>>> +              <p>The default for this parameter is <code>false</code>.
>>> +                This means that the data is written to the storage
>>> device even
>>> +                if the Java process crashes, but there may be data loss
>>> if the
>>> +                operating system crashes. Note that manually forcing a
>>> sync on every
>>> +                log event loses most of the performance benefits of
>>> using a memory mapped file.</p>
>>> +              <p>Flushing after every write is only useful when using
>>> this
>>> +              appender with synchronous loggers. Asynchronous loggers
>>> and
>>> +              appenders will automatically flush at the end of a batch
>>> of events,
>>> +              even if immediateFlush is set to false. This also
>>> guarantees
>>> +              the data is written to disk but is more efficient.
>>> +              </p>
>>> +            </td>
>>> +          </tr>
>>> +          <tr>
>>> +            <td>regionLength</td>
>>> +            <td>int</td>
>>> +            <td>The length of the mapped region, defaults to 32 MB
>>> +              (32 * 1024 * 1024 bytes). This parameter must be a value
>>> +              between 256 and 1,073,741,824 (1 GB or 2^30);
>>> +              values outside this range will be adjusted to the closest
>>> valid
>>> +              value.
>>> +              Log4j will round the specified value up to the nearest
>>> power of two.</td>
>>> +          </tr>
>>> +          <tr>
>>> +            <td>layout</td>
>>> +            <td>Layout</td>
>>> +            <td>The Layout to use to format the LogEvent</td>
>>> +          </tr>
>>> +          <tr>
>>> +            <td>name</td>
>>> +            <td>String</td>
>>> +            <td>The name of the Appender.</td>
>>> +          </tr>
>>> +          <tr>
>>> +            <td>ignoreExceptions</td>
>>> +            <td>boolean</td>
>>> +            <td>The default is <code>true</code>, causing exceptions
>>> encountered while appending events to be
>>> +              internally logged and then ignored. When set to
>>> <code>false</code> exceptions will be propagated to the
>>> +              caller, instead. You must set this to <code>false</code>
>>> when wrapping this Appender in a
>>> +              <a href="#FailoverAppender">FailoverAppender</a>.</td>
>>> +          </tr>
>>> +        </table>
>>> +        <p>
>>> +          Here is a sample MemoryMappedFile configuration:
>>> +        </p>
>>> +
>>> +          <pre class="prettyprint linenums"><![CDATA[<?xml
>>> version="1.0" encoding="UTF-8"?>
>>> +<Configuration status="warn" name="MyApp" packages="">
>>> +  <Appenders>
>>> +    <MemoryMappedFile name="MyFile" fileName="logs/app.log">
>>> +      <PatternLayout>
>>> +        <Pattern>%d %p %c{1.} [%t] %m%n</Pattern>
>>> +      </PatternLayout>
>>> +    </MemoryMappedFile>
>>> +  </Appenders>
>>> +  <Loggers>
>>> +    <Root level="error">
>>> +      <AppenderRef ref="MyFile"/>
>>> +    </Root>
>>> +  </Loggers>
>>> +</Configuration>]]></pre>
>>> +      </subsection>
>>>          <a name="NoSQLAppender"/>
>>>          <subsection name="NoSQLAppender">
>>>            <p>The NoSQLAppender writes log events to a NoSQL database
>>> using an internal lightweight provider interface.
>>>
>>>
>>>
>>>
>>> --
>>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> Java Persistence with Hibernate, Second Edition
>>> <http://www.manning.com/bauer3/>
>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>>> Spring Batch in Action <http://www.manning.com/templier/>
>>> Blog: http://garygregory.wordpress.com
>>> Home: http://garygregory.com/
>>> Tweet! http://twitter.com/GaryGregory
>>>
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>



-- 
Matt Sicker <bo...@gmail.com>

Re: [1/3] git commit: LOG4J2-431 MemoryMappedFileAppender manual page

Posted by Gary Gregory <ga...@gmail.com>.
I would say nothing, otherwise, we should go around all of the docs and put
"beta" on all the new stuff. I think the docs maybe could say "since 2.1"
or "new" for the new stuff. But it is says "new" or "beta" you have to go
edit that again when we release. I think it is best to have a "what's new
section" that tracks what was added in each version.

Gary

On Wed, Sep 17, 2014 at 12:02 PM, Remko Popma <re...@gmail.com> wrote:

> Shall I replace "Experimental" with "Beta" in the docs for this component
> then until 2.1 final? I'm fine with that.
>
> On Thu, Sep 18, 2014 at 12:48 AM, Gary Gregory <ga...@gmail.com>
> wrote:
>
>> I do not think this should be marker "experimental".
>>
>> If it is brought into trunk for 2.1 and we have a beta, we can say, this
>> and that are new, it's a beta.
>>
>> Gary
>>
>> ---------- Forwarded message ----------
>> From: <rp...@apache.org>
>> Date: Wed, Sep 17, 2014 at 11:45 AM
>> Subject: [1/3] git commit: LOG4J2-431 MemoryMappedFileAppender manual page
>> To: commits@logging.apache.org
>>
>>
>> Repository: logging-log4j2
>> Updated Branches:
>>   refs/heads/LOG4J2-431 64369f3d7 -> 63aed83d6
>>
>>
>> LOG4J2-431 MemoryMappedFileAppender manual page
>>
>> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
>> Commit:
>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/80dafe9e
>> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/80dafe9e
>> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/80dafe9e
>>
>> Branch: refs/heads/LOG4J2-431
>> Commit: 80dafe9e85c28f89d5b4d411d8b28c33642f411f
>> Parents: 64369f3
>> Author: rpopma <rp...@apache.org>
>> Authored: Thu Sep 18 00:42:50 2014 +0900
>> Committer: rpopma <rp...@apache.org>
>> Committed: Thu Sep 18 00:42:50 2014 +0900
>>
>> ----------------------------------------------------------------------
>>  src/site/xdoc/manual/appenders.xml | 131 ++++++++++++++++++++++++++++++++
>>  1 file changed, 131 insertions(+)
>> ----------------------------------------------------------------------
>>
>>
>>
>> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/80dafe9e/src/site/xdoc/manual/appenders.xml
>> ----------------------------------------------------------------------
>> diff --git a/src/site/xdoc/manual/appenders.xml
>> b/src/site/xdoc/manual/appenders.xml
>> index 032983b..7d47f78 100644
>> --- a/src/site/xdoc/manual/appenders.xml
>> +++ b/src/site/xdoc/manual/appenders.xml
>> @@ -1320,6 +1320,137 @@ public class JpaLogEntity extends
>> AbstractLogEventWrapperEntity {
>>      ...
>>  }]]></pre>
>>          </subsection>
>> +      <a name="MemoryMappedFileAppender" />
>> +      <subsection name="MemoryMappedFileAppender">
>> +        <p><i>Experimental. This has been tested on several platforms,
>> but this is
>> +          a new component (since 2.1) and does not yet have much track
>> record.</i></p>
>> +        <p>
>> +          The MemoryMappedFileAppender maps a part of the specified file
>> into memory
>> +          and writes log events to this memory, relying on the operating
>> system's
>> +          virtual memory manager to synchronize the changes to the
>> storage device.
>> +          The main benefit of doing this is I/O performance. Instead of
>> making system
>> +          calls to write to disk, this appender can simply change the
>> program's local memory,
>> +          which is orders of magnitude faster. Also, in most operating
>> systems the memory
>> +          region mapped actually is the kernel's <a href="
>> http://en.wikipedia.org/wiki/Page_cache">page
>> +          cache</a> (file cache), meaning that no copies need to be
>> created in user space.
>> +          (TODO: performance tests that compare performance of this
>> appender to
>> +          RandomAccessFileAppender and FileAppender.)
>> +        </p>
>> +        <p>
>> +          There is some overhead with mapping a file region into memory,
>> +          especially very large regions (half a gigabyte or more).
>> +          The default region size is 32 MB, which should strike a
>> reasonable balance
>> +          between the frequency and the duration of remap operations.
>> +          (TODO: performance test remapping various sizes.)
>> +        </p>
>> +        <p>
>> +          Similar to the FileAppender and the RandomAccessFileAppender,
>> +          MemoryMappedFileAppender uses a MemoryMappedFileManager to
>> actually perform the
>> +          file I/O. While MemoryMappedFileAppender from different
>> Configurations
>> +          cannot be shared, the MemoryMappedFileManagers can be if the
>> Manager is
>> +          accessible. For example, two web applications in a servlet
>> container can have
>> +          their own configuration and safely write to the same file if
>> Log4j
>> +          is in a ClassLoader that is common to both of them.
>> +        </p>
>> +        <table>
>> +          <caption align="top">MemoryMappedFileAppender
>> Parameters</caption>
>> +          <tr>
>> +            <th>Parameter Name</th>
>> +            <th>Type</th>
>> +            <th>Description</th>
>> +          </tr>
>> +          <tr>
>> +            <td>append</td>
>> +            <td>boolean</td>
>> +            <td>When true - the default, records will be appended to the
>> end
>> +              of the file. When set to false, the file will be cleared
>> before
>> +              new records are written.
>> +            </td>
>> +          </tr>
>> +          <tr>
>> +            <td>fileName</td>
>> +            <td>String</td>
>> +            <td>The name of the file to write to. If the file, or any of
>> its
>> +              parent directories, do not exist, they will be created.
>> +            </td>
>> +          </tr>
>> +          <tr>
>> +            <td>filters</td>
>> +            <td>Filter</td>
>> +            <td>A Filter to determine if the event should be handled by
>> this
>> +              Appender. More than one Filter may be used by using a
>> CompositeFilter.
>> +            </td>
>> +          </tr>
>> +          <tr>
>> +            <td>immediateFlush</td>
>> +            <td>boolean</td>
>> +            <td>
>> +              <p>When set to true, each write will be followed by a
>> +                call to <a href="
>> http://docs.oracle.com/javase/7/docs/api/java/nio/MappedByteBuffer.html#force()
>> ">MappedByteBuffer.force()</a>.
>> +            This will guarantee the data is written to the storage
>> device.
>> +              </p>
>> +              <p>The default for this parameter is <code>false</code>.
>> +                This means that the data is written to the storage
>> device even
>> +                if the Java process crashes, but there may be data loss
>> if the
>> +                operating system crashes. Note that manually forcing a
>> sync on every
>> +                log event loses most of the performance benefits of
>> using a memory mapped file.</p>
>> +              <p>Flushing after every write is only useful when using
>> this
>> +              appender with synchronous loggers. Asynchronous loggers and
>> +              appenders will automatically flush at the end of a batch
>> of events,
>> +              even if immediateFlush is set to false. This also
>> guarantees
>> +              the data is written to disk but is more efficient.
>> +              </p>
>> +            </td>
>> +          </tr>
>> +          <tr>
>> +            <td>regionLength</td>
>> +            <td>int</td>
>> +            <td>The length of the mapped region, defaults to 32 MB
>> +              (32 * 1024 * 1024 bytes). This parameter must be a value
>> +              between 256 and 1,073,741,824 (1 GB or 2^30);
>> +              values outside this range will be adjusted to the closest
>> valid
>> +              value.
>> +              Log4j will round the specified value up to the nearest
>> power of two.</td>
>> +          </tr>
>> +          <tr>
>> +            <td>layout</td>
>> +            <td>Layout</td>
>> +            <td>The Layout to use to format the LogEvent</td>
>> +          </tr>
>> +          <tr>
>> +            <td>name</td>
>> +            <td>String</td>
>> +            <td>The name of the Appender.</td>
>> +          </tr>
>> +          <tr>
>> +            <td>ignoreExceptions</td>
>> +            <td>boolean</td>
>> +            <td>The default is <code>true</code>, causing exceptions
>> encountered while appending events to be
>> +              internally logged and then ignored. When set to
>> <code>false</code> exceptions will be propagated to the
>> +              caller, instead. You must set this to <code>false</code>
>> when wrapping this Appender in a
>> +              <a href="#FailoverAppender">FailoverAppender</a>.</td>
>> +          </tr>
>> +        </table>
>> +        <p>
>> +          Here is a sample MemoryMappedFile configuration:
>> +        </p>
>> +
>> +          <pre class="prettyprint linenums"><![CDATA[<?xml version="1.0"
>> encoding="UTF-8"?>
>> +<Configuration status="warn" name="MyApp" packages="">
>> +  <Appenders>
>> +    <MemoryMappedFile name="MyFile" fileName="logs/app.log">
>> +      <PatternLayout>
>> +        <Pattern>%d %p %c{1.} [%t] %m%n</Pattern>
>> +      </PatternLayout>
>> +    </MemoryMappedFile>
>> +  </Appenders>
>> +  <Loggers>
>> +    <Root level="error">
>> +      <AppenderRef ref="MyFile"/>
>> +    </Root>
>> +  </Loggers>
>> +</Configuration>]]></pre>
>> +      </subsection>
>>          <a name="NoSQLAppender"/>
>>          <subsection name="NoSQLAppender">
>>            <p>The NoSQLAppender writes log events to a NoSQL database
>> using an internal lightweight provider interface.
>>
>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> Java Persistence with Hibernate, Second Edition
>> <http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>


-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [1/3] git commit: LOG4J2-431 MemoryMappedFileAppender manual page

Posted by Remko Popma <re...@gmail.com>.
Shall I replace "Experimental" with "Beta" in the docs for this component
then until 2.1 final? I'm fine with that.

On Thu, Sep 18, 2014 at 12:48 AM, Gary Gregory <ga...@gmail.com>
wrote:

> I do not think this should be marker "experimental".
>
> If it is brought into trunk for 2.1 and we have a beta, we can say, this
> and that are new, it's a beta.
>
> Gary
>
> ---------- Forwarded message ----------
> From: <rp...@apache.org>
> Date: Wed, Sep 17, 2014 at 11:45 AM
> Subject: [1/3] git commit: LOG4J2-431 MemoryMappedFileAppender manual page
> To: commits@logging.apache.org
>
>
> Repository: logging-log4j2
> Updated Branches:
>   refs/heads/LOG4J2-431 64369f3d7 -> 63aed83d6
>
>
> LOG4J2-431 MemoryMappedFileAppender manual page
>
> Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
> Commit:
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/80dafe9e
> Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/80dafe9e
> Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/80dafe9e
>
> Branch: refs/heads/LOG4J2-431
> Commit: 80dafe9e85c28f89d5b4d411d8b28c33642f411f
> Parents: 64369f3
> Author: rpopma <rp...@apache.org>
> Authored: Thu Sep 18 00:42:50 2014 +0900
> Committer: rpopma <rp...@apache.org>
> Committed: Thu Sep 18 00:42:50 2014 +0900
>
> ----------------------------------------------------------------------
>  src/site/xdoc/manual/appenders.xml | 131 ++++++++++++++++++++++++++++++++
>  1 file changed, 131 insertions(+)
> ----------------------------------------------------------------------
>
>
>
> http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/80dafe9e/src/site/xdoc/manual/appenders.xml
> ----------------------------------------------------------------------
> diff --git a/src/site/xdoc/manual/appenders.xml
> b/src/site/xdoc/manual/appenders.xml
> index 032983b..7d47f78 100644
> --- a/src/site/xdoc/manual/appenders.xml
> +++ b/src/site/xdoc/manual/appenders.xml
> @@ -1320,6 +1320,137 @@ public class JpaLogEntity extends
> AbstractLogEventWrapperEntity {
>      ...
>  }]]></pre>
>          </subsection>
> +      <a name="MemoryMappedFileAppender" />
> +      <subsection name="MemoryMappedFileAppender">
> +        <p><i>Experimental. This has been tested on several platforms,
> but this is
> +          a new component (since 2.1) and does not yet have much track
> record.</i></p>
> +        <p>
> +          The MemoryMappedFileAppender maps a part of the specified file
> into memory
> +          and writes log events to this memory, relying on the operating
> system's
> +          virtual memory manager to synchronize the changes to the
> storage device.
> +          The main benefit of doing this is I/O performance. Instead of
> making system
> +          calls to write to disk, this appender can simply change the
> program's local memory,
> +          which is orders of magnitude faster. Also, in most operating
> systems the memory
> +          region mapped actually is the kernel's <a href="
> http://en.wikipedia.org/wiki/Page_cache">page
> +          cache</a> (file cache), meaning that no copies need to be
> created in user space.
> +          (TODO: performance tests that compare performance of this
> appender to
> +          RandomAccessFileAppender and FileAppender.)
> +        </p>
> +        <p>
> +          There is some overhead with mapping a file region into memory,
> +          especially very large regions (half a gigabyte or more).
> +          The default region size is 32 MB, which should strike a
> reasonable balance
> +          between the frequency and the duration of remap operations.
> +          (TODO: performance test remapping various sizes.)
> +        </p>
> +        <p>
> +          Similar to the FileAppender and the RandomAccessFileAppender,
> +          MemoryMappedFileAppender uses a MemoryMappedFileManager to
> actually perform the
> +          file I/O. While MemoryMappedFileAppender from different
> Configurations
> +          cannot be shared, the MemoryMappedFileManagers can be if the
> Manager is
> +          accessible. For example, two web applications in a servlet
> container can have
> +          their own configuration and safely write to the same file if
> Log4j
> +          is in a ClassLoader that is common to both of them.
> +        </p>
> +        <table>
> +          <caption align="top">MemoryMappedFileAppender
> Parameters</caption>
> +          <tr>
> +            <th>Parameter Name</th>
> +            <th>Type</th>
> +            <th>Description</th>
> +          </tr>
> +          <tr>
> +            <td>append</td>
> +            <td>boolean</td>
> +            <td>When true - the default, records will be appended to the
> end
> +              of the file. When set to false, the file will be cleared
> before
> +              new records are written.
> +            </td>
> +          </tr>
> +          <tr>
> +            <td>fileName</td>
> +            <td>String</td>
> +            <td>The name of the file to write to. If the file, or any of
> its
> +              parent directories, do not exist, they will be created.
> +            </td>
> +          </tr>
> +          <tr>
> +            <td>filters</td>
> +            <td>Filter</td>
> +            <td>A Filter to determine if the event should be handled by
> this
> +              Appender. More than one Filter may be used by using a
> CompositeFilter.
> +            </td>
> +          </tr>
> +          <tr>
> +            <td>immediateFlush</td>
> +            <td>boolean</td>
> +            <td>
> +              <p>When set to true, each write will be followed by a
> +                call to <a href="
> http://docs.oracle.com/javase/7/docs/api/java/nio/MappedByteBuffer.html#force()
> ">MappedByteBuffer.force()</a>.
> +            This will guarantee the data is written to the storage device.
> +              </p>
> +              <p>The default for this parameter is <code>false</code>.
> +                This means that the data is written to the storage device
> even
> +                if the Java process crashes, but there may be data loss
> if the
> +                operating system crashes. Note that manually forcing a
> sync on every
> +                log event loses most of the performance benefits of using
> a memory mapped file.</p>
> +              <p>Flushing after every write is only useful when using this
> +              appender with synchronous loggers. Asynchronous loggers and
> +              appenders will automatically flush at the end of a batch of
> events,
> +              even if immediateFlush is set to false. This also guarantees
> +              the data is written to disk but is more efficient.
> +              </p>
> +            </td>
> +          </tr>
> +          <tr>
> +            <td>regionLength</td>
> +            <td>int</td>
> +            <td>The length of the mapped region, defaults to 32 MB
> +              (32 * 1024 * 1024 bytes). This parameter must be a value
> +              between 256 and 1,073,741,824 (1 GB or 2^30);
> +              values outside this range will be adjusted to the closest
> valid
> +              value.
> +              Log4j will round the specified value up to the nearest
> power of two.</td>
> +          </tr>
> +          <tr>
> +            <td>layout</td>
> +            <td>Layout</td>
> +            <td>The Layout to use to format the LogEvent</td>
> +          </tr>
> +          <tr>
> +            <td>name</td>
> +            <td>String</td>
> +            <td>The name of the Appender.</td>
> +          </tr>
> +          <tr>
> +            <td>ignoreExceptions</td>
> +            <td>boolean</td>
> +            <td>The default is <code>true</code>, causing exceptions
> encountered while appending events to be
> +              internally logged and then ignored. When set to
> <code>false</code> exceptions will be propagated to the
> +              caller, instead. You must set this to <code>false</code>
> when wrapping this Appender in a
> +              <a href="#FailoverAppender">FailoverAppender</a>.</td>
> +          </tr>
> +        </table>
> +        <p>
> +          Here is a sample MemoryMappedFile configuration:
> +        </p>
> +
> +          <pre class="prettyprint linenums"><![CDATA[<?xml version="1.0"
> encoding="UTF-8"?>
> +<Configuration status="warn" name="MyApp" packages="">
> +  <Appenders>
> +    <MemoryMappedFile name="MyFile" fileName="logs/app.log">
> +      <PatternLayout>
> +        <Pattern>%d %p %c{1.} [%t] %m%n</Pattern>
> +      </PatternLayout>
> +    </MemoryMappedFile>
> +  </Appenders>
> +  <Loggers>
> +    <Root level="error">
> +      <AppenderRef ref="MyFile"/>
> +    </Root>
> +  </Loggers>
> +</Configuration>]]></pre>
> +      </subsection>
>          <a name="NoSQLAppender"/>
>          <subsection name="NoSQLAppender">
>            <p>The NoSQLAppender writes log events to a NoSQL database
> using an internal lightweight provider interface.
>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>

Fwd: [1/3] git commit: LOG4J2-431 MemoryMappedFileAppender manual page

Posted by Gary Gregory <ga...@gmail.com>.
I do not think this should be marker "experimental".

If it is brought into trunk for 2.1 and we have a beta, we can say, this
and that are new, it's a beta.

Gary

---------- Forwarded message ----------
From: <rp...@apache.org>
Date: Wed, Sep 17, 2014 at 11:45 AM
Subject: [1/3] git commit: LOG4J2-431 MemoryMappedFileAppender manual page
To: commits@logging.apache.org


Repository: logging-log4j2
Updated Branches:
  refs/heads/LOG4J2-431 64369f3d7 -> 63aed83d6


LOG4J2-431 MemoryMappedFileAppender manual page

Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
Commit:
http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/80dafe9e
Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/80dafe9e
Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/80dafe9e

Branch: refs/heads/LOG4J2-431
Commit: 80dafe9e85c28f89d5b4d411d8b28c33642f411f
Parents: 64369f3
Author: rpopma <rp...@apache.org>
Authored: Thu Sep 18 00:42:50 2014 +0900
Committer: rpopma <rp...@apache.org>
Committed: Thu Sep 18 00:42:50 2014 +0900

----------------------------------------------------------------------
 src/site/xdoc/manual/appenders.xml | 131 ++++++++++++++++++++++++++++++++
 1 file changed, 131 insertions(+)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/80dafe9e/src/site/xdoc/manual/appenders.xml
----------------------------------------------------------------------
diff --git a/src/site/xdoc/manual/appenders.xml
b/src/site/xdoc/manual/appenders.xml
index 032983b..7d47f78 100644
--- a/src/site/xdoc/manual/appenders.xml
+++ b/src/site/xdoc/manual/appenders.xml
@@ -1320,6 +1320,137 @@ public class JpaLogEntity extends
AbstractLogEventWrapperEntity {
     ...
 }]]></pre>
         </subsection>
+      <a name="MemoryMappedFileAppender" />
+      <subsection name="MemoryMappedFileAppender">
+        <p><i>Experimental. This has been tested on several platforms, but
this is
+          a new component (since 2.1) and does not yet have much track
record.</i></p>
+        <p>
+          The MemoryMappedFileAppender maps a part of the specified file
into memory
+          and writes log events to this memory, relying on the operating
system's
+          virtual memory manager to synchronize the changes to the storage
device.
+          The main benefit of doing this is I/O performance. Instead of
making system
+          calls to write to disk, this appender can simply change the
program's local memory,
+          which is orders of magnitude faster. Also, in most operating
systems the memory
+          region mapped actually is the kernel's <a href="
http://en.wikipedia.org/wiki/Page_cache">page
+          cache</a> (file cache), meaning that no copies need to be
created in user space.
+          (TODO: performance tests that compare performance of this
appender to
+          RandomAccessFileAppender and FileAppender.)
+        </p>
+        <p>
+          There is some overhead with mapping a file region into memory,
+          especially very large regions (half a gigabyte or more).
+          The default region size is 32 MB, which should strike a
reasonable balance
+          between the frequency and the duration of remap operations.
+          (TODO: performance test remapping various sizes.)
+        </p>
+        <p>
+          Similar to the FileAppender and the RandomAccessFileAppender,
+          MemoryMappedFileAppender uses a MemoryMappedFileManager to
actually perform the
+          file I/O. While MemoryMappedFileAppender from different
Configurations
+          cannot be shared, the MemoryMappedFileManagers can be if the
Manager is
+          accessible. For example, two web applications in a servlet
container can have
+          their own configuration and safely write to the same file if
Log4j
+          is in a ClassLoader that is common to both of them.
+        </p>
+        <table>
+          <caption align="top">MemoryMappedFileAppender
Parameters</caption>
+          <tr>
+            <th>Parameter Name</th>
+            <th>Type</th>
+            <th>Description</th>
+          </tr>
+          <tr>
+            <td>append</td>
+            <td>boolean</td>
+            <td>When true - the default, records will be appended to the
end
+              of the file. When set to false, the file will be cleared
before
+              new records are written.
+            </td>
+          </tr>
+          <tr>
+            <td>fileName</td>
+            <td>String</td>
+            <td>The name of the file to write to. If the file, or any of
its
+              parent directories, do not exist, they will be created.
+            </td>
+          </tr>
+          <tr>
+            <td>filters</td>
+            <td>Filter</td>
+            <td>A Filter to determine if the event should be handled by
this
+              Appender. More than one Filter may be used by using a
CompositeFilter.
+            </td>
+          </tr>
+          <tr>
+            <td>immediateFlush</td>
+            <td>boolean</td>
+            <td>
+              <p>When set to true, each write will be followed by a
+                call to <a href="
http://docs.oracle.com/javase/7/docs/api/java/nio/MappedByteBuffer.html#force()
">MappedByteBuffer.force()</a>.
+            This will guarantee the data is written to the storage device.
+              </p>
+              <p>The default for this parameter is <code>false</code>.
+                This means that the data is written to the storage device
even
+                if the Java process crashes, but there may be data loss if
the
+                operating system crashes. Note that manually forcing a
sync on every
+                log event loses most of the performance benefits of using
a memory mapped file.</p>
+              <p>Flushing after every write is only useful when using this
+              appender with synchronous loggers. Asynchronous loggers and
+              appenders will automatically flush at the end of a batch of
events,
+              even if immediateFlush is set to false. This also guarantees
+              the data is written to disk but is more efficient.
+              </p>
+            </td>
+          </tr>
+          <tr>
+            <td>regionLength</td>
+            <td>int</td>
+            <td>The length of the mapped region, defaults to 32 MB
+              (32 * 1024 * 1024 bytes). This parameter must be a value
+              between 256 and 1,073,741,824 (1 GB or 2^30);
+              values outside this range will be adjusted to the closest
valid
+              value.
+              Log4j will round the specified value up to the nearest power
of two.</td>
+          </tr>
+          <tr>
+            <td>layout</td>
+            <td>Layout</td>
+            <td>The Layout to use to format the LogEvent</td>
+          </tr>
+          <tr>
+            <td>name</td>
+            <td>String</td>
+            <td>The name of the Appender.</td>
+          </tr>
+          <tr>
+            <td>ignoreExceptions</td>
+            <td>boolean</td>
+            <td>The default is <code>true</code>, causing exceptions
encountered while appending events to be
+              internally logged and then ignored. When set to
<code>false</code> exceptions will be propagated to the
+              caller, instead. You must set this to <code>false</code>
when wrapping this Appender in a
+              <a href="#FailoverAppender">FailoverAppender</a>.</td>
+          </tr>
+        </table>
+        <p>
+          Here is a sample MemoryMappedFile configuration:
+        </p>
+
+          <pre class="prettyprint linenums"><![CDATA[<?xml version="1.0"
encoding="UTF-8"?>
+<Configuration status="warn" name="MyApp" packages="">
+  <Appenders>
+    <MemoryMappedFile name="MyFile" fileName="logs/app.log">
+      <PatternLayout>
+        <Pattern>%d %p %c{1.} [%t] %m%n</Pattern>
+      </PatternLayout>
+    </MemoryMappedFile>
+  </Appenders>
+  <Loggers>
+    <Root level="error">
+      <AppenderRef ref="MyFile"/>
+    </Root>
+  </Loggers>
+</Configuration>]]></pre>
+      </subsection>
         <a name="NoSQLAppender"/>
         <subsection name="NoSQLAppender">
           <p>The NoSQLAppender writes log events to a NoSQL database using
an internal lightweight provider interface.




-- 
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

[2/3] git commit: LOG4J2-431 improve parameter validation

Posted by rp...@apache.org.
LOG4J2-431 improve parameter validation

Project: http://git-wip-us.apache.org/repos/asf/logging-log4j2/repo
Commit: http://git-wip-us.apache.org/repos/asf/logging-log4j2/commit/a5325b37
Tree: http://git-wip-us.apache.org/repos/asf/logging-log4j2/tree/a5325b37
Diff: http://git-wip-us.apache.org/repos/asf/logging-log4j2/diff/a5325b37

Branch: refs/heads/LOG4J2-431
Commit: a5325b37995775a02865f4093f4f4b4ff2df5120
Parents: 80dafe9
Author: rpopma <rp...@apache.org>
Authored: Thu Sep 18 00:43:54 2014 +0900
Committer: rpopma <rp...@apache.org>
Committed: Thu Sep 18 00:43:54 2014 +0900

----------------------------------------------------------------------
 .../core/appender/MemoryMappedFileAppender.java | 35 ++++++++++++++++----
 1 file changed, 28 insertions(+), 7 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/logging-log4j2/blob/a5325b37/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/MemoryMappedFileAppender.java
----------------------------------------------------------------------
diff --git a/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/MemoryMappedFileAppender.java b/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/MemoryMappedFileAppender.java
index 785c3da..56b40b8 100644
--- a/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/MemoryMappedFileAppender.java
+++ b/log4j-core/src/main/java/org/apache/logging/log4j/core/appender/MemoryMappedFileAppender.java
@@ -42,6 +42,9 @@ public final class MemoryMappedFileAppender extends AbstractOutputStreamAppender
 
     private static final long serialVersionUID = 1L;
 
+    private static final int MAX_REGION_LENGTH = 1 << 30; // 1GB
+    private static final int MIN_REGION_LENGTH = 256;
+
     private final String fileName;
     private Object advertisement;
     private final Advertiser advertiser;
@@ -127,7 +130,7 @@ public final class MemoryMappedFileAppender extends AbstractOutputStreamAppender
      */
     @PluginFactory
     public static MemoryMappedFileAppender createAppender(
-    // @formatter:off
+// @formatter:off
             @PluginAttribute("fileName") final String fileName, //
             @PluginAttribute("append") final String append, //
             @PluginAttribute("name") final String name, //
@@ -142,15 +145,11 @@ public final class MemoryMappedFileAppender extends AbstractOutputStreamAppender
         // @formatter:on
 
         final boolean isAppend = Booleans.parseBoolean(append, true);
-        final boolean isForce = Booleans.parseBoolean(immediateFlush, true);
+        final boolean isForce = Booleans.parseBoolean(immediateFlush, false);
         final boolean ignoreExceptions = Booleans.parseBoolean(ignore, true);
         final boolean isAdvertise = Boolean.parseBoolean(advertise);
         final int regionLength = Integers.parseInt(regionLengthStr, MemoryMappedFileManager.DEFAULT_REGION_LENGTH);
-        final int actualRegionLength = Integers.ceilingNextPowerOfTwo(regionLength);
-        if (regionLength != actualRegionLength) {
-            LOGGER.info("MemoryMappedAppender[{}] Rounded up region length from {} to next power of two: {}", name,
-                    regionLength, actualRegionLength);
-        }
+        final int actualRegionLength = determineValidRegionLength(name, regionLength);
 
         if (name == null) {
             LOGGER.error("No name provided for MemoryMappedFileAppender");
@@ -173,4 +172,26 @@ public final class MemoryMappedFileAppender extends AbstractOutputStreamAppender
         return new MemoryMappedFileAppender(name, layout, filter, manager, fileName, ignoreExceptions, isForce,
                 isAdvertise ? config.getAdvertiser() : null);
     }
+
+    /**
+     * Converts the specified region length to a valid value.
+     */
+    private static int determineValidRegionLength(final String name, final int regionLength) {
+        if (regionLength > MAX_REGION_LENGTH) {
+            LOGGER.info("MemoryMappedAppender[{}] Reduced region length from {} to max length: {}", name, regionLength,
+                    MAX_REGION_LENGTH);
+            return MAX_REGION_LENGTH;
+        }
+        if (regionLength < MIN_REGION_LENGTH) {
+            LOGGER.info("MemoryMappedAppender[{}] Expanded region length from {} to min length: {}", name, regionLength,
+                    MIN_REGION_LENGTH);
+            return MIN_REGION_LENGTH;
+        }
+        final int result = Integers.ceilingNextPowerOfTwo(regionLength);
+        if (regionLength != result) {
+            LOGGER.info("MemoryMappedAppender[{}] Rounded up region length from {} to next power of two: {}", name,
+                    regionLength, result);
+        }
+        return result;
+    }
 }