JMX Docs Issue

[dmikusa]

I don't believe that this statement is correct.

The LOCAL_PORT can be any open port on your computer, but typically matches the REMOTE_PORT where possible.

https://github.com/cloudfoundry/java-buildpack/blob/master/docs/framework-jmx.md#creating-ssh-tunnel

I think that LOCAL_PORT will need to match the REMOTE_PORT. If you change LOCAL_PORT to something different the JMX connection will succeed, but the RMI connection will fail, because it does match com.sun.management.jmxremote.rmi.port.

Ultimately it would be cool if you could set com.sun.management.jmxremote.port and com.sun.management.jmxremote.rmi.port independently, or perhaps if the build pack auto incremented com.sun.management.jmxremote.rmi.port for each app instance. That way you could access multiple instances at the same time. Ex: instance #0 on 5000, #1 on 5001, etc...

Thanks

[nebhale]

While the problem is undoubtedly real, I'm not sure why it is. The JSR-160 and RMI ports always match one another, so the tunnel for one should match the tunnel for the other. I'm guessing something is doing an internal redirect causing the issue.

Outside of an easy fix, I think we'll update the docs to be more clear rather than making the implementation more robust. Instance choice should be handled via the cf ssh -i argument, and I don't want to add anything additional if you can't use non-matching ports. In the end, this is not something that should be used very often so putting a ton of engineering into it isn't in line with our goals.

I'll do some research about tunneling JSR-160/RMI over SSH, but be prepared for a doc-only change.

[jhliptak]

The blog at http://sykesm.mybluemix.net/posts/jmx-in-diego/ seems to document the issue in detail.

John Liptak
Principal Architect
Infrastructure Architecture & Strategy
931 14th St
Denver, CO 80202
John.Liptak@CenturyLink.commailto:John.Liptak@CenturyLink.com
(303) 992-9623 (work)
(303) 437-4206 (cell)

All problems in computer science can be solved by another level of indirection" – Butler Lampson

From: Ben Hale [mailto:notifications@github.com]
Sent: Monday, December 07, 2015 10:32 AM
To: cloudfoundry/java-buildpack
Subject: Re: [java-buildpack] JMX Docs Issue (#266)

While the problem is undoubtedly real, I'm not sure why it is. The JSR-160 and RMI ports always match one anotherhttps://github.com/cloudfoundry/java-buildpack/blob/master/lib/java_buildpack/framework/jmx.rb#L42-L43, so the tunnel for one should match the tunnel for the other. I'm guessing something is doing an internal redirect causing the issue.

Outside of an easy fix, I think we'll update the docs to be more clear rather than making the implementation more robust. Instance choice should be handled via the cf ssh -i argument, and I don't want to add anything additional if you can't use non-matching ports. In the end, this is not something that should be used very often so putting a ton of engineering into it isn't in line with our goals.

I'll do some research about tunneling JSR-160/RMI over SSH, but be prepared for a doc-only change.

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

This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.

[nebhale]

@jhliptak That's actually an issue that we've already solved. We can make the connection just fine so long as port numbers all match. It breaks down when the port numbers don't match. So

$ cf ssh -N -T -L 5000:localhost:5000 <APP>

works, while

$ cf ssh -N -T -L 6000:localhost:5000 <APP>

does not.

[dmikusa]

Docs only change is fine with me.