Request Timeout for Annotation Store on Heroku

I have the 1.6 branch of Annotation Studio and the latest MIT Annotation Store up and running on Heroku. My API_SECRET in AS matches my SECRET in the datastore; API_CONSUMER matches CONSUMER. API_URL is correct and the API is up and running. However, whenever I try to search or create a new annotation, the request times out. I’ve tried this in Firefox and Chrome. The Heroku logs for the data store also show time outs, even though the annotation data comes through. Here’s a truncated example:

2014-06-02T22:13:19.066593+00:00 heroku[router]: at=error code=H12 desc="Request timeout" method=GET path=/api/search?uri=http%3A

A query of the Mongodb shows no new annotations getting created. Any troubleshooting suggestions? Thanks.

Hi @mikewidner,

Let’s try to isolate the issue. First thought: we could exercise the API with a different REST client.

In Chrome, you can install postman, and craft requests with all the requisite headers. The only one that you’ll have to dig up is the JWT token, which you can find in the source of the document view. https://chrome.google.com/webstore/detail/postman-rest-client/fdmmgilgnpjigdojojpjoooidkmcomcm/details?hl=en

At first blush, though it seems possible that that’s an actual error on the Heroku platform. Drop me a line via hangout if you want to work on this together today.

Thanks @jamiefolsom. I’m narrowing it down. The request timeout is coming from the API itself and appears to be a problem authenticating to the Mongo DB. I was able to run it locally both via the AS app and Postman. The mongo credentials Heroku is giving me don’t allow me to connect, though, so I’m pretty sure that’s the problem now. I’ve sent a support request in and will see what comes of it.

Yup. That was it. Using the wrong connection string, of all things, now it’s working. SMH

Great, glad you figured it out! We recently discovered recently that our database host had reset the credentials on our database as a security measure, which if you configure things exactly as recommended, wouldn’t have caused a problem, but since our API app was using differently named config variables, it broke the API.