Bug 980320

Summary:	node.js: Cannot read property 'getsockname' of undefined
Product:	OpenShift Online	Reporter:	Ilkkah <ilkkah>
Component:	Containers	Assignee:	Hiro Asari <hasari>
Status:	CLOSED NOTABUG	QA Contact:	libra bugs <libra-bugs>
Severity:	low	Docs Contact:
Priority:	low
Version:	2.x	CC:	ilkkah, jkeck, mpatel
Target Milestone:	---	Keywords:	Reopened
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-10-26 22:14:01 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Ilkkah 2013-07-02 04:58:32 UTC

Description of problem:
The site in question: http://dtest1-ile.rhcloud.com/
I made a Node bug report too: https://github.com/joyent/node/issues/5774

At Node 0.10.11 (the latest code seems to be similar) I get this:

net.js:1071
    if (port && handle.getsockname && port != handle.getsockname().port) {
                      ^
TypeError: Cannot read property 'getsockname' of undefined
    at net.js:1071:23
    at Object.1:1 (cluster.js:587:5)
    at handleResponse (cluster.js:171:41)
    at respond (cluster.js:192:5)
    at handleMessage (cluster.js:202:5)
    at process.EventEmitter.emit (events.js:117:20)
    at handleMessage (child_process.js:318:10)
    at Pipe.channel.onread (child_process.js:345:11)



Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. run "node server.js" at http://dtest1-ile.rhcloud.com/
2.
3.

Actual results:
Crashes

Expected results:
Should run

Additional info:

Is there something in OpenShift's net/socket handling that I should know?

Comment 1 Mrunal Patel 2013-07-02 15:45:37 UTC

Looks like handle itself is undefined. Are you able to reproduce the issue with some simple test code?

Comment 2 Ilkkah 2013-07-03 00:43:18 UTC

The handle is indeed undefined. The lack of error handling is Node's fault.

But why the handle cannot be obtained is something that OpenShift may be partly responsible with, that's why I made this bug report.

The code itself is pretty complicated. I'm not sure I could simplify it, but I could see what I can do in the future if needed.

Thanks.

Comment 3 Hiro Asari 2013-07-03 01:58:33 UTC

Without the intimate knowledge of the application code, it is near impossible to figure out why `handle` is not defined. (We don't have access to your gear on http://dtest1-ile.rhcloud.com/)

https://github.com/joyent/node/issues/5330 may be relevant here, since it refers to approximately the same line in the same file (net.js). This issue is presumably fixed in 10.11, but maybe there are still issues to be resolved.

My best bet is to pursue it upstream with the node team.

The information given so far does not indicate that there is something that we can change to make your application go. Simplifying your application to isolate the problematic parts of your application and/or node.js would be most helpful, I think.

Comment 4 Hiro Asari 2013-09-12 15:40:11 UTC

Hello, have you had a chance to investigate this?

We need a simple reproduction to go any further.

Comment 5 Hiro Asari 2013-10-22 20:06:12 UTC

I'm closing this. If there is something else we can try to investigate this further, do let us know.

Comment 6 Ilkkah 2013-10-22 23:23:56 UTC

Hey,

Sorry I didn't get back.

I just tried with the latest node, 0.10.21, but it still happens. 

I think it would take quite a bit of time to debug this further. If there is anyone at RedHat who wants to take a look, I could give all the access needed. But otherwise I think I will just delete the application.

Thanks.

Comment 7 Hiro Asari 2013-10-23 14:38:19 UTC

Hi there.

The best bet is to have a simple reproduction. Can you strip sensitive information of your application while retaining the problem?

As I said earlier, it is very difficult to guess what might be causing the problem.

Comment 8 Ilkkah 2013-10-23 16:55:37 UTC

Hi,

The app in question is a Derby app (http://derbyjs.com/) and it's the default app that derby creates when starting a new project (command: derby new). So it doesn't contain any sensitive information.

If you have time to inspect this, please go ahead, you can have the access to it, if you need a public key placed there, you can do it or I can do it for you. 

The app itself is both very minimal and also quite large - the Derby framework is large, but the default app created is not. So it's hard to strip down. If it is needed to strip down, then I think it should be done component-by-component: for example creating an express app, and then adding components into it one-by-one and seeing when the problem happens.

I would think though that it is possible to debug the cause without stripping the app. It may even be easy, but it would require some debugging for sure.

Comment 9 Hiro Asari 2013-10-23 20:24:52 UTC

https://github.com/codeparty/derby/issues/263#issuecomment-18290683 and ensuing comments lead me to believe that you'll need to bind your application to the correct host and port for OpenShift. For Node.js, they will be OPENSHIFT_NODEJS_IP and OPENSHIFT_NODEJS_PORT. (See, for example: https://github.com/openshift-quickstart/nodejs-example/blob/master/server.js#L6-L7)

See http://openshift.github.io/documentation/oo_cartridge_guide.html#nodejs for further information.

Comment 10 Ilkkah 2013-10-26 22:14:01 UTC

That really seemed to be the problem. I'm very sorry to bother you this much with this, when it was mainly my fault. 

BTW, a side note: on some other Node hosting service the IP address binding isn't needed. So on OpenShift this is an extra step. Actually, Derby right now listens just the 'default ip', i.e. doesn't provide any IP address, but just the port. So, what it does is:
   
   server.listen(port, callback);

... and no hostname/ip address.

So this may limit options on OpenShift if IP address is required. 

This meant as a "fyi" and constructive information.

I'll close this issue. Thanks.