저희는 rss-polling 플러그인을 사용하여 수십 개의 피드에서 항목을 가져오고 있습니다. 가끔씩 일부 피드가 목록에서 갑자기 사라지는 경우가 있습니다. 어떤 조건에서, 어떻게 발생하는지 알 수 없으며, 해당 동작에 대한 로그도 찾을 수 없습니다. 패턴 역시 발견하지 못했습니다. 피드가 단순히 사라지고, 이를 인지했을 때 다시 새 항목을 생성해야 합니다(피드가 너무 많아 사라졌다는 사실을 알아차리는 것조차 쉽지 않습니다).
특정 조건에서 RSS 피드를 제거하는 기능이 코드에 구현되어 있나요? 이러한 일이 발생했을 때를 기록하는 로그가 있나요?
RSS 피드에 대해 우리가 하는 일은 /admin/plugins/rss_polling 페이지에서 수동으로 새 피드를 생성하는 것뿐입니다. 그 외에는 아무것도 하지 않습니다.
해당 페이지에서 RSS 피드의 순서가 가끔씩 바뀐다는 점을 발견했습니다. 이는 이미 이상한 일이며, 피드 생성의 시간 순서가 사라져 문제 디버깅에도 도움이 되지 않습니다. 게다가 새로운 정렬 방식은 어떤 알파벳 순서나 숫자 순서를 따르는 것 같지도 않습니다.
이 문제가 얼마나 자주 발생하는지는 즉시 감지할 수 없어 알 수 없습니다. 최선의 경우, 피드 소유자가 새 항목이 표시되지 않는다고 알려줄 때까지 기다리거나, 예를 들어 매주 올라오는 팟캐스트가 최근 포럼에서 침묵하고 있다는 것을 우리가 스스로 알아차릴 때까지 기다릴 수밖에 없습니다.
이 문제가 CPU 사용률이 100%에 가까워지거나 서버의 다른 부분이 최대 용량에 도달하는 상황과 관련이 있을 것 같은 인상을 받고 있습니다. 스케줄러가 한 번에 5개 피드만 폴링하도록 잘 작동하더라도, 호스팅 분석 도구에서 RSS 피드가 업데이트될 때 CPU 사용률이 기본적으로 100%에 도달하는 것을 확인할 수 있습니다.
아마도 이것이 피드가 몇 개뿐인 포럼에서는 이 문제를 느끼지 못하는 이유일 수 있습니다. 하지만 피드를 많이 추가하면 스케줄러와 관계없이 가끔씩 무언가가 깨질 수 있습니다.
어쨌든, Discourse가 RSS 피드를 왜 삭제해야 하는지, 그리고 그걸 조용히 처리하는지 궁금합니다. 만약 어떤 이유로 RSS 피드에 문제가 있다면, 이번 한 번은 건너뛰고 문제를 로그로 기록하는 것이 나을 것입니다. 이 시점부터 두 가지 일이 발생할 수 있습니다:
일시적인 문제였을 경우, 다음 스케줄러 실행에서는 정상적으로 작동할 것입니다. 로그 항목은 잊혀질 것입니다.
문제가 지속될 경우, 모든 건너뛰기마다 에러 로그에 항목이 남게 되며, 누군가 문제가 있음을 인지했을 때 관리자가 에러 로그를 확인하여 세부 사항을 찾을 수 있습니다.
이상적으로는 관리자에게 어떤 형태의 알림이 보내져야 하지만, 이것이 잠재적인 해결책에 더 많은 작업을 추가하는 것을 이해합니다. 삭제 대신 건너뛰기 + 에러 로그 항목 기록은 이미 큰 개선이 될 것입니다.
그리고 이 문제가 우리 프로젝트에 미치는 영향을 설명하기 위해. 우리는 독립적인 팟캐스트들의 포털을 운영하고 있으며, 그들은 저희에게 집계(aggregation)를 요청합니다. 우리는 그들의 프로그램이 가져와지고 청취자들이 좋아요를 누르고 댓글을 달 수 있는 채널(하위 카테고리)을 생성합니다… 그들이 저희가 더 이상 그들의 콘텐츠를 집계하지 않는다는 사실을 알게 될 때, 그리고 우리는 어쩔 수 없이 그들의 피드가 삭제되었다고 답변해야 할 때, 이는 우리 프로젝트와 Discourse 플랫폼에 매우 나쁜 인상을 남깁니다…
패치를 올려주셔서 감사합니다! 바로 새 버전으로 업그레이드하고 누락된 RSS 피드(약 20개!)를 추가했는데, 오늘 확인해 보니… 피드가 다시 조용히 사라져 있었습니다. 언제, 어떻게, 그리고 정확히 어떤 피드들이 사라졌는지는 여전히 모르지만, 약 10개 정도가 빠져 있습니다. 피드를 삭제하기 전에 관련 대화를 묻는 창이나 그 밖의 어떤 알림도 본 적이 없습니다. 또한, 서버 CPU 부하가 적을 때 RSS 피드를 다시 추가하고, RSS 폴링 시간대를 피해서 작업을 진행하여 해당 요인을 변수에서 제외해 보기도 했습니다.
피드 목록의 정렬이 바뀌는 것과 피드가 사라지는 현상 사이에 어떤 연관성이 있는 것 같다는 인상을 받고 있습니다. 정렬 방식을 변경하는 원인이 충격이 될 만큼 크다면, 그 과정에서 피해(피드 소실)가 발생하는 것도 당연한 일일 수 있습니다. 유용한 질문은 다음과 같습니다: 왜 목록의 정렬 방식이 애초에 바뀌는 것일까요? 정렬 방식은 그대로 유지된 채로 피드가 사라진다면 그 또한 나쁜 일이겠지만, 그래도… 훨씬 깔끔하게 느껴질 것 같습니다.
이 문제는 우리 측에서 수정하기가 번거롭습니다(소유자가 알아채고 문의하기 전에 어떤 피드가 누락되었는지 파악하고 + 피드 항목을 다시 추가해야 하므로). 또한 탐지하기도 매우 번거로운데, 유일한 방법은 카테고리별 피드를 하나씩 확인하여 어떤 것이 누락되었는지 보는 것, 혹은 최소한 이전에 세어 둔 횟수와 비교하여 현재 피드 수를 수동으로 세어 보는 것이기 때문입니다.
디버깅 시간을 크게 절약할 수 있는 방법은 /admin/plugins/rss_polling 페이지에 피드 총 개수를 표시하는 문자열(예: “N feeds”)을 추가하는 것입니다. 그리고/또는 목록에 번호를 매겨 주는 것도 좋습니다.
와, 훨씬 좋아졌네요! 각 피드가 개별적으로 편집되고, 변경 사항이 한 번에 저장됩니다. 새 피드 추가는 즉시 처리됩니다. 이전에는 피드가 많을 때 새 피드를 추가하고 저장 아이콘을 누르면 전체 목록이 새로 고쳐지기까지 몇 초간의 처리 과정이 있었습니다. 지금은 안정적이고 신뢰할 수 있는 느낌입니다. 정말 감사합니다!
피드가 손실되지 않는지 확인하기 위해 몇 주 정도 지켜보겠습니다.
UI를 개선할 수 있을 것 같아, 적절한 시기에 도움이 된다면 몇 가지 제안을 드립니다:
새 피드를 추가하는 “+” 버튼은 상단에 있지만, 새 행은 목록 하단에 추가됩니다. 피드 목록이 화면보다 길면 사용자가 "+"를 클릭해도 아무 일도 일어나지 않는 것처럼 보입니다. 이 페이지를 잘 알고 있지만, 처음에는 버튼이 고장 난 줄 알았습니다. 그러다 목록 끝을 확인해보니 이전과 똑같이 새 행이 대기하고 있었습니다.
새 행을 목록 상단, 즉 “+” 버튼 바로 아래에 추가하는 것이 좋은 대안이 될 수 있습니다. 이렇게 하면 새 피드가 목록 맨 위에 위치하게 되며, 스케줄러에서도 우선적으로 처리됩니다. 기존 피드보다 새 피드가 더 많은 작업이나 확인 사항이 생길 가능성이 높으므로, 이는 좋은 방식입니다.
“Feed Settings”(피드 설정)와 “Discourse Settings”(디스커스 설정)라는 문자열이 마치 홀로 떠 있는 것처럼 보입니다. 목록이 바로 아래에 있고 스스로 설명이 되므로 "Feed Settings"는 중복된 것처럼 느껴집니다. "Discourse Settings"는 /admin/site_settings/category/plugins?filter=plugin%3Adiscourse-rss-polling 링크를 의미하는 건가요? 아니면 두 개의 다른 하위 페이지를 위한 탭으로 사용하려는 건가요?
좋은 지적이네요. 이 부분을 염두에 두겠습니다. Creating consistent admin interfaces 이 새 주제에 대해 논의하고 있는데, 그로부터 rss-polling 플러그인에 대한 몇 가지 개선 사항이 반영될 것 같습니다. 아마도 인라인 편집 대신 다른 플러그인처럼 별도의 편집 화면을 만들 가능성이 높습니다.
네, 지적해 주셔서 감사합니다. 왜 혼란을 줄 수 있는지 이해할 수 있습니다. "Feed Settings"는 첫 번째 두 열에 대한 라벨로, 해당 열들이 RSS 피드에 영향을 미친다는 것을 나타냅니다. “Discourse Settings” 라벨은 마지막 3열에 대한 것으로, 이들을 수정하면 Discourse 내부의 설정에 영향을 미친다는 것을 나타냅니다.