Przeglądaj źródła

Merge branch 'candidate-5.0.4'

Conflicts:
	initfiles/componentfiles/configxml/ldapserver.xsd

Signed-off-by: Richard Chapman <rchapman@hpccsystems.com>
Richard Chapman 10 lat temu
rodzic
commit
aa37d20155

+ 8 - 3
dali/base/dasds.cpp

@@ -7541,7 +7541,7 @@ void CCovenSDSManager::createConnection(SessionId sessionId, unsigned mode, unsi
             try
             {
                 loop
-                {                       
+                {
                     try
                     {
                         Owned<IPropertyTreeIterator> iter = root->getElements(xpath+1);
@@ -7556,8 +7556,13 @@ void CCovenSDSManager::createConnection(SessionId sessionId, unsigned mode, unsi
                                 freeExistingLocks.add(existing);
                                 {
                                     unsigned remaining;
-                                    if (tm.timedout(&remaining))
-                                        throw MakeSDSException(SDSExcpt_LockTimeout, "Failed to establish lock to %s, timeout whilst retrying connection to orphaned connection path", xpath);
+                                    if (timeout)
+                                    {
+                                        if (tm.timedout(&remaining))
+                                            throw MakeSDSException(SDSExcpt_LockTimeout, "Failed to establish lock to %s, timeout whilst retrying connection to orphaned connection path", xpath);
+                                    }
+                                    else
+                                        remaining = 0; // a timeout of 0 means fail immediately if locked
                                     CConnectExistingLockCallback connectLockCallback(xpath, connectionId, existing, &connectCrit);
                                     lock(existing, xpath, connectionId, sessionId, mode, remaining, connectLockCallback);
                                 }

+ 42 - 0
docs/UsingConfigManager/UsingConfigManager.xml

@@ -1914,6 +1914,48 @@ sudo -u hpcc cp /etc/HPCCSystems/source/NewEnvironment.xml /etc/HPCCSystems/envi
             <graphic fileref="images/CM-img18-1.jpg" vendor="configmgrSS" />
           </para>
 
+          <para>
+            <emphasis role="bold">Thor Memory Settings</emphasis>
+          </para>
+
+          <para>If <emphasis role="bold">globalMemorySize</emphasis> is left
+          unset, Thor[master] detects total physical memory and allocates 75%
+          of it. If there are multiple slaves per node (slavesPerNode&gt;1) it
+          divides the total among the slaves. If globalMemorySize is defined,
+          then it allocates that amount of memory to each slave. The
+          masterMemorySize attribute allocates memory for the Thor master. If
+          omitted, Thor master uses globalMemorySize, or the default 75% of
+          memory.</para>
+
+          <para>On systems with a lot of memory, the default 75% of physical
+          memory is probably too conservative and reserving total physical
+          minus 2GB (for the OS and other processes) is sensible. You should
+          then divide that number by the number of slavesPerNode. </para>
+
+          <para>If there are multiple Thors sharing the same nodes, then
+          globalMemorySize must be configured to take that into account.
+          </para>
+
+          <para>For example, if there are 2 Thors each with 2 slaves per box,
+          that will mean there are 4 slaves per physical node. So you should
+          use a formula similar to the following in your calculations when
+          configuring globalMemorySize:</para>
+
+          <programlisting>globalMemorySize = (total-physical-memory)-2GB / (2*2) </programlisting>
+
+          <para>Without any specified setting, Thor assumes it has exclusive
+          access to the memory and would therefore use too much (because each
+          Thor is unaware of the other's configuration and memory usage).
+          </para>
+
+          <para>Although a configuration may be set using upper memory limits
+          that exceed total physical memory, Thor will not actually reserve
+          the memory ahead of time and will only hit memory problems when and
+          if your jobs use all of memory. So, for example, two Thors that are
+          configured to use all available memory could peacefully co-exist
+          until a query on each are simultaneously using more memory than the
+          node has available.</para>
+
           <!--configMgr-Thor-Attribute-Include-XXX-->
 
           <para>

BIN
docs/images/CM-img18-1.jpg


+ 1 - 1
ecl/hqlcpp/hqlhtcpp.cpp

@@ -15007,7 +15007,7 @@ ABoundActivity * HqlCppTranslator::doBuildActivitySerialize(BuildCtx & ctx, IHql
 
     IHqlExpression * record = expr->queryRecord();
     HqlExprArray args;
-    args.append(*createSerializer(ctx, record, serializeForm, kind));
+    args.append(*createSerializer(funcctx, record, serializeForm, kind));
     args.append(*ensureActiveRow(dataset));
     Owned<ITypeInfo> type = makeTransformType(record->getType());
     OwnedHqlExpr call = bindFunctionCall(func, args, type);