Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Callback or response from the parse-server in case of mongo DB or any long processing timeout #3122

Closed
swami701 opened this issue Nov 26, 2016 · 1 comment

Comments

@swami701
Copy link

Environment Setup

Server

  • Local parse-server hosted in AWS Singapore

Database

  • mLab - In US (us-east)

We're running our local parse server in AWS Singapore. We're using mLab in US for our Database. Since there is a latency involved, for some of the queries we receive timeout. We're currently working on improving the slow queries by building some indexes. And we wanted to give a response from the parse-server if a specific timeout has reached.

For eg:
We're running parse-server using express. We're using connect-timeout for checking the timeout for a request.

Let us say if a timeout of 10 secs has been reached, we would like to send a response with the status code 408 and response as below

{ 
    "message": "Request timedout!"
}

We were trying to achieve with the following code, but couldn't able to do since we don't have a callback from the parse-server

Could you guys please suggest some ways for us?

var port = process.env.PORT || 1337;
var mountPath = process.env.PARSE_MOUNT || '/parse';
var parseConfiguration = {
    databaseURI: process.env.DATABASE_URI || 'mongodb://localhost:27017/dev',
    cloud: process.env.CLOUD_CODE_MAIN || __dirname + '/cloud/main.js',
    appId: process.env.APP_ID,
    masterKey: process.env.MASTER_KEY, //Add your master key here. Keep it secret!
    serverURL: process.env.SERVER_URL || 'http://localhost:' + port + mountPath,  // Don't forget to change to https if needed,
    push: {
        android: {
            senderId: process.env.GCM_SENDER_ID,
            apiKey: process.env.GCM_API_KEY
        }
    },
    publicServerURL: process.env.PUBLIC_SERVER_URL,
    emailAdapter: SimpleSendGridAdapter({
        apiKey: process.env.SENDGRID_API_KEY,
        fromAddress: process.env.SENDGRID_EMAIL_FROM
    })
};

if (process.env.LOG_LEVEL) {
    parseConfiguration.logLevel = process.env.LOG_LEVEL;
}

var parseApi = new ParseServer(parseConfiguration);
var app = express();
app.use(mountPath, timeout('10s'), (req, res, next) => {
    req.on("timeout", function (evt) {
        if (req.timedout) {
            if (!res.headersSent) {
                res.status(408).send({
                    message: 'Request timedout!'
                });
            }
        }
    });
    parseApi(req, res, next);
});

And I guess since node works on event driven approach we can't avoid the CPU, memory usages. But at least we wanted to avoid the Error: Can't set headers after they are sent in the logs, since we're listening for timeout event and sending the response

We would like to have some timeout option in the parse configuration or some work around if parse-server is able to give the callback. Or may be there is a better way.

app.use(mountPath, timeout('10s'), (req, res, next) => {
    req.on("timeout", function (evt) {
        if (req.timedout) {
            if (!res.headersSent) {
                res.status(408).send({
                    message: 'Request timedout!'
                });
            }
        }
    });
    parseApi(req, res, (response) => {
        if (!req.timedout) {
            res.send(response);
        }
    });
});

Thank you very much.

@swami701 swami701 changed the title Callback or response from the parse-server in case of mongo timeout or any long processing Callback or response from the parse-server in case of mongo DB or any long processing timeout Nov 26, 2016
@hramos
Copy link
Contributor

hramos commented Feb 10, 2017

It's not clear to me if this should be an issue. Is there something actionable that can be done by opening a PR? Or are you looking to start a discussion? For the latter, I suggest using Serverfault or Stack Overflow, as we're not using GitHub issues for general Q&A.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants