Hide Forgot
Description of problem: If the query POST /metric/data/raw is sent to the server with the 'scheduleId' parameter set to nonexistent schedule, the server responds with HTTP code 204 even though it fails to find the schedule and even though the error message "05:16:55,567 ERROR [org.rhq.enterprise.server.alert.engine.internal.AlertConditionCacheCoordinator] (EJB default - 5) Could not find agent for scheduleId = 99999 " is logged in server.log file. Version-Release number of selected component (if applicable): RHQ 4.13-SNAPSHOT (181e5e7) How reproducible: always Steps to Reproduce: 1. execute REST query POST /metric/data/raw with the body [{"timeStamp":<current_timestamp>, "value":12345, "scheduleId":99999}] 2. check the server's HTTP code response equals 204 3. Actual results: Server responds with HTTP code 204 Expected results: Server responds with some 4xx HTTP code Additional info:
See https://github.com/rhq-project/rhq/pull/104 from Libor
Moving into ER05 as didn't make the ER04 cut.
Libor is taking over.
branch: master link: https://github.com/rhq-project/rhq/commit/39f45463d time: 2014-09-29 15:52:28 +0200 commit: 39f45463d9c17aaef108dcc177898d0bd5319335 author: Libor Zoubek - lzoubek@jezzovo.net message: Merge pull request #104 from lzoubek/bugs/1122444 Bug 1122444 - Server responds with 204 even if it fails to find the sche... branch: master link: https://github.com/rhq-project/rhq/commit/29186360a time: 2014-09-29 15:52:00 +0200 commit: 29186360a4103ad82a86dcc2b257f354c2bf7b1b author: Libor Zoubek - lzoubek@redhat.com message: Bug 1122444 - Server responds with 204 even if it fails to find the schedule Get ISPN cache to work correctly for REST: REST api was using incorrect cache name - so used cache was not preconfigured at all, thatswhy cache entries never expired. Now, we'll deploy rhqRestCache which is preconfigured with lifespan=15m and max-idle=5min. This means, cache entry will be dropped and refreshed every 15minutes no matter how often is accessed and also if not accessed for longer than 5minutes. branch: master link: https://github.com/rhq-project/rhq/commit/c9d5d9125 time: 2014-09-29 15:52:00 +0200 commit: c9d5d91254a6032f9cb2c9f427c6f9d1b7f361ce author: Libor Zoubek - lzoubek@redhat.com message: Bug 1122444 - Server responds with 204 even if it fails to find the schedule upon POST /metric/data/raw request As POST /metric/data/raw accepts data points for various schedule IDs rejecting all data, just because several have invalid scheduleId may not be a good idea. Current fix does: * return 204 (No content) in case all scheduleIds are valid and all data were accepted * returns 201 (rejected data) in case some data points were rejected and some accepted * returns 403 (rejected data) in case all data points were rejected This commit also fixes endpoint POST /metric/data/raw/{resourceId} which now returns 403 in case there is at least 1 non-existing metric for given resource ID (this case was previously failing on NPE)
Cherry-picked over to release/jon3.3.x commit 9caa50ba13e5d693ef46aa847f1af075e0e9e930 Author: Thomas Segismont <tsegismo@redhat.com> Date: Fri Oct 10 18:08:49 2014 +0200 Applied patch created with git diff b4b0238 39f4546
Moving to ON_QA as available to test with the latest brew build: https://brewweb.devel.redhat.com//buildinfo?buildID=394734
Verified on JON 3.3 ER05 Server responds with HTTP code 403 [root@dhcp201-174 ~]# curl -i -u rhqadmin:rhqadmin -X POST -d @/tmp/foo -H 'Content-Type:application/json' http://10.65.201.174:7080/rst/metric/data/raw HTTP/1.1 403 Forbidden Server: Apache-Coyote/1.1 Content-Type: application/json Transfer-Encoding: chunked Date: Mon, 03 Nov 2014 12:45:36 GMT {"message":"Schedules for rejected datapoints do not exist","rejected":[{"timeStamp":1415012528000,"value":12345.0,"scheduleId":99999}]