הפעלת פקודה כשתהליך נופל בPM2

[nigun]

אני מפעיל שרת TCP שמדבר עם אסטריסק עם PM2
לפעמים השרת נופל בגלל קריאות לNULL וכדומה
ואז PM2 מפעיל אותו מחדש.

הבעיה היא שאסטריסק לא מעודכן שהשרת TCP נפל ומנסה להמשיך לתקשר
ואז גם אסטריסק נופל.

אמנם אני צריך לבנות שרת שלא יפול אף פעם (אבל זה כבר נושא אחר)
אבל אני צריך בכל מקרה גם אופציה לאתחל את אסטריסק במקרה שהשרת TCP נפל.

האם יש אופציה להפעיל פקודה של לינוקס
לפני הפעלה מחדש של תהליך PM2?
(אני מעדיף שזה לא יעשה מתוך השרת TCP)

@dovid
אם אני לא כותב ברור וכו'?
אל תהסס ותן בראש
אני רוצה להשתפר.
(ולכל שאר החברים אל תהססו לשאול שאלות בעתיד
אתם לא תקבלו כאלו התקפות)

[מנצפך]

לפי איך שהבנתי, הפתרון מאוד פשוט. השרת עצמו יפעיל את הפקודה בעת העלייה שלו. לא צריך שה PM2 יעשה את זה

[aaron]

למה שלא תשתמש בnginx כreverse proxy אל יותר מאינסטנס 1 של שרת אחורי שמופעל עם PM2?
ככה גם אם אחד ייפול השני יהיה זמין.

[nigun]

@aaron
זה לא בעיה שלי
אני רוצה להפעיל מחדש שירות אחר במקרה של נפילה
כנראה הדרך הכי פשוטה זה להוסיף פקודה, בעת עליית השרת.
(רק רציתי לראות אולי יש משהו מובנה בPM2 אבל אם אין, אז לא נורא)

אתה מדבר על זמינות של השרת TCP, שזה נושא אחר
פרוקסי לא יעזור לי כי אסטריסק ימשיך לחשוב שהוא מחובר לשרת TCP, מתי שאין מין שמאזין לו באמת
אז מה יעזור לי פרוקסי?

[dovid]

@nigun פרוקסי זה דרך מקובלת להאזין בשתי פורטים (עם שני מופעים של תוכנה בלתי תלויים, כמו הGO שלך שירוץ פעמיים) דרך פורט אחד, וככה יש שרידות.
העובדה שאסטריסק נופל מייד כשהGO נופל אולי גם יכולה להיפתר ע"י טייימהאוט גדול בפרוקסי, אני לא בטוח.
בכל מקרה הפתרון הזה לא כ"כ קל, נדמה לי שNGINX לא תומך בפרוקסי לTCP אלא רק בגירסה המסחרית שלו.
זה גם מחייב לבנות את האפליקציה שתתמוך בשיתוף המידע הזה עם המופעים האחרים שלה וזה החלק הכי קשה במיחד במקרה שלך.

[nigun]

@dovid אמר בהפעלת פקודה כשתהליך נופל בPM2:

@nigun
העובדה שאסטריסק נופל מייד כשהGO נופל אולי גם יכולה להיפתר ע"י טייימהאוט גדול בפרוקסי, אני לא בטוח.

לא הבנתי כ"כ, אתה מתכוון שהפרוקסי יםיל את השיחה ברגע שהוא מחליף שרת?

בכל מקרה הפתרון הזה לא כ"כ קל, נדמה לי שNGINX לא תומך בפרוקסי לTCP אלא רק בגירסה המסחרית שלו.

ייש עוד הרבה שרתי פרוקסי חוץ מNGINX. אני דווקא אוהב יותר שרתים שמקמפלים אותם מהמקור
ולא משהו מוכן, ככה יש לי הזדמנות ללמוד עוד משהו (וגם יותר קל להבנה בחלק מהמקרים)

זה גם מחייב לבנות את האפליקציה שתתמוך בשיתוף המידע הזה עם המופעים האחרים שלה וזה החלק הכי קשה במיחד במקרה שלך.

אכן זה הבעיה שלי
עכשיו אני חושב שאולי כדאי לשים את כל המידע המשותף על שרת נוסף, ולסנכן בין השרתים עם TCP,HTTP או משהו כזה
השרת הזה אמור להיות יציב, ובלי שינויים בקוד, ואני ניגש אליו מבחוץ כמו מסד נתונים.
זה כנראה לא יפתור לי את הבעיה של המידע של מופעים ספיציפים
אבל לפחות לא יהרוס את המידע המשותף בין המופעים.
אמנם אני לא יודע כמה זה יעיל מבחינת ביצועים
מה אתה אומר?

[aaron]

@dovid אמר בהפעלת פקודה כשתהליך נופל בPM2:

זה גם מחייב לבנות את האפליקציה שתתמוך בשיתוף המידע הזה עם המופעים האחרים שלה וזה החלק הכי קשה במיחד במקרה שלך.

יש מושג של sticky session, מה שאומר שמידע של runtime אתה לא צריך לשתף, ומידע אחר בכל מקרה צריך להיות זמין על db.. כי זה אותו סוג מידע שאתה צריך שיהיה קיים גם כשאתה מרסט את השרת TCP שלך..

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

לדעתי זה צריך להיות משהו כמו websocket שנפתח עבור כל שיחה, או יותר טוב ממשק API אמיתי שמיועד לעבוד בrealtime, כמו graphql אולי

[nigun]

@aaron אמר בהפעלת פקודה כשתהליך נופל בPM2:

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

דברים מוזרים באסטריסק זה לא מחזה נדיר
הרבה מתלוננים על מערכת לא יציבה
ויש שם הרבה תקלות מוזרות.

לדעתי זה צריך להיות משהו כמו websocket שנפתח עבור כל שיחה, או יותר טוב ממשק API אמיתי שמיועד לעבוד בrealtime, כמו graphql אולי

יש להם בגירסאות האחרונות API חיצוני שמנהל את השיחה עם WS + REST API
אבל ניהול השיחה שם הוא מורכב
צריך להזין לכל האירועים בWS, ולבצע את הפקודות דרך הAPI הרגיל (HTTP)
זה אומנם נותן הרבה יכולות, אבל נראה לי שזה מסבך את הקוד
בימים אלו אני מנסה לבנות בזה אפליקציה קטנה
אולי זה יפתור גם את שאר הבעיות הנ"ל (לא בטוח)
יש עוד מתחרה לאסטריסק בשם freeswitch
שהוא נחשב יותר יציב אבל הרבה פחות נפוץ, אז כולם ממשיכים ללכת על אסטריסק ולהשתגע מההתנהגות שלו.

[aaron]

@nigun
קצת גיגלתי על זה עכשיו, אתה מדבר על signalwire?
מה המשמעות שלו? חייבים להשתמש בשירות החיצוני בתשלום שלהם בשביל זה?

דווקא בעבר עברתי קצת על התיעוד של freeswitch והוא נראה הרבה יותר מוצלח מבחינת תכנון וביצוע. מצאתי גם כמה ספריות שיודעות ממש לבנות flow של שיחה. נשמע מעולה..

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

[nigun]

@aaron
signalwire זה שירות שדוחפים משום מה, כשמתקינים את freeswitch
אבל לא נראה לי שחייבים את זה.
freeswitch זכאי לתת פורום בפני עצמו ,אחרי שהציבור כאן יגלה את freeswitch בעז"ה
נוכל לסגור את פרום אסטריסק מחוסר עניין לציבור
(לא יודע למה אני מפתח לו שנאה, אני פשוט מתוסכל מהבאגים המוזרים של אסטריסק)
לבנתיים תבקש מ @clickone שיוסיף אותך לאסטריסק.

[aaron]

@clickone בקשתי שטוחה לפניך..
אם כי יש מצב שאני לא זכאי לחברות משום שאני לא מתעסק במערכות IVR עצמאיות ככלל..

[nigun]

@aaron אמר בהפעלת פקודה כשתהליך נופל בPM2:

אם כי יש מצב שאני לא זכאי לחברות משום שאני לא מתעסק במערכות IVR עצמאיות ככלל..

אז אתה קורא תיעוד על FS (קיצור של freeswitch) לכיף?

[aaron]

@nigun אמר בהפעלת פקודה כשתהליך נופל בPM2:

@aaron אמר בהפעלת פקודה כשתהליך נופל בPM2:

אם כי יש מצב שאני לא זכאי לחברות משום שאני לא מתעסק במערכות IVR עצמאיות ככלל..

אז אתה קורא תיעוד על FS (קיצור של freeswitch) לכיף?

זה היה מזמן כששקלתי לבנות עצמאית, בסופו של דבר ימות הספיק.
אם כי עכשיו יש לי עוד הצעה לפרויקט שFS יכול להיות מועיל.