You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@qpid.apache.org by kw...@apache.org on 2016/11/09 08:52:40 UTC
svn commit: r1768875 -
/qpid/java/trunk/doc/java-broker/src/docbkx/runtime/Java-Broker-Runtime-Memory.xml
Author: kwall
Date: Wed Nov 9 08:52:40 2016
New Revision: 1768875
URL: http://svn.apache.org/viewvc?rev=1768875&view=rev
Log:
QPID-7479: [Java Broker Documentation] Correct a couple of typos in new documentation.
Modified:
qpid/java/trunk/doc/java-broker/src/docbkx/runtime/Java-Broker-Runtime-Memory.xml
Modified: qpid/java/trunk/doc/java-broker/src/docbkx/runtime/Java-Broker-Runtime-Memory.xml
URL: http://svn.apache.org/viewvc/qpid/java/trunk/doc/java-broker/src/docbkx/runtime/Java-Broker-Runtime-Memory.xml?rev=1768875&r1=1768874&r2=1768875&view=diff
==============================================================================
--- qpid/java/trunk/doc/java-broker/src/docbkx/runtime/Java-Broker-Runtime-Memory.xml (original)
+++ qpid/java/trunk/doc/java-broker/src/docbkx/runtime/Java-Broker-Runtime-Memory.xml Wed Nov 9 08:52:40 2016
@@ -57,7 +57,7 @@
<section>
<title>Direct</title>
<para>
- The world ouside of the JVM, in particular the operating system (OS), does not know about Java heap memory and uses other structures like C arrays.
+ The world outside of the JVM, in particular the operating system (OS), does not know about Java heap memory and uses other structures like C arrays.
In order to interact with these systems Java needs to copy data between its own heap memory and these native structures.
This can become a bottle neck when there is a lot of exchange between Java and the OS like in I/O (both disk and network) heavy applications.
Java's solution to this is to allow programmers to request <literal>ByteBuffer</literal>s from so called direct memory.
@@ -158,7 +158,7 @@
<section xml:id="Java-Broker-Runtime-Memory-Defaults">
<title>Defaults</title>
<para>
- By default Qpid uses these settiongs:
+ By default Qpid uses these settings:
<itemizedlist>
<listitem>
0.5 GB heap memory
@@ -173,7 +173,7 @@
Start flow-to-disk at 40% direct memory utilisation.
</listitem>
</itemizedlist>
- As an example, this would accomodate a broker with 50 connections, each serving 5 sessions, and each session having 1000 messages of 1 kB on queues in the broker.
+ As an example, this would accommodate a broker with 50 connections, each serving 5 sessions, and each session having 1000 messages of 1 kB on queues in the broker.
This means a total of 250 concurrent sessions and a total of 250000 messages without flowing messages to disk.
</para>
</section>
@@ -229,8 +229,8 @@
Where <mathphrase>N</mathphrase> denotes the total number of connections/sessions/messages on the broker. Furthermore, for direct memory only the messages that have not been flown to disk are relevant.
</para>
<note>
- <para>Provided formulas covers the worst case scenario when all persistent messages are loaded into heap memory and TLS connections are used.
- Transient messages consumes less heap memory than persistent messages and plain connections consumes less direct memory than TLS connections.
+ <para>The formulae assume the worst case in terms of memory usage: persistent messages and TLS connections. Transient messages consume less heap memory than peristent and plain connections consume less direct memory than TLS
+ connections.
</para>
</note>
</section>
@@ -243,7 +243,7 @@
This can have impact on performance in the transient case where otherwise no disk I/O would be involved.
</para>
<para>
- Having to little heap memory will result in poor performance due to frequent garbage collection events. See <xref linkend="Java-Broker-Runtime-Memory-Low-Memory"/> for more details.
+ Having too little heap memory will result in poor performance due to frequent garbage collection events. See <xref linkend="Java-Broker-Runtime-Memory-Low-Memory"/> for more details.
</para>
</section>
<section>
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@qpid.apache.org
For additional commands, e-mail: commits-help@qpid.apache.org