Error messages instead of HTTP 500

[andyjagoe]

Amit...thanks again for the efforts on kiji-rest. I'm liking it...but the lack of debugging information is making it very hard to use. When I'm posting json data to a large table, if anything is wrong the server returns an HTTP 500 with no error message in the console or in the logs. This is extremely painful to uncover things like a number mistakenly showing up as a float instead of a long, etc...

Is there a way you can pass this info on to the console or the logs? Even just a stacktrace would be great. Is this available somewhere else in Kiji perhaps and I'm missing it?

[shashir]

REST sends all logging information to the console or the kiji-rest/logs/
directory based on the setup in configuration.yml. I think the default
configuration sends all application logs to kiji-rest/logs/app.log and
request logs to kiji-rest/logs/request.log.

Can you tell me what you get in the app.log and the requests.log when you
make that troublesome POST request?

On Thu, Jun 6, 2013 at 9:27 AM, andyjagoe [email protected] wrote:

Amit...thanks again for the efforts on kiji-rest. I'm liking it...but the
lack of debugging information is making it very hard to use. When I'm
posting json data to a large table, if anything is wrong the server returns
an HTTP 500 with no error message in the console or in the logs. This is
extremely painful to uncover things like a number mistakenly showing up as
a float instead of a long, etc...

Is there a way you can pass this info on to the console or the logs? Even
just a stacktrace would be great. Is this available somewhere else in Kiji
perhaps and I'm missing it?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3
.

[andyjagoe]

Thanks Shashir. app.log looks like what I was looking for. I don't remember seeing this sent to the console. Maybe there is a debug flag I need to set in configuration.yml that is by default disabled for production

[shashir]

Awesome!

So logging is handled by Dropwizard backend. The configuration.yml file
(lives in kiji-rest/conf/) can be visually divided into two portions: the
top portion of configuration.yml is devoted to KijiREST configurations and
the bottom portion is devoted to Dropwizard configuration.

By default, the kiji-rest/conf/configuration.yml sends application logs
only to the kiji-rest/logs/app.log file and not to the console (this is to
simulate production settings). For your purpose, you may want to turn
console logging ON.

In the Dropwizard section, you will see something like:

[...]
logging:
console:

• enabled: false # you may want to set this as true*
  [...]
  file:
  enabled: true
  currentLogFilename: ./logs/app.log # where the logs are going by default
  [...]

Shashir

On Thu, Jun 6, 2013 at 2:17 PM, andyjagoe [email protected] wrote:

Thanks Shashir. app.log looks like what I was looking for. I don't
remember seeing this sent to the console. Maybe there is a debug flag I
need to set in configuration.yml that is by default disabled for production

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3#issuecomment-19074750
.

[andyjagoe]

Thanks Shasir!

[andyjagoe]

Shasir/Amit,

I'm re-opening this issue because it's still really tough to work through error conditions with Kiji-REST. I'm trying to do an HTTP DELETE to remove a record, but am unable to do so.

I have a record in the database I can retrieve by issuing a GET to the following URL: http://server:8080/v1/instances/default/tables/users/rows?eid=['[email protected]']. However, when I issue a DELETE to the same URL, I receive an HTTP 500 error.

The request.log and app.log is below and is not really helpful. I think maybe the larger issue here is the need for documentation somewhere on the REST endpoints themselves. Also, is it really appropriate for a web service to return an HTTP 500 in this situation? I've noticed that all error conditions in Kiji-REST seem to return an HTTP 500--this is not expected behavior and I would only expect an HTTP 500 if Kiji-REST encountered an internal application error due to some unexpected situation (e.g. a bug)...

I'd really appreciate any help (and documentation ;-) you have!

requests.log (notice one url encoded, one not.... both errors.)

10.250.n.n - - [09/Jun/2013:03:50:04 +0000] "DELETE /v1/instances/default/tables/users/rows?eid=['[email protected]'] HTTP/1.1" 500 0 29 29
10.250.n.n - - [09/Jun/2013:04:04:04 +0000] "DELETE /v1/instances/default/tables/users/rows?eid=%5B%27first%40last.com%27%5D HTTP/1.1" 500 0 3 3

app.log

ERROR [2013-06-09 03:30:30,381] com.sun.jersey.spi.container.ContainerResponse: Exception mapper org.kiji.rest.WebAppExceptionMapper@24adb083 for Throwable javax.ws.rs.WebApplicationException threw a RuntimeException when attempting to obtain the response
ERROR [2013-06-09 03:30:30,383] com.sun.jersey.spi.container.ContainerResponse: Mapped exception to response: 500 (Internal Server Error)
! java.lang.IllegalArgumentException: null
! at com.sun.jersey.core.spi.factory.ResponseBuilderImpl.status(ResponseBuilderImpl.java:126) ~[kiji-rest-0.1.0.jar:0.1.0]
! at javax.ws.rs.core.Response$ResponseBuilder.status(Response.java:406) ~[kiji-rest-0.1.0.jar:0.1.0]
! at org.kiji.rest.WebAppExceptionMapper.toResponse(WebAppExceptionMapper.java:51) ~[kiji-rest-0.1.0.jar:0.1.0]
! at org.kiji.rest.WebAppExceptionMapper.toResponse(WebAppExceptionMapper.java:40) ~[kiji-rest-0.1.0.jar:0.1.0]
! at com.sun.jersey.spi.container.ContainerResponse.mapException(ContainerResponse.java:463) [kiji-rest-0.1.0.jar:0.1.0]
! at com.sun.jersey.spi.container.ContainerResponse.mapWebApplicationException(ContainerResponse.java:427) [kiji-rest-0.1.0.jar:0.1.0]
! at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1444) [kiji-rest-0.1.0.jar:0.1.0]
! at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1391) [kiji-rest-0.1.0.jar:0.1.0]
! at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1381) [kiji-rest-0.1.0.jar:0.1.0]
! at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416) [kiji-rest-0.1.0.jar:0.1.0]
! at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:538) [kiji-rest-0.1.0.jar:0.1.0]
! at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:716) [kiji-rest-0.1.0.jar:0.1.0]
! at javax.servlet.http.HttpServlet.service(HttpServlet.java:848) [kiji-rest-0.1.0.jar:0.1.0]
! at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:669) [kiji-rest-0.1.0.jar:0.1.0]
! at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1448) [kiji-rest-0.1.0.jar:0.1.0]
! at com.yammer.dropwizard.servlets.ThreadNameFilter.doFilter(ThreadNameFilter.java:29) [kiji-rest-0.1.0.jar:0.1.0]
! at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419) [kiji-rest-0.1.0.jar:0.1.0]
! at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455) [kiji-rest-0.1.0.jar:0.1.0]
! at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075) [kiji-rest-0.1.0.jar:0.1.0]
! at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384) [kiji-rest-0.1.0.jar:0.1.0]
! at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009) [kiji-rest-0.1.0.jar:0.1.0]
! at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135) [kiji-rest-0.1.0.jar:0.1.0]
! at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) [kiji-rest-0.1.0.jar:0.1.0]
! at com.yammer.metrics.jetty.InstrumentedHandler.handle(InstrumentedHandler.java:200) [kiji-rest-0.1.0.jar:0.1.0]
! at org.eclipse.jetty.server.handler.GzipHandler.handle(GzipHandler.java:301) [kiji-rest-0.1.0.jar:0.1.0]
! at com.yammer.dropwizard.jetty.BiDiGzipHandler.handle(BiDiGzipHandler.java:123) [kiji-rest-0.1.0.jar:0.1.0]
! at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154) [kiji-rest-0.1.0.jar:0.1.0]
! at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116) [kiji-rest-0.1.0.jar:0.1.0]
! at org.eclipse.jetty.server.Server.handle(Server.java:368) [kiji-rest-0.1.0.jar:0.1.0]
! at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489) [kiji-rest-0.1.0.jar:0.1.0]
! at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53) [kiji-rest-0.1.0.jar:0.1.0]
! at org.eclipse.jetty.server.AbstractHttpConnection.content(AbstractHttpConnection.java:953) [kiji-rest-0.1.0.jar:0.1.0]
! at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.content(AbstractHttpConnection.java:1014) [kiji-rest-0.1.0.jar:0.1.0]
! at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:861) [kiji-rest-0.1.0.jar:0.1.0]
! at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:240) [kiji-rest-0.1.0.jar:0.1.0]
! at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72) [kiji-rest-0.1.0.jar:0.1.0]
! at org.eclipse.jetty.server.nio.BlockingChannelConnector$BlockingChannelEndPoint.run(BlockingChannelConnector.java:298) [kiji-rest-0.1.0.jar:0.1.0]
! at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608) [kiji-rest-0.1.0.jar:0.1.0]
! at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543) [kiji-rest-0.1.0.jar:0.1.0]
! at java.lang.Thread.run(Thread.java:722) [na:1.7.0_21]

[andyjagoe]

Also tried using the rowkey instead of entity id after finding this blog post (http://www.kiji.org/2013/05/20/revealing-kijirest-resources/), but I still get the same error:

10.250.n.n - - [09/Jun/2013:04:13:55 +0000] "DELETE /v1/instances/default/tables/users/rows/3e67616e6479406a61676f652e636f6d00 HTTP/1.1" 500 0 3 3

[shashir]

@andyjagoe Great question! We really appreciate your feedback! We have a two more KijiREST blog posts in our pipeline so stay tuned for more on that.

Simple answer

DELETE is (for now) intentionally unimplemented for cells, rows, tables, and instances. However, it's not a good idea to send a "500 Internal server error" code when a "405 Method not allowed" is more appropriate.

Why not (yet) implement DELETE?

DELETE on cells (perhaps even DELETE-ing all the cells of a row, thus a row) may be considered unnecessary in the HBase+Kiji application world because cells have timestamps. So it may be better from a data conservation perspective to put a cell with a later timestamp to the same column and the older cell persists for analysis at a later time. So DELETE being unimplemented is serving as a heavy-handed access control right now.

Since the KijiSchema API's command line tools allow deletes and the API itself provides significantly more sophisticated table interactions, there are arguments from the feature completion perspective to just implement DELETE for cells (and perhaps tables, instances as well?). And your use-case would be very useful in formalizing the semantics of DELETE.

Going forward

We track our issues on http://jira.kiji.org (instead of the more limited Github issue-tracker) so let's move the discussion there. Also, I have created a ticket REST-19 for properly sending DELETE (and perhaps other valid HTTP requests) to a 405 exception for now.

Also, we would really like to learn about your use-case and future application bugs you may encounter so please join the user list: [email protected]

[andyjagoe]

Thanks Shashir. This makes sense, and I agree that it should probably be
done for feature completeness. Also, thanks for sending me the full Kiji
REST specs. Can you put a link to them in the project readme so it's
available on GitHub for others?

On Monday, June 10, 2013, Shashir Reddy wrote:

@andyjagoe https://github.com/andyjagoe Great question! We really
appreciate your feedback! We have a two more KijiREST blog posts in our
pipeline so stay tuned for more on that.
Simple answer

DELETE is (for now) intentionally unimplemented for cells, rows, tables,
and instances. However, it's not a good idea to send a "500 Internal server
error" code when a "405 Method not allowed" is more appropriate.
Why not (yet) implement DELETE?

DELETE on cells (perhaps even DELETE-ing all the cells of a row, thus a
row) may be considered unnecessary in the HBase+Kiji application world
because cells have timestamps. So it may be better from a data conservation
perspective to put a cell with a later timestamp to the same column and the
older cell persists for analysis at a later time. So DELETE being
unimplemented is serving as a heavy-handed access control right now.

Since the KijiSchema API's command line tools allow deletes and the API
itself provides significantly more sophisticated table interactions, there
are arguments from the feature completion perspective to just implement
DELETE for cells (and perhaps tables, instances as well?). And your
use-case would be very useful in formalizing the semantics of DELETE.
Going forward

We track our issues on http://jira.kiji.org (instead of the more limited
Github issue-tracker) so let's move the discussion there. Also, I have
created a ticket REST-19 https://jira.kiji.org/browse/REST-19 for
properly sending DELETE (and perhaps other valid HTTP requests) to a 405
exception for now.

Also, we would really like to learn about your use-case and future
application bugs you may encounter so please join the user list:
[email protected] <javascript:_e({}, 'cvml', '[email protected]');>

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3#issuecomment-19223093
.