JedisSocketFactory.createSocket חייב להחזיר סוקט מחובר ומוכן לשאת תעבורת Redis. ב-Jedis 5.2.0 האפליקציה מספקת את המחלקה ואת תצורת לקוח ה-Redis שלה כאן:

var jedis = new Jedis(socksSocketFactory, redisConfig);

socksSocketFactory מיישם את redis.clients.jedis.JedisSocketFactory, ו-redisConfig הוא ה-JedisClientConfig של האפליקציה. היו מוכנים להתחבר כשהבנאי רץ: הוא עשוי לבצע אימות והגדרות Redis אחרות מיד.

עקבו אחר סוקט אחד מרגע היצירה ועד המסירה

למסלול SOCKS5 ללא אימות, המחלקה יכולה ליצור java.net.Socket עם מתווך Proxy.Type.SOCKS מפורש, ואז להתחבר למארח ולפורט של Redis. השאירו את היעד לא פתור אם שרת ה-SOCKS אמור לפתור את שם המארח.

הגבילו את ניסיון החיבור והחילו את זמן הקריאה המיועד. אם החיבור נכשל, סגרו את הסוקט הזה ודווחו על JedisConnectionException; ממשק המחלקה אינו מצהיר על IOException נבדקת.

אם Redis דורש TLS, הקימו ואמתו TLS לפני החזרת הסוקט. אין להניח שדגל נפרד ימיר סוקט שרירותי שהמחלקה מחזירה. עבור מאגר, חזרו על מחזור החיים הזה עם סוקט חדש בכל קריאה למחלקה, כולל חיבורי החלפה.

בחירת HTTP ב-ProxySelector גלובלי אינה יישום חלופי של העבודה הזו. Redis שולח RESP דרך הסוקט שלו; בכך הוא אינו הופך ל-HTTP ואינו מנהל משא ומתן על CONNECT.

מאמרים קשורים