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 એ મેનેજમેન્ટ ઇન્ટરફેસ છે જેની તે નિરીક્ષણ કરે તે પ્રોસેસ જેટલી જ સત્તા છે; તેના એક્સેસ કંટ્રોલ રાખો, અને ક્લાયન્ટ ક્રેડેન્શિયલ રજૂ કરી શકતું ન હોય તો તેને ઠીક કરો.

એન્ડપોઇન્ટ સાચા થયા પછી, હવે પછી જે ભૂલ દેખાય તે સાચવી રાખો. ટ્રસ્ટ સ્ટોર અથવા એકાઉન્ટ તરફથી અસ્વીકાર ન પહોંચી શકતા કનેક્ટર પછીનો તબક્કો છે અને તેનો અર્થ નેટવર્કનું કામ પૂરું થયું છે.