Add documentation for retry.interval feature
diff --git a/modules/documentation/src/site/xdoc/userguide/samples/sample705.xml b/modules/documentation/src/site/xdoc/userguide/samples/sample705.xml
index c9017d3..d7207df 100644
--- a/modules/documentation/src/site/xdoc/userguide/samples/sample705.xml
+++ b/modules/documentation/src/site/xdoc/userguide/samples/sample705.xml
@@ -58,6 +58,7 @@
       <parameter name="max.deliver.attempts">3</parameter>
       <parameter name="max.deliver.drop">true</parameter>
       <parameter name="retry.http.status.codes">500, 504</parameter>
+      <parameter name="retry.interval">5000</parameter>
    </messageProcessor>
 </definitions>
             </div>
@@ -68,6 +69,7 @@
                         <li>max.deliver.attempts</li>
                         <li>max.deliver.drop</li>
                         <li>retry.http.status.codes</li>
+                        <li>retry.interval</li>
                     </ul>
                 </p>
             </subsection>
@@ -107,6 +109,13 @@
                     HTTP error responses. For instance, in the above example Message Forwarding Processor retries not only for transport
                     level failures but also for application level failures such as Internal Server Error (500) and Gateway timeout (504).
                 </p>
+                <p>
+                    Rate in which Message Forwarding Processor sends request to configured back-end is controlled by configuring
+                    "interval" parameter. However, when there is a failure, rate in which Message Forwarding Processor retries is
+                    controlled by configuring "retry.interval". Similar to "interval" "retry.interval" value must be set in milli seconds.
+                    In the case of setting a non-integer value, makes Message Forwarding Processor set the default value
+                    to "retry.interval", which is 1000ms.
+                </p>
             </subsection>
         </section>
         <p>