Hi Andrew, Thanks for the response.
Our Content-Type is actually "text/xml", not JSON, but I can imagine the bug just generally relates to gzip encoding regardless of content type. I'll try out 0.90.4 when it's released. Thanks, Greg. -----Original Message----- From: Andrew Purtell [mailto:[email protected]] Sent: Saturday, 23 July 2011 4:20 PM To: [email protected] Subject: Re: Stargate: Only getting HTTP 200 responses in 0.90.x > We used to get a 201 after creating a scanner with the scanner ID in > the "Location" property. We still get this packet with a valid scanner > ID but it's now an HTTP 200 packet. > The real problem is that we used to get an HTTP 204 when we exhausted the > scanner, but now we get an 200 packet there too. Both problems are due to using the gzip filter. Incorporated in https://issues.apache.org/jira/browse/HBASE-4105 Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White) ----- Original Message ----- > From: Greg Cottman <[email protected]> > To: "HBase List ([email protected])" <[email protected]> > Cc: > Sent: Monday, July 18, 2011 11:57 PM > Subject: Stargate: Only getting HTTP 200 responses in 0.90.x > > Hi guys, > > We're using the Stargate REST server to access HBase data and as of 0.90.1 > we getting HTTP 200 packets where we used to get 201s and 204s. There seem > to > be two significant changes... > > We used to get a 201 after creating a scanner with the scanner ID in the > "Location" property. We still get this packet with a valid scanner ID > but it's now an HTTP 200 packet. This doesn't matter too much because > we are mostly interested in the Location property anyway. > > The real problem is that we used to get an HTTP 204 when we exhausted the > scanner, but now we get an 200 packet there too. The documentation on > scanners > at http://wiki.apache.org/hadoop/Hbase/Stargate#A5says we should still expect > this to be the case. > > These 200 packets appear to have 20 bytes of garbage in the content. The > content encoding says they're gzip streams but they're not, and they > seem to appear on any 200 packet that doesn't carry a specific payload. > Because it's a dodgy 200 packet at the end of the legitimate 200 packets > carrying the scanner results, we are trying to decode this as just another > data > packet at which point we crash and burn. :-( > > Anyone seeing anything like this? Any ideas on why the packets no longer > match > the documented protocol? > > Thanks, > Greg. > > > ________________________________ > Greg Cottman > Technical Architect, Cloud Databases > Quest Software, Melbourne > Tel: +61 3 9811 8057 > [email protected]<mailto:[email protected]> >
