diff --git a/docs/user-manual/en/perf-tuning.md b/docs/user-manual/en/perf-tuning.md
index 3b2d37a64a..19c2595a14 100644
--- a/docs/user-manual/en/perf-tuning.md
+++ b/docs/user-manual/en/perf-tuning.md
@@ -139,7 +139,7 @@ some tuning:
   then you can avoid some unnecessary copying.
   
 - If using frameworks like Spring, configure destinations permanently broker
-  side and enable `destinationCache` on the client side.  See the [Setting The
+  side and enable `cacheDestinations` on the client side.  See the [Setting The
   Destination Cache](using-jms.md) for more information on this.
 
 ## Tuning Transport Settings
diff --git a/docs/user-manual/en/using-jms.md b/docs/user-manual/en/using-jms.md
index bc9f3f2729..26342663f9 100644
--- a/docs/user-manual/en/using-jms.md
+++ b/docs/user-manual/en/using-jms.md
@@ -393,7 +393,7 @@ valuable bandwidth. This can be configured on the connection factory via the
 Many frameworks such as Spring resolve the destination by name on every
 operation, this can cause a performance issue and extra calls to the broker, in
 a scenario where destinations (addresses) are permanent broker side, such as
-they are managed by a platform or operations team.  using `destinationCache`
+they are managed by a platform or operations team.  using `cacheDestinations`
 element, you can toggle on the destination cache to improve the performance and
 reduce the calls to the broker.  This should not be used if destinations
 (addresses) are not permanent broker side, as in dynamic creation/deletion.