Hi Greg, Yes the bug affects any use of the gzip filter.
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: "[email protected]" <[email protected]> > Cc: > Sent: Sunday, July 24, 2011 10:08 PM > Subject: RE: Stargate: Only getting HTTP 200 responses in 0.90.x > > 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]> >> >
