<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[nxpush "Request timed out" on nodes with variable connectivity only.]]></title><description><![CDATA[<p dir="auto">Hello,</p>
<p dir="auto">Prerequisite information:<br />
We are pushing data to NetXMS from the machine hosting NetXMS itself with a<br />
series of nxpush calls - one for each target node.</p>
<p dir="auto">Observation:<br />
We are experiencing a node-specific issue, concerning a set of local nxpush<br />
sessions timing out statistically for specific nodes only.  Those nodes are all<br />
experiencing connectivity issues. There seems to be a correlation between<br />
occurrences of timeouts and network issues.</p>
<p dir="auto">Question:<br />
At the event of a new nxpush session, are there any internal checks taking<br />
place requiring connectivity of the node? Could a recurring process like a poll<br />
get stuck at the connectivity issue and interfere?</p>
<p dir="auto">Kind regards,</p>
<p dir="auto">  Florian</p>
]]></description><link>https://forum.netxms.org/topic/7088/nxpush-request-timed-out-on-nodes-with-variable-connectivity-only.</link><generator>RSS for Node</generator><lastBuildDate>Fri, 13 Nov 2026 11:25:22 GMT</lastBuildDate><atom:link href="https://forum.netxms.org/topic/7088.rss" rel="self" type="application/rss+xml"/><pubDate>Wed, 16 Jun 2021 08:29:49 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to nxpush "Request timed out" on nodes with variable connectivity only. on Tue, 22 Jun 2021 08:59:59 GMT]]></title><description><![CDATA[<p dir="auto">Let's try to exclude the option that transformation scripts get randomly delayed. Try wrapping transformation scripts in something like</p>
<pre><code>trace(0, $object-&gt;id . ":" . $dci-&gt;id . " tranformation script start");
...
trace(0, $object-&gt;id . ":" . $dci-&gt;id . " tranformation script end");
</code></pre>
<p dir="auto">first parameter of trace() defines the log level. This way you should get some stats on the actual duration of the transformation scripts.</p>
]]></description><link>https://forum.netxms.org/post/30187</link><guid isPermaLink="true">https://forum.netxms.org/post/30187</guid><dc:creator><![CDATA[Filipp Sudanov]]></dc:creator><pubDate>Tue, 22 Jun 2021 08:59:59 GMT</pubDate></item><item><title><![CDATA[Reply to nxpush "Request timed out" on nodes with variable connectivity only. on Mon, 21 Jun 2021 13:52:17 GMT]]></title><description><![CDATA[<p dir="auto">Hi,</p>
<p dir="auto">Yes, there are some transformation scripts.  But those are limited in<br />
complexity as well as number ( ~700 DCIs ) and should therefore be manageable.</p>
<ul>
<li>88% of DCIs do not have a transformation script</li>
<li> 9% of DCIs have a lower bound or static normalization ( if;else / division )</li>
<li> 3% of DCIs show dynamic normalization using up to two<br />
'GetDCIValue($node, FindDCIByName($node, "..."));' invokes<br />
( all referenced quantities are push-DCIs )</li>
</ul>
<p dir="auto">There are no more than 30 *DCI*() invokes for said client in total.<br />
Thresholds boil down to very basic diff(), last() and average() calls.<br />
These DCIs and their threshold events do not trigger any further scripts.</p>
<p dir="auto">---</p>
<p dir="auto">Multiple other nodes under very similar circumstances ( they inherit from the<br />
same DCI templates or more, and are being pushed to at the same frequency ) on<br />
the very same server instance are handled perfectly fine.  We are talking ~5<br />
afflicted and 50 unaffected nodes.</p>
<p dir="auto">Here is a quick plot I did for navigating/cross-referencing netxmsd's logs for<br />
hangs in my last post.<br />
I added the data of an unaffected node ( taken briefly after ) comparing the<br />
time nxpush took for a set of attempts to an affected nodes behaviour.<br />
<a href="https://i.imgur.com/CUrEvin.png" rel="nofollow ugc">https://i.imgur.com/CUrEvin.png</a></p>
<p dir="auto">Am I off track for assuming there should be an external variable connecting the affected nodes?</p>
<p dir="auto">Kind regards,</p>
<p dir="auto">  Florian</p>
]]></description><link>https://forum.netxms.org/post/30185</link><guid isPermaLink="true">https://forum.netxms.org/post/30185</guid><dc:creator><![CDATA[fldiet]]></dc:creator><pubDate>Mon, 21 Jun 2021 13:52:17 GMT</pubDate></item><item><title><![CDATA[Reply to nxpush "Request timed out" on nodes with variable connectivity only. on Fri, 18 Jun 2021 18:56:59 GMT]]></title><description><![CDATA[<p dir="auto">Hi,</p>
<p dir="auto">it looks that DCI data processing for some reason takes too long. Do you have any transformation scripts or script thresholds on those push DCIs?</p>
<p dir="auto">Best regards,<br />
Victor</p>
]]></description><link>https://forum.netxms.org/post/30179</link><guid isPermaLink="true">https://forum.netxms.org/post/30179</guid><dc:creator><![CDATA[victor]]></dc:creator><pubDate>Fri, 18 Jun 2021 18:56:59 GMT</pubDate></item><item><title><![CDATA[Reply to nxpush "Request timed out" on nodes with variable connectivity only. on Fri, 18 Jun 2021 09:08:27 GMT]]></title><description><![CDATA[<p dir="auto">I configured the debug level as requested, restarted netxmsd, set up a series of identical nxpush requests sequentially without artificial delay and observed the result of nxpush next to netxmsd's log.</p>
<p dir="auto">Here are some basic observances:</p>
<ul>
<li>
<p dir="auto">Typically the nxpush requests take 0.172-0.300s.</p>
</li>
<li>
<p dir="auto">Isolated hangs take around 5.05s ( low variance ) and do not influence following pushes time.</p>
</li>
<li>
<p dir="auto">Clusters of hangs back to back ( around 5-10 ) raise the following successful attempts time:</p>
<ol>
<li></li>
<li>
<p dir="auto">Hang cluster</p>
<ol>
<li></li>
<li> 46.2s ( first following successful )</li>
<li>  2.2s ( second following successful )</li>
<li>  0.2s ( third  following successful )</li>
</ol>
</li>
<li>
<p dir="auto">Hang cluster</p>
<ul>
<li></li>
<li> 25.3s</li>
<li>  2.9s</li>
<li>  0.2s</li>
</ul>
</li>
<li>
<p dir="auto">Hang cluster</p>
<ul>
<li></li>
<li> 12.9s</li>
<li>  0.2s</li>
</ul>
</li>
<li>
<p dir="auto">Hang cluster</p>
<ul>
<li></li>
<li> 17.4s</li>
<li>  0.2s</li>
</ul>
</li>
</ol>
</li>
</ul>
<p dir="auto">Here is a snippet of the logs in the neighbourhood of an isolated hang ( answering with CMD_KEEPALIVE to CMD_PUSH_DCI_DATA ), including the surrounding successful ones:</p>
<pre><code>2021.06.16 15:30:01.735 *D* [client.session     ] Client session with ID 84 registered
2021.06.16 15:30:01.735 *D* [client.session.84  ] Received message CMD_GET_SERVER_INFO
2021.06.16 15:30:01.735 *D* [client.session.84  ] Server time zone: UTC+00UTC
2021.06.16 15:30:01.735 *D* [client.session.84  ] Sending message CMD_REQUEST_COMPLETED (616 bytes)
2021.06.16 15:30:01.736 *D* [client.session.84  ] Received message CMD_LOGIN
2021.06.16 15:30:01.736 *D* [client.session.84  ] authentication type 0
2021.06.16 15:30:01.736 *D* [client.session.84  ] Protocol level compression is supported by client
2021.06.16 15:30:01.736 *D* [client.session.84  ] User &lt;ourUserForNxpush&gt;@127.0.0.1 authenticated (language=en clientInfo="nxpush/3.8.382 (Linux 4.19.0-16-amd64; libnxcl 3.8.382)")
2021.06.16 15:30:01.736 *D* [client.session.84  ] Sending compressed message CMD_LOGIN_RESP (312 bytes)
2021.06.16 15:30:01.777 *D* [client.session.84  ] Received message CMD_PUSH_DCI_DATA
2021.06.16 15:30:02.545 *D* [client.session.84  ] Sending message CMD_REQUEST_COMPLETED (32 bytes)
2021.06.16 15:30:02.545 *D* [client.session.84  ] readSocket: connection closed
2021.06.16 15:30:02.545 *D* [client.session.84  ] Session closed
2021.06.16 15:30:02.545 *D* [client.session     ] Client session with ID 84 unregistered
2021.06.16 15:30:02.545 *D* [client.session.84  ] Socket closed
2021.06.16 15:30:02.545 *D* [client.session.84  ] Session object destroyed
</code></pre>
<pre><code>2021.06.16 15:30:02.560 *D* [client.session     ] Client session with ID 84 registered
2021.06.16 15:30:02.560 *D* [client.session.84  ] Received message CMD_GET_SERVER_INFO
2021.06.16 15:30:02.560 *D* [client.session.84  ] Server time zone: UTC+00UTC
2021.06.16 15:30:02.560 *D* [client.session.84  ] Sending message CMD_REQUEST_COMPLETED (616 bytes)
2021.06.16 15:30:02.561 *D* [client.session.84  ] Received message CMD_LOGIN
2021.06.16 15:30:02.561 *D* [client.session.84  ] authentication type 0
2021.06.16 15:30:02.561 *D* [client.session.84  ] Protocol level compression is supported by client
2021.06.16 15:30:02.561 *D* [client.session.84  ] User &lt;ourUserForNxpush&gt;@127.0.0.1 authenticated (language=en clientInfo="nxpush/3.8.382 (Linux 4.19.0-16-amd64; libnxcl 3.8.382)")
2021.06.16 15:30:02.561 *D* [client.session.84  ] Sending compressed message CMD_LOGIN_RESP (312 bytes)
2021.06.16 15:30:02.602 *D* [client.session.84  ] Received message CMD_PUSH_DCI_DATA
2021.06.16 15:30:05.416 *D* [client.session.84  ] Sending message CMD_KEEPALIVE (32 bytes)
2021.06.16 15:30:05.423 *D* [client.session.84  ] Sending message CMD_NOTIFY (48 bytes)
2021.06.16 15:30:05.495 *D* [client.session.84  ] Sending message CMD_NOTIFY (48 bytes)
2021.06.16 15:30:07.601 *D* [client.session.84  ] readSocket: connection closed
2021.06.16 15:30:07.602 *D* [client.session.84  ] Waiting for pending requests...
</code></pre>
<pre><code>2021.06.16 15:30:07.627 *D* [client.session     ] Client session with ID 71 registered
2021.06.16 15:30:07.627 *D* [client.session.71  ] Received message CMD_GET_SERVER_INFO
2021.06.16 15:30:07.627 *D* [client.session.71  ] Server time zone: UTC+00UTC
2021.06.16 15:30:07.627 *D* [client.session.71  ] Sending message CMD_REQUEST_COMPLETED (616 bytes)
2021.06.16 15:30:07.628 *D* [client.session.71  ] Received message CMD_LOGIN
2021.06.16 15:30:07.628 *D* [client.session.71  ] authentication type 0
2021.06.16 15:30:07.628 *D* [client.session.71  ] Protocol level compression is supported by client
2021.06.16 15:30:07.628 *D* [client.session.71  ] User &lt;ourUserForNxpush&gt;@127.0.0.1 authenticated (language=en clientInfo="nxpush/3.8.382 (Linux 4.19.0-16-amd64; libnxcl 3.8.382)")
2021.06.16 15:30:07.628 *D* [client.session.71  ] Sending compressed message CMD_LOGIN_RESP (312 bytes)
2021.06.16 15:30:07.668 *D* [client.session.71  ] Received message CMD_PUSH_DCI_DATA
2021.06.16 15:30:07.989 *D* [client.session.71  ] Sending message CMD_REQUEST_COMPLETED (32 bytes)
2021.06.16 15:30:07.990 *D* [client.session.71  ] readSocket: connection closed
2021.06.16 15:30:07.990 *D* [client.session.71  ] Session closed
2021.06.16 15:30:07.990 *D* [client.session     ] Client session with ID 71 unregistered
2021.06.16 15:30:07.990 *D* [client.session.71  ] Socket closed
2021.06.16 15:30:07.990 *D* [client.session.71  ] Session object destroyed
</code></pre>
]]></description><link>https://forum.netxms.org/post/30173</link><guid isPermaLink="true">https://forum.netxms.org/post/30173</guid><dc:creator><![CDATA[fldiet]]></dc:creator><pubDate>Fri, 18 Jun 2021 09:08:27 GMT</pubDate></item><item><title><![CDATA[Reply to nxpush "Request timed out" on nodes with variable connectivity only. on Wed, 16 Jun 2021 12:04:16 GMT]]></title><description><![CDATA[<p dir="auto">Collection of server log would be beneficial here. Can you set debug level 6 for client.* tag (issue "debug client.* 6" in Tools-&gt;Server Console or you can set this in server configuration file).<br />
nxpush is creating the same connection as nxmc, so sessions of both will be visible under this tag. Each new connecting gets a new session id which is visible in the debug tag, e.g. client.session.1234.</p>
<p dir="auto">Then, when you encounter a nxpush nang, you should be able to find and grep out a corresponding session from the log file.</p>
]]></description><link>https://forum.netxms.org/post/30168</link><guid isPermaLink="true">https://forum.netxms.org/post/30168</guid><dc:creator><![CDATA[Filipp Sudanov]]></dc:creator><pubDate>Wed, 16 Jun 2021 12:04:16 GMT</pubDate></item></channel></rss>