Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1122444 - Server responds with 204 even if it fails to find the schedule upon POST /metric/data/raw request
Summary: Server responds with 204 even if it fails to find the schedule upon POST /met...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Operations Network
Classification: JBoss
Component: REST
Version: JON 3.2.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ER05
: JON 3.3.0
Assignee: Libor Zoubek
QA Contact: Sunil Kondkar
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-23 09:31 UTC by Jan Bednarik
Modified: 2015-11-02 00:44 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-12-11 14:04:17 UTC
Type: Bug

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Description Jan Bednarik 2014-07-23 09:31:12 UTC 
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:
Comment 3 Heiko W. Rupp 2014-09-26 09:11:32 UTC 
See https://github.com/rhq-project/rhq/pull/104 from Libor
Comment 4 Simeon Pinder 2014-09-29 08:12:54 UTC 
Moving into ER05 as didn't make the ER04 cut.
Comment 5 Heiko W. Rupp 2014-09-29 13:12:53 UTC 
Libor is taking over.
Comment 6 Libor Zoubek 2014-09-29 18:28:42 UTC 
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)
Comment 7 Thomas Segismont 2014-10-10 16:10:29 UTC 
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
Comment 9 Simeon Pinder 2014-10-21 20:24:32 UTC 
Moving to ON_QA as available to test with the latest brew build:
https://brewweb.devel.redhat.com//buildinfo?buildID=394734
Comment 10 Sunil Kondkar 2014-11-03 12:52:22 UTC 
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}]
Note You need to log in before you can comment on or make changes to this bug.