Question
BPM Company
NL
Last activity: 16 Jul 2018 10:16 EDT
NullPointerException in log when Pega REST service gets a HEAD http message
I configured uptimerobot.com to monitor a REST service that we provide from Pega 7.3.1. They send a GET and HEAD http message each 5 minutes to the service URL. I noticed that the HEAD message generates a NullPointerException in the log and I'd like to avoid that.
I know that Service REST rules support only the GET, POST, PUT and DELETE methods. But I did some testing from Postman and found these responses on the HTTP methods:
Methods that return a 501 Not Implemented status code: PATCH, COPY, LINK, UNLINK, PURGE, LOCK, UNLOCK, PROPFIND & VIEW. These messages will not be registered if you enable service monitoring;
Methods that return a 500 Internal Server Error status code: HEAD & OPTIONS. Only a HEAD message will be registered when service monitoring is enabled.
So my conclusion is that HEAD and OPTIONS are implemented but are not customizable.
My main question is: Is it possible to avoid a NullPointerException with a HEAD message?
See the log with some extra debug logs in. The bold line will be generated with regular log level settings.
I configured uptimerobot.com to monitor a REST service that we provide from Pega 7.3.1. They send a GET and HEAD http message each 5 minutes to the service URL. I noticed that the HEAD message generates a NullPointerException in the log and I'd like to avoid that.
I know that Service REST rules support only the GET, POST, PUT and DELETE methods. But I did some testing from Postman and found these responses on the HTTP methods:
Methods that return a 501 Not Implemented status code: PATCH, COPY, LINK, UNLINK, PURGE, LOCK, UNLOCK, PROPFIND & VIEW. These messages will not be registered if you enable service monitoring;
Methods that return a 500 Internal Server Error status code: HEAD & OPTIONS. Only a HEAD message will be registered when service monitoring is enabled.
So my conclusion is that HEAD and OPTIONS are implemented but are not customizable.
My main question is: Is it possible to avoid a NullPointerException with a HEAD message?
See the log with some extra debug logs in. The bold line will be generated with regular log level settings.
2018-07-13 09:04:38,964 [p-apr-8080-exec-1368] [ STANDARD] [ ] [ ] ( internal.services.ServiceAPI) DEBUG <RemovedHostFromLogMessage> - Constructing alert for messageId PEGA0011
2018-07-13 09:04:38,964 [p-apr-8080-exec-1368] [ STANDARD] [ ] [ ] ( internal.services.ServiceAPI) DEBUG <RemovedHostFromLogMessage> - Enabling alert for messageId PEGA0011
2018-07-13 09:04:38,964 [p-apr-8080-exec-1368] [ STANDARD] [ ] [ ] ( internal.services.ServiceAPI) INFO <RemovedHostFromLogMessage>|Rest|Abillity|API|customers - Processing service request...
2018-07-13 09:04:38,965 [p-apr-8080-exec-1368] [ STANDARD] [ ] [ ] ( internal.services.ServiceAPI) DEBUG <RemovedHostFromLogMessage>|Rest|Abillity|API|customers - entering postLockCleanup()
2018-07-13 09:04:38,965 [p-apr-8080-exec-1368] [ STANDARD] [ ] [ ] ( internal.services.ServiceAPI) ERROR <RemovedHostFromLogMessage>|Rest|Abillity|API|customers - Rest service [Abillity][API][customers] failed::java.lang.NullPointerException
2018-07-13 09:04:38,965 [p-apr-8080-exec-1368] [ STANDARD] [ ] [ ] ( internal.services.ServiceAPI) DEBUG <RemovedHostFromLogMessage> - leaving postLockCleanup()
Pegasystems Inc.
GB
BPM Company
NL
Hi Moiss,
1) See my original question again: We were facing irregular 504 Gateway Timeouts on our cloud environment so therefore I started monitoring the REST service with uptimerobot.com . They are sending a HEAD each 5 minutes to check if the HTTP resource is up. I asked them why they use HEAD, this is the answer: "Actually, HEAD requests are the default and the monitoring engine switched to GET if HEAD fails."
2) See answer 1, this is the default behaviour of uptimerobot.com .
My question then: If HEAD is not implemented or customizable, why does it give a NullPointerException in the log and not just a 501 Not Implemented status code without any log lines?
Pegasystems Inc.
GB
Hi. Thanks for clarification.
I personally would not use any method which is undocumented - for me this not only means not supported, but rather not completely implemented or used for internal purposes.
Also, as this is not documented (= not supported as we do not made any commitment for that in regards to configuration) the implementation could be changed without any notice and even removed. Which means having one outcome as you see in the log in one version of the Product could be different in any other version.
So, I'd push back to the service you wanted to use to stick with GET only.
And if HEADER is a-must, then you need to raise Enhancement request to have this implemented and configuration UI added to the Product and documented to have it supported.
Hi.
2 questions:
1. Why you are trying to use HEAD if you "know that Service REST rules support only the GET, POST, PUT and DELETE methods"?
2. What you cannot achieve using just GET method that made you to use HEAD instead?