JConsole ਰਜਿਸਟਰੀ ਨਾਲ ਜੁੜਦਾ ਹੈ, ਫਿਰ RMI ਇਸਨੂੰ ਕਿਤੇ ਹੋਰ ਭੇਜਦਾ ਹੈ

ਟਨਲ ਰਾਹੀਂ ਰਜਿਸਟਰੀ ਪੋਰਟ ਨਾਲ ਜੁੜੋ, ਹੈਂਡਸ਼ੇਕ ਸ਼ੁਰੂ ਹੁੰਦਾ ਵੇਖੋ ਅਤੇ ਫਿਰ ਵੇਖੋ ਕਿ JConsole ਫਿਰ ਵੀ ਸਮਾਂ ਖਤਮ ਹੋਣ ਨਾਲ ਰੁਕ ਜਾਂਦਾ ਹੈ। ਇਹ ਇਸ ਲਈ ਹੁੰਦਾ ਹੈ ਕਿਉਂਕਿ ਪਹਿਲਾ TCP ਕਨੈਕਸ਼ਨ ਮੈਨੇਜਮੈਂਟ ਕਨੈਕਸ਼ਨ ਨਹੀਂ ਹੈ: ਇਹ ਇੱਕ ਖੋਜ ਹੈ। RMI ਰਜਿਸਟਰੀ ਇੱਕ ਹਵਾਲੇ ਨਾਲ ਜਵਾਬ ਦਿੰਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਇੱਕ ਹੋਸਟ ਅਤੇ ਦੂਜਾ ਪੋਰਟ ਹੁੰਦਾ ਹੈ, ਅਤੇ JConsole ਫਿਰ ਉੱਥੇ ਜਾਂਦਾ ਹੈ ਜਿੱਥੇ ਇਸਨੂੰ ਭੇਜਿਆ ਗਿਆ ਸੀ। ਜੇ ਟਨਲ ਸਿਰਫ਼ ਸਰਵਰ ਦੇ ਪਹਿਲੇ ਪੋਰਟ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਜਾਂ ਹਵਾਲਾ ਅਜਿਹਾ ਪਤਾ ਦੱਸਦਾ ਹੈ ਜੋ ਸਿਰਫ਼ ਸਰਵਰ ਦੇ ਆਪਣੇ ਲੋਕਲ ਨੈੱਟਵਰਕ ਵਿੱਚ ਹੀ ਮੌਜੂਦ ਹੈ, ਤਾਂ ਕਲਾਇੰਟ ਦਿਖਾਈ ਸਫਲਤਾ ਤੋਂ ਬਾਅਦ ਅਟਕ ਜਾਂਦਾ ਹੈ।

ਮਿੱਥ: ਇੱਕ ਖੁੱਲ੍ਹਾ ਪੋਰਟ ਇੱਕ ਕਨੈਕਸ਼ਨ ਹੈ

RMI ਰਾਹੀਂ ਰਿਮੋਟ JMX ਵਿੱਚ ਘੱਟੋ-ਘੱਟ ਦੋ ਐਂਡਪੁਆਇੰਟ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਸਿਸਟਮ ਦੇ ਵੱਖ-ਵੱਖ ਹਿੱਸੇ ਚੁਣਦੇ ਹਨ। ਰਜਿਸਟਰੀ ਪੋਰਟ ਉਹ ਹੈ ਜੋ ਤੁਸੀਂ ਕਲਾਇੰਟ ਵਿੱਚ ਲਿਖਦੇ ਹੋ, ਅਤੇ ਇਹ ਅਸਲ ਕਨੈਕਟਰ ਦਾ ਵੇਰਵਾ ਦੇਣ ਵਾਲਾ stub ਦੇਣ ਲਈ ਮੌਜੂਦ ਹੈ। ਪਹਿਲੇ ਸਫਲ ਸਾਕਟ ਨੂੰ ਇਸ ਗੱਲ ਦਾ ਸਬੂਤ ਮੰਨਣਾ ਕਿ ਮੈਨੇਜਮੈਂਟ ਦਾ ਰਾਹ ਖੁੱਲ੍ਹਾ ਹੈ, ਦੋ ਮਿੰਟ ਦੇ ਨਿਦਾਨ ਨੂੰ ਫਾਇਰਵਾਲ ਟਿਕਟਾਂ ਨਾਲ ਭਰੀ ਦੁਪਹਿਰ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।

ਸਰਵਰ ਦੀ ਸੁਣਨ ਵਾਲਿਆਂ ਦੀ ਸੂਚੀ ਦੀ ਥਾਂ ਕਲਾਇੰਟ ਦੀ ਆਪਣੀ ਗਲਤੀ ਵੇਖੋ। ਹੈਂਡਸ਼ੇਕ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਬਾਅਦ ਦੀ ਅਸਫਲਤਾ ਦੱਸਦੀ ਹੈ ਕਿ ਦੂਜਾ ਕਨੈਕਸ਼ਨ ਪੂਰਾ ਨਹੀਂ ਹੋਇਆ, ਪਹਿਲਾ ਨਹੀਂ।

ਰਜਿਸਟਰੀ ਕੀ ਵਾਪਸ ਕਰਦੀ ਹੈ

stub ਵਿੱਚ ਇੱਕ ਪਤਾ ਅਤੇ ਪੋਰਟ ਹੁੰਦਾ ਹੈ, ਜੋ ਕਨੈਕਟਰ ਬਣਨ ਵੇਲੇ ਕ੍ਰਮਬੱਧ ਕੀਤੇ ਗਏ ਸਨ। ਕਈ ਇੰਟਰਫੇਸ ਵਾਲੇ ਸਰਵਰ ਉੱਤੇ ਸਟੈਕ ਨੇ ਅਜਿਹਾ ਪਤਾ ਚੁਣਿਆ ਹੋ ਸਕਦਾ ਹੈ ਜੋ ਲੋਕਲ ਨੈੱਟਵਰਕ ਤੋਂ ਪਹੁੰਚਯੋਗ ਹੈ ਪਰ ਤੁਹਾਡੇ ਤੋਂ ਨਹੀਂ। ਕਲਾਇੰਟ ਨੂੰ ਫ਼ਰਕ ਨਹੀਂ ਪਤਾ; ਇਹ ਬੱਸ ਮਿਲੀ ਕੀਮਤ ਡਾਇਲ ਕਰਦਾ ਹੈ, ਅਤੇ ਪੈਕੇਟ ਉਸ ਪਤੇ ਲਈ ਮੌਜੂਦ ਰਸਤੇ ਉੱਤੇ ਚੱਲਦਾ ਹੈ, ਜੋ VPN ਕਲਾਇੰਟ ਉੱਤੇ ਅਕਸਰ ਕੋਈ ਨਹੀਂ ਹੁੰਦਾ। ਦੂਜਾ ਕਨੈਕਸ਼ਨ ਉਸੇ ਪਲ ਅਜ਼ਮਾਇਆ ਜਾਂਦਾ ਹੈ।

ਇਹੀ ਕਾਰਨ ਹੈ ਕਿ ਅਸਫਲਤਾ ਵੱਖ-ਵੱਖ ਵਾਤਾਵਰਨਾਂ ਵਿੱਚ ਰੁਕ-ਰੁਕ ਕੇ ਹੁੰਦੀ ਹੈ: ਉਹੀ ਸਰਵਰ JMX ਸੰਰਚਨਾ ਵਿੱਚ ਬਿਨਾਂ ਕੋਈ ਬਦਲਾਅ ਕੀਤੇ ਲੋਕਲ ਨੈੱਟਵਰਕ ਦੇ ਵਰਤੋਂਕਾਰ ਅਤੇ ਟਨਲ ਦੇ ਵਰਤੋਂਕਾਰ ਲਈ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰ ਸਕਦਾ ਹੈ।

ਦੋ ਪੋਰਟ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਨਿਸ਼ਚਿਤ ਕਰਨ ਵਾਲੀਆਂ ਦੋ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ

ਰਜਿਸਟਰੀ ਪੋਰਟ com.sun.management.jmxremote.port ਤੋਂ ਆਉਂਦਾ ਹੈ, ਅਤੇ ਕਨੈਕਟਰ ਨੂੰ ਸਟੈਕ ਦੇ ਦਿੱਤੇ ਉੱਤੇ ਛੱਡਣ ਦੀ ਥਾਂ com.sun.management.jmxremote.rmi.port ਨਾਲ ਨਿਸ਼ਚਿਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਜਦੋਂ ਕਲਾਇੰਟ ਅਤੇ ਸਰਵਰ ਵਿਚਕਾਰ ਫਾਇਰਵਾਲ ਜਾਂ ਸੁਰੱਖਿਆ ਸਮੂਹ ਹੋਵੇ ਤਾਂ ਦੋਵੇਂ ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਸੈੱਟ ਕਰੋ, ਕਿਉਂਕਿ ਅਣਅਨੁਮਾਨਿਤ ਦੂਜੇ ਪੋਰਟ ਨੂੰ ਪਹਿਲਾਂ ਤੋਂ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦਿੱਤੀ ਜਾ ਸਕਦੀ, ਅਤੇ ਉਸਨੂੰ ਸਮੇਟਣ ਲਈ ਖੋਲ੍ਹੀ ਚੌੜੀ ਰੇਂਜ ਇੱਕ ਮੁੱਲ ਨਿਸ਼ਚਿਤ ਕਰਨ ਨਾਲੋਂ ਬਦਤਰ ਹੈ।

ਫਿਰ ਸਰਵਰ ਉੱਤੇ ss -ltn ਜਾਂ netstat -an ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਦੋਵੇਂ ਪੋਰਟ ਸੁਣ ਰਹੇ ਹਨ ਅਤੇ ਕਿਹੜੇ ਪਤਿਆਂ ਉੱਤੇ। loopback ਨਾਲ ਬੱਝਾ ਸੁਣਨ ਵਾਲਾ ਸਿਰਫ਼ ਲੋਕਲ ਡਿਪਲਾਇਮੈਂਟ ਲਈ ਸਹੀ ਹੈ ਅਤੇ ਇਸ ਲਈ ਬੇਕਾਰ ਹੈ।

ਜਦੋਂ ਘੋਸ਼ਿਤ ਨਾਮ ਗਲਤ ਹੋਵੇ

ਰਿਮੋਟ ਹਵਾਲੇ ਵਿੱਚ ਦਿਖਣ ਵਾਲਾ ਹੋਸਟ ਨਾਮ java.rmi.server.hostname ਤੈਅ ਕਰਦਾ ਹੈ। ਇਹ ਇਸ ਗੱਲ ਉੱਤੇ ਅਸਰ ਪਾਉਂਦਾ ਹੈ ਕਿ stub ਕੀ ਘੋਸ਼ਿਤ ਕਰਦਾ ਹੈ; ਆਪਣੇ ਆਪ ਵਿੱਚ ਇਹ ਹਰ ਸੁਣਨ ਵਾਲੇ ਨੂੰ ਇੱਕ ਇੰਟਰਫੇਸ ਨਾਲ ਬੰਨ੍ਹਣ ਦਾ ਨਿਰਦੇਸ਼ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਸੈੱਟ ਕਰਨਾ ਹਮੇਸ਼ਾ ਉਮੀਦ ਕੀਤਾ ਇੱਕ-ਪੋਰਟ ਵਿਵਹਾਰ ਨਹੀਂ ਦਿੰਦਾ। ਇਸਨੂੰ ਸੈੱਟ ਕਰੋ, ਪ੍ਰੋਸੈਸ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਫਿਰ ਜਾਂਚੋ ਕਿ stub ਵਿੱਚ ਅਸਲ ਵਿੱਚ ਕੀ ਹੈ। ਅਜਿਹਾ ਨਾਮ ਜਾਂ ਪਤਾ ਚੁਣੋ ਜੋ ਕਲਾਇੰਟ ਹੱਲ ਕਰ ਸਕੇ ਅਤੇ ਟਨਲ ਰਾਹੀਂ ਪਹੁੰਚ ਸਕੇ, ਅਤੇ stub ਦੁਬਾਰਾ ਬਣਨ ਲਈ ਪ੍ਰੋਸੈਸ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰੋ।

ਕੰਟੇਨਰ ਨੈੱਟਵਰਕ ਇਸਨੂੰ ਹੋਰ ਵਿਗਾੜਦੇ ਹਨ, ਕਿਉਂਕਿ ਪ੍ਰੋਸੈਸ ਨੂੰ ਦਿਖਣ ਵਾਲਾ ਪਤਾ ਅੰਦਰੂਨੀ ਹੋ ਸਕਦਾ ਹੈ ਜਿਸਨੂੰ ਕੰਟੇਨਰ ਤੋਂ ਬਾਹਰ ਕੋਈ ਰੂਟ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਪਲੇਟਫਾਰਮ ਨੂੰ ਚੁਣਨ ਦੇਣ ਦੀ ਥਾਂ ਲੋੜੀਂਦਾ ਹੋਸਟ ਨਾਮ ਸਪਸ਼ਟ ਰੂਪ ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ।

ਜੇ ਤੁਸੀਂ VPN ਦੀ ਥਾਂ SSH ਨਾਲ ਟਨਲ ਕਰ ਰਹੇ ਹੋ ਤਾਂ ਉਹੀ ਸਮੱਸਿਆ ਦੂਜੇ ਰੂਪ ਵਿੱਚ ਦਿਖਦੀ ਹੈ: ਸਿਰਫ਼ ਰਜਿਸਟਰੀ ਪੋਰਟ ਅੱਗੇ ਭੇਜਣ ਨਾਲ ਦੂਜਾ ਐਂਡਪੁਆਇੰਟ ਅਜਿਹੇ ਪਤੇ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਰਹਿ ਜਾਂਦਾ ਹੈ ਜਿੱਥੇ ਤੁਹਾਡਾ ਕਲਾਇੰਟ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ। ਦੋਵੇਂ ਪੋਰਟ ਅੱਗੇ ਭੇਜੋ ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਘੋਸ਼ਿਤ ਨਾਮ ਅਜਿਹੀ ਚੀਜ਼ ਵਿੱਚ ਹੱਲ ਹੋਵੇ ਜਿੱਥੇ ਕਲਾਇੰਟ ਲੋਕਲ ਤੌਰ ਉੱਤੇ ਪਹੁੰਚ ਸਕੇ।

ਸੌਖਾ ਕਰਨ ਲਈ ਮੈਨੇਜਮੈਂਟ ਸੁਰੱਖਿਆ ਬੰਦ ਨਾ ਕਰੋ

ਪ੍ਰਮਾਣੀਕਰਨ ਅਤੇ TLS ਬੰਦ ਕਰਨ ਵਾਲੇ ਸਨਿੱਪਟ ਸੌਖਿਆਂ ਮਿਲ ਜਾਂਦੇ ਹਨ ਅਤੇ ਕਨੈਕਸ਼ਨ ਨੂੰ ਇਸ ਤਰੀਕੇ ਨਾਲ ਚਲਾਉਂਦੇ ਹਨ ਜਿਸਨੂੰ ਬਾਅਦ ਵਿੱਚ ਵਾਪਸ ਕਰਨਾ ਪਵੇਗਾ। ਰਿਮੋਟ JMX ਇੱਕ ਮੈਨੇਜਮੈਂਟ ਇੰਟਰਫੇਸ ਹੈ ਜਿਸਦੇ ਉਹੀ ਅਧਿਕਾਰ ਹਨ ਜੋ ਉਸ ਪ੍ਰੋਸੈਸ ਦੇ ਹਨ ਜਿਸਦੀ ਇਹ ਜਾਂਚ ਕਰਦਾ ਹੈ; ਇਸਦੇ ਪਹੁੰਚ ਨਿਯੰਤਰਣ ਰੱਖੋ, ਅਤੇ ਜੇ ਕਲਾਇੰਟ ਪ੍ਰਮਾਣ ਪੇਸ਼ ਨਹੀਂ ਕਰ ਸਕਦਾ ਤਾਂ ਉਹੀ ਠੀਕ ਕਰੋ।

ਐਂਡਪੁਆਇੰਟ ਸਹੀ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਅਗਲੀ ਜੋ ਗਲਤੀ ਦਿਖੇ ਉਸਨੂੰ ਸੰਭਾਲ ਕੇ ਰੱਖੋ। ਟਰਸਟ ਸਟੋਰ ਜਾਂ ਖਾਤੇ ਵੱਲੋਂ ਇਨਕਾਰ ਨਾ ਪਹੁੰਚਣ ਵਾਲੇ ਕਨੈਕਟਰ ਤੋਂ ਬਾਅਦ ਦਾ ਪੜਾਅ ਹੈ ਅਤੇ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਨੈੱਟਵਰਕ ਦਾ ਕੰਮ ਪੂਰਾ ਹੋ ਗਿਆ।