NetXMS Support Forum

Dear NetXMS,

I am currently trying to receive data from our NetXMS Server through the REST API.

Logging in via the basic Authentication header works fine and GET requests to /objects.*, /alarms.*, /info or /predefinedgraphs endpoints returns proper data on valid and error messages on invalid requests.

However, using POST requests on the /sessions and /summaryTable/adHoc endpoints results in {"error":46} responses, when adding a JSON object to the request.

Omitting the JSON object results in an "Invalid argument" message.

Digging through the sourcecode of the latest version (3.0.2329) and cross-checking with the Tomcat9 logs, I could find out that when not adding a JSON object to the request, the logging message in line 100 of AbstractHandler.java ("No POST data in call") is being printed and the method returns the expected error object.

But: When a JSON object is added to the request, the debug message in line 105 ("POST: data = [...]") is not being printed, although it should be and the loglevel is set to "debug" (Other debug messages of the API are visible).

The tomcat logs then state that the internal error is caused by a NullPointerException, so my assumption would be that either new JsonRepresentation(entity) or .getJsonObject() in line 104 of AbstractHandler.java return NULL, thus causing this exception.

Is there anything special that I did not take into account or did I stumble upon a bug? (Stacktrace is attached as screenshot "tomcat9_stacktrace.png")

Just as additional information: I am using Postman (note the missing "description" field in the response, as seen in the attached screenshot "postman_error_46.png") for testing, but I also tried with cURL, giving the same error.

I would be glad, if you could help me with this 

Kind regards,
fbu

Hi,

do you have stack trace below "caused by"? Because this is seems to be root cause.

Best regards,
Victor

Also there should be some debug output. If possible attach full log for request.

I just tested on my build system and it seems to work. This is Jetty log:


2019-10-18 18:03:01,532 DEBUG | qtp635934462-14 | org.netxms.websvc.handlers.AbstractHandler              | POST: data = {"columns":[{"isRegexp":false,"dciName":"System.CPU.Usage","columnName":"System.CPU.Usage"}],"baseObject":"2"}
2019-10-18 18:03:01,533 DEBUG | qtp635934462-14 | org.netxms.websvc.handlers.AbstractHandler              | session_handle: f5b2061a-92f2-439e-b971-8769e7d85fd0
2019-10-18 18:03:01,533 DEBUG | qtp635934462-14 | org.netxms.websvc.handlers.AbstractHandler              | Handler attached to session f5b2061a-92f2-439e-b971-8769e7d85fd0
2019-10-18 18:03:01,533 DEBUG | qtp635934462-14 | org.netxms.websvc.handlers.AbstractHandler              | POST adhoc summaryTable: baseObject = 2
Oct 18, 2019 6:03:01 PM org.restlet.engine.log.LogFilter afterHandle
INFO: 2019-10-18 18:03:01 127.0.0.1 admin 127.0.0.1 8000 POST /summaryTable/adHoc - 200 115 130 12 http://127.0.0.1:8000 Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:69.0) Gecko/20100101 Firefox/69.0 -


and request screenshot attached.

Best regards,
Victor

Hi Victor,

I added a screenshot of the stack trace for the NullPointerException. (Note that the date does not match, because I simply placed the request, again. But it is the same, as for the previous requests)

There are different debug outputs as well, but they are all related to other requests, this error message and stack trace are the first log lines that appear, when performing the request.

Best regards,
fbu

It looks very strange. Null pointer exception happens within tokenizer, that means that content getText() method returns null. If you can modify source and add additional logging for entity and entity.getText() that could help.

Best regards,
Victor

Okay, I will try my best. Is there a way to only build the war file for the API, or do I need to rebuild the whole project?

Kind regards,
fbu

Hi Victor,

I managed to build the changed source code for the API and deploy it on tomcat. You can find the changes in the attachment "sourcecode_change.png" (lines 103 - 108).

The debug-messages are printed in the screenshot "debug_messages.png". I shows that entity.getText() returns NULL, which causes the StringReader called by getJsonObject() (now in line 107) to throw a NullPointerException (as seen in "nullpointer_cause.png".

However, I still don't know why getText() returns NULL in the first place ... I will keep searching for the cause, but I'm not feeling to optimistic about my chances.

Hope, I could help, so far.

Best regards,
fbu

Quick update:

Previously, I was using an NGINX in front of Tomcat9 for hostname and SSL/TLS handling.

When bypassing that NGINX and going directly to the Tomcat, the entity.getText() actually returns the provided data as string. However, new JsonRepresentation(endity).getJsonObject() and [...].getText() still return NULL and cause the same NullPointerException, as before. (see attachment for debug messages)

I am pretty much out of ideas, right now. I'll still try to at least get a similar result with using NGINX, as I will need it in the future, but this might just be a configuration error.

Hope this helps.

Kind regards,
fbu

Update #2:

Based on my previous update, I tested a workaround solution, by simply instantiating the JSONObject, based on the text value returned by the entity:

JSONObject data = new JSONObject(entity.getText());

This works perfectly fine for me, when bypassing the NGINX.

I still don't know what the actual problem is, but it works like this for me - I only need to fix the problem related to NGINX.

Thanks for your help, Victor. Hopefully the root cause of this problem can be determined.

Kind regards,
fbu

Now, for my final update:

After some hours of digging, I found out that NGINX was the reason for the entire problem: It was not configured to pass the POST data to the proxied API server.

Thus, there is no problem with the original API code - I guess that the scenario, as stated in my second update, may be related to the entity's content being empty, once it is read (Somewhere, I read about it being a stream, rather than a storage variable, but I'm not 100% sure about that)

Anyway, I apologize for causing this false alarm and thank you for your support.

Keep up the good work on this tool

Best regards,
fbu