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

ParseServer - functions hangs with curl showing "Empty reply from server" #2605

Closed
vkeepe opened this issue Aug 29, 2016 · 18 comments
Closed

Comments

@vkeepe
Copy link

vkeepe commented Aug 29, 2016

I have cloud code that I am trying to run. I am in process of migrating. When I call my functions the server hangs. All operation on classes works fine.

I have checked that it hangs at query.find(). I have verbose: true in my Express code. Is there a way to debug it more to see where the problem might be occurring. I have tried #705

Environment Setup

  • Server
    • parse-server version : 2.2.18
    • Operating System: OS X El Capitan
    • Localhost or remote server? (AWS, Heroku, Azure, Digital Ocean, etc): localhost
  • Database
    • MongoDB version: 3.0.12
    • Storage engine: MMAPv1
    • Hardware: mlab
    • Localhost or remote server? : mLab
  • Code

    Logs/Trace

You can turn on additional logging by configuring VERBOSE=1 in your environment.

verbose: REQUEST for [POST] /api-dev/functions/myFunction: {} method=POST, url=/api-dev/functions/myFunction, host=localhost:4000, user-agent=curl/7.43.0, accept=/, x-parse-application-id=myAppId, x-parse-rest-api-key=myRestKey, content-type=application/json, content-length=2,

@vkeepe
Copy link
Author

vkeepe commented Aug 29, 2016

I have also taken the code from https://github.com/ParsePlatform/parse-server-example. Placed a simple find query in cloud code and it hangs as well. Am I missing some configuration?

@flovilmart
Copy link
Contributor

This looks like a misconfiguration problem, did you correctly set the serverURL option, is you database URL correct etc...

@vkeepe
Copy link
Author

vkeepe commented Aug 29, 2016

@flovilmart databaseURI is fine as all /classes calls are working fine. serverURL is also set. Here is my code. serverURL is set to http://localhost:4000/parse

Note my dbServer is in mLab. All calls are working fine via parse.com. Does localhost matters?

var api = new ParseServer({ databaseURI: databaseUri || 'mongodb://localhost:27017/dev', cloud: process.env.CLOUD_CODE_MAIN || __dirname + '/cloud/main.js', appId: process.env.APP_ID || 'myAppId', masterKey: process.env.MASTER_KEY || '', serverURL: process.env.SERVER_URL || 'http://localhost:4000/parse' });

@flovilmart
Copy link
Contributor

Yeah it matters, is your server listening on port 4000? CloudCode uses that value in order to communicate with the server/database.

@vkeepe
Copy link
Author

vkeepe commented Aug 29, 2016

Yes, my server is listening on port 4000. I have telnet and confirmed it. I have noticed that if I changed to wrong url; I do get error message. With correct URL; it hangs on query.find({ useMasterKey: true }).

@flovilmart
Copy link
Contributor

So I'm not sure what's wrong... Do you use a promise?

query.find({ useMasterKey: true }).then(function() {
   // success
}, function(err) {
   // handle err
})

@vkeepe
Copy link
Author

vkeepe commented Aug 29, 2016

Yes I am using promise. It is not getting into success or error.

@flovilmart
Copy link
Contributor

Just to make sure, parse-server is mounted on /api-dev/ right? Your serverURL should be http://localhost:4000/api-dev

@vkeepe
Copy link
Author

vkeepe commented Aug 29, 2016

Sorry initially when I created the issue; I was on my code (/api-dev). Now I am using parse-server-example with (/parse)

The parse-server is mounted on /parse. The server is configured for
http://localhost:4000/parse

See the code below:

var mountPath = process.env.PARSE_MOUNT || '/parse';
console.log("Mount On: " + mountPath); //shows correct
app.use(mountPath, api);

@flovilmart
Copy link
Contributor

You should probably ask on stackoverflow as what you're describing is heavily tested, and don't seem to be a problem that I can reproduce.

@vkeepe
Copy link
Author

vkeepe commented Aug 29, 2016

I understand. Is there a way I can place better logging on ParseServer? I know it is hanging on query.find. I want to see if I can debug this further.

@flovilmart
Copy link
Contributor

you can run it attaching to a debugger and looking what's going on. Try https://github.com/node-inspector/node-inspector that may help.

@vkeepe
Copy link
Author

vkeepe commented Aug 29, 2016

I will not be closing this issue as there is some problem that needs to be looked into. There might be specific condition the server is behaving this way.

@flovilmart
Copy link
Contributor

Yeah but unreproducible... Feel free to reopen with more informations and a clear way to reproduce, a stack trace etc...

@vkeepe
Copy link
Author

vkeepe commented Aug 29, 2016

Not sure how many out there are using
node -v
v6.4.0
npm -v
3.10.3

I will let you know what I find. Can't see any stack trace etc. Server code is not throwing anything and that is the problem. I will look into node-inspector to see if I can find anything.

@flovilmart Debugger throws error at json.js

screen shot 2016-08-29 at 3 49 53 pm

I am going to next go back to older version of node.js

@vkeepe
Copy link
Author

vkeepe commented Aug 29, 2016

@flovilmart So here is what is happening:

If I change my code to use the default port 1337 everything works fine. If I change it to 4000 it stops working.

Note sure if I am missing anything for port change.

@flovilmart
Copy link
Contributor

It means that your server is not properly listening on 4000 on the localhost and indeed listening on 1337.

@vkeepe
Copy link
Author

vkeepe commented Aug 29, 2016

Thanks. Figured out that one of the external software running on my laptop was also using 4000. Some reason server did not error out while starting on 4000. I have not looked further but stopping the software made it work.

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