הפעם שוחחו ליאור ורן על אחת מהחוויות שכל מפתח עובר בחייו - באגים. אבל לא סתם באגים - באגים קשים, מתסכלים, כאלה שעובדים עליהם ימים, שבועות או יותר...
במקרה ספציפי זה רן נתקל בבאג שעליו הוא כבר עובד מספר שבועות (בהפסקות, אבל זמן ממושך) וביחד רן וליאוד ניסו לנתח דרכי פעולה אפשריות ולהעלות השערות לגבי היתכנות פתרונו.
הבאג הוא ככל הנראה ״לא בקוד שלנו״ או לפחות כך אנו מקווים, מפאת הפאדיחה, וככל הנראה הוא בקוד של צד שלישי, אבל לא ברור איזה כי יש איזה שלושה צדדים שלישיים שמעורבים בעניין. בקיצור, באג מאתגר...
להלן כמה לינקים, בין השאר לדיווח על הבאג ומידע כללי לצורך ההקשר.
- Related presentation https://speakerdeck.com/rantav/dropwizard
- Related meetup group http://www.meetup.com/JavaIL/events/209047222/
- The bug report https://java.net/jira/browse/JERSEY-2683
- And a related bug report https://java.net/jira/browse/JERSEY-2684
- Lior: http://bootsnipp.com/
- Anti-pick by Lior: http://ionicframework.com/
הקובץ נמצא כאן, האזנה נעימה
Hi Ran,
השבמחקIt sounds to me like the bug is in the set-cookie header, when you try to write too big cookie you might get this exception.
Since many times cookies are incremental (you add data to existing data) the cause can
be specific users that have big cookies.
If you have server stickiness that can explain why it happens on one server only.
good luck
-Dan
Hi Dan thanks for the idea. Cookies are a good direction to check although I should note that I'm not setting any cookies at all. But perhaps something configures the server to echo the values of the cookies received and maybe sometimes even modify them. I'll check.
מחקBTW I checked further on and it seems to be not related to one specific request, it's more about load or perhaps many concurrent requests (not necessarily under load) that any one specific request.
שלום רן,
השבמחקהזכרת בפודקסט כלי (השם בהקלטה לא ברור) שנכתב בGo שמקליט/משכפל תנועת HTTP על ידי האזנה, אתה יכול לצרף URL אולי?
אני צריך אותו כדי לדבג בעיות שיש לי ב (הפתעה, הפתעה) Dropwizard... כל מיני שגיאות בלוג ועניינים אחרים שאני לא רואה את הבקשות עצמן בלוג (שגיאה שאמורה להחזיר 413 ואין כאלה בלוג), הפיצול המוחלט בין הלוגים (בקשות/AccessLog ואפליקציה) והעובדה שאין ממש דרך לקשר בין שגיאה פה לבקשה שם מטריפה אותי. יותר מזה, יש בהחלט מצב שחלק מהבקשות (באג אחר) בכלל לא נכתבות ללוג כי העיבוד שלהן לא מסתיים.
תודה
There you go Moshe
מחקhttps://github.com/buger/gor
תודה רבה! אין לך מושג כמה זמן אני מחפש בדיוק את הדבר הזה...
השבמחקThanks everyone for your help, I found the issue (my bug, surprise surprise) and fixed it.
השבמחקWell...
מחקPlease tell us what was the bug :-)
Hi Avi, the bug was incorrect reuse or a response object in legacy code which surprisingly worked well in the previous implementation but did not work well in the new implementation.
מחקThe fix is to create a new response object with each response, never reuse those
שלום רן,
השבמחקסיפרת על כך שלפעמים המערכת מגיעה לרצף של שגיאות NullPointerException אבל לא מודפס stack trace.
הסיבה לכך נעוצה באופטימיזציה שנעשית ע"י ה-JVM כששגיאה נזרקת הרבה פעמים. השגיאה מודפסת במלואה בפעמים הראשונות ואז ה-JVM מחליט לחסוך את איסוף המידע ואת וההדפסה ומדפיס רק את העובדה שקרתה שגיאה.
דרך אחת להתגבר על כך היא למצוא את אותן השגיאות הראשונות שהודפסו במלואן לפני שהאופטימיזציה נכנסה ולחקור אותן.
אפשרות אחרת היא לומר ל-JVM לא לבצע את האופטימיזציה כלל ע"י הרצת ה-JVM עם הדגל
XX:-OmitStackTraceInFastThrow-
בהצלחה
אה תודה משה, לא ידעתי את זה, מאוד שימושי!
מחק