Request timed out

Started by bdefloo, February 05, 2014, 12:50:14 PM

Previous topic - Next topic

bdefloo

Hi,

Since upgrading to v1.2.11 I've been getting more "Request timed out" errors in the management console when doing various changes. (applying templates, creating a container, moving nodes, ...)

It doesn't always happen, andsometimes the operation goes through anyway, other times I have to do it again or it only succeeds partially (eg 3 out of 20 nodes are in the template, the others aren't)

Has something changed that could be causing resource locks or delays?

Thanks!

Kind regards,
bdefloo

possamai

same here.. it queues the request and finally it times out..

Victor Kirhenshtein

What database you are using?

Best regards,
Victor

bdefloo

Hi,

I have NetXMS x64 and MS SQL 2012 Express x64 on a Windows 2008 R2 server.

Marco Incalcaterra

Same here on Windows 2003 R2 x64 with MSSQL 2008 R2

Best regards,
Marco

ditonet

#5
I noticed same problem on Win XP and SQLite database.
Usually on dashboard's charts.
Status line shows small progress bar and message 'Get DCI value for history graph' if I remember correctly.

Regards, Grzegorz.

EDIT: Forgot to mention, NetXMS ver. 1.2.11 and corrected message text.

Peter Sentveld

Same here. "Cannot terminate alarm: Request timed out", lots.

CentOS, mysql, NetXMS 2.11.

Regards,
  Peter.

opcenter1218

Same issues as everything is describing. Whenever we try to delete more than a handful of alarms we get the error message popup but after a refresh the alarms go away. Very annoying but still functional.

Client Version: 1.2.11
Microsoft SQL Database

possamai

connection with the client gets completely messed up here.. I have to kill my client and reconnect a freshly started one to continue working.
Happens a lot when changing settings in Business Services as well.

Victor Kirhenshtein

Please try version 1.2.12. We have fixed lot of bugs here, hopefully timeout problem will be gone.

Best regards,
Victor

possamai

hmm.. looks like it's solved  :D
At least for me it is.
So far no more requests timed out anymore.

lindeamon

had this problem with 1.2.11 x64 2k8 srv and pgsql.
upgraded just now to 1.2.12, will check...

opcenter1218

#12
After upgrading to 1.2.12 we've been experiencing the issue below in management console and web portal.

"Cannot synchronize alarm list: Broken pipe
Broken pipe"

It generates the event "SYS_THREAD_HANG", Thread "Syncer Thread" is not responding

Restarting the client or refreshing the web browser clears the issue temporarily.



The previous "Request timed out" issue from 1.2.11 seems to be resolved.


mjcig

To add we are seeing a similar issue.. we are running 1.2.12 compiled for Linux using ODBC. The database is MS SQL 2012. With the past three releases we did not experience the management console timing out, but did see intermittent issues with the alarm browser and syncing the alarms.

With the new release 1.2.12, we are seeing the client session establish and then 15 minutes later the session time out.

Here is what the log is showing....
[21-Feb-2014 09:20:47.600] [DEBUG] [CLSN-0] Server time zone: CST-06CDT
[21-Feb-2014 09:20:48.176] [DEBUG] [CLSN-0] User [email protected] authenticated
[21-Feb-2014 09:20:51.350] [DEBUG] [CLSN-0] listLibraryImages: category=*ANY*
........
[21-Feb-2014 09:35:53.465] [DEBUG] [CLSN-0] RecvNXCPMessageEx: receive timeout
[21-Feb-2014 09:35:53.465] [DEBUG] *Locks* All locks for session 0 removed
[21-Feb-2014 09:35:53.465] [DEBUG] [CLSN-0] Session closed

Has a new feature been added to time out any client sessions after 15 minutes or based on a configuraiton that I need to review?

Appreciate the help

Victor Kirhenshtein

Hi!

There is hard-coded read timeout on server side, which is used to detect dead sessions. Normally it should not happen, because client sends keep-alive messages once per minute. However, there is a bug in 1.2.12 which prevents client from sending these messages, and so inactive session terminated after 15 minutes. I already fix this bug, and after 1.2.13 release problem should be gone.

Best regards,
Victor