고급 포럼 모듈에서 제공하는보기를 일관되게 간헐적으로 찾지 못하는 원인은 무엇입니까?


15

Advanced Forum 모듈에서 자주 발생하는 오류 (WSOD)가 발생하면 500 오류가 발생합니다. 프로덕션 환경에서는 시간당 약 20 회 발생하며 시간당 모든 포럼 페이지로드의 2-3 %에 해당합니다. 그것은이다 지속적으로 단속 . 로컬에서는 오류를 일관되게 재현 할 수 없지만 발생합니다.

오류가 있습니다

site / all / modules / contrib / advanced_forum / includes / core-overrides.inc의 라인 232 :

정의되지 않은 메소드 stdClass :: preview () 호출

문제는 advanced_forum_get_topics () 함수에 있습니다.

function advanced_forum_get_topics($tid, $sortby, $forum_per_page, $sort_form = TRUE) {
  $term = taxonomy_term_load($tid);
  drupal_add_feed('taxonomy/term/' . $tid . '/feed', 'RSS - ' . check_plain($term->name));

  // Views handles this page
  $view = views_get_view('advanced_forum_topic_list');
  $view->sort_form = $sort_form;

  return $view->preview('default', array($tid));

}

본질적으로 views_get_view ()가 뷰를 찾지 못하고 리턴 라인에서 예상대로 오브젝트가 작성되지 않습니다. 따라서 문제는 때때로 뷰가 존재한다는 것을 알지 못하는 Views에 있습니다. 이것은 내가 후크 문제라고 생각하게합니다.

이상하게 시작되는 곳은 hook_views_default_views () 및 hook_views_plugins ()의 구현입니다. views.api.php에 따르면 hook_views_default_views ()는 MODULENAME.views_default.inc라는 파일에 있어야하고 hook_views_plugins ()는 MODULENAME.views.inc라는 파일에 있어야합니다. 그러나 두 파일 모두 MODULENAME.views.inc 파일에 있습니다.

views.api.php에서 :

  • hook_views_plugins()
    이 후크는 MODULENAME.views.inc에 위치해야하며 자동로드됩니다.
    MODULENAME.views.inc는 MODULENAME_views_api ()에 의해 리턴 된 'path'키로 지정된 디렉토리 또는 'path'가 지정되지 않은 경우 .module 파일과 동일한 디렉토리에 있어야합니다.

  • hook_views_default_views()
    이 후크는 MODULENAME.views_default.inc에 있어야하며 자동로드됩니다. MODULENAME.views_default.inc는 MODULENAME_views_api ()에 의해 리턴 된 'path'키로 지정된 디렉토리 또는 'path'가 지정되지 않은 경우 .module 파일과 동일한 디렉토리에 있어야합니다.

이 루틴을 겉보기에 올바른 파일로 분할하려고했습니다. 이로 인해 Views는 Advanced Forum보기를 일관되게 찾게되었지만 (Views GUI 목록에 표시됨) 플러그인을 볼 수 없었습니다. Advanced Forum의 페이지는 제대로 실행되었지만 View는 더 이상 표시되지 않는 Advanced Forum에서 제공 한 스타일 플러그인을 참조했기 때문에보기가 비어있었습니다.

뷰 후크에 대해 누락 된 것으로 가정하지만 완전히 혼란에 빠졌습니다.

  • 스택 : Drupal 7, 뷰 (7.x-3.3), CTools (7.x-1.0), 고급 포럼 (7.x-2.0)
  • PHP FPM, APC, nginx, 레디 스
  • 문제에 도움이되는 것을 찾지 못했습니다.

업데이트 1 : 근본 원인을 해결하지는 못했지만 Redis를 비활성화하고 Drupal의 기본 데이터베이스 기반 캐시 스토리지 메커니즘으로 되 돌리면 문제가 발생하지 않습니다.

업데이트 2 : flushallRedis에서 수행하여 로컬에서 문제를 안정적으로 복제 할 수 있습니다 . 포럼 목록을 보는 첫 페이지로드는 치명적입니다. 두 번째 페이지로드 (및 모든 후속)가 정상적으로 작동합니다 . 업데이트 : 오류를 지우려면 관리자 조회 목록 페이지를 방문해야합니다.

업데이트 3 : 추가 문제 해결시 캐시를 지운 후 Redis를 사용할 때만 Views 캐시가 올바르게 다시 작성되지 않아 문제가 발생한 것으로 보입니다. 표준 Drupal 캐시로 되돌릴 때 문제가 발생하지 않습니다. 이 문제가 발생하면 캐시가 올바르게 구축 된 경우 100+가 아니라보기에 2-4 개의 캐시 항목 만 존재합니다. 관리자보기 목록 페이지를 방문하면 캐시가 완전히 빌드되고 문제가 발생하지 않습니다. View view 페이지를 방문하여 문제가 발생했는지 또는 고급 포럼보기인지 확인해야합니다.

업데이트 4 : IRC의 도움이되는 사용자는 이것이 Views 캐시 경쟁 조건 문제와 관련된 문제 일 수 있다고 제안했습니다 : 853864 , 1102252


조회수, Ctools 또는 고급 포럼 대기열에서 문제를 작성해 보셨습니까? 당면한 질문 인 Views 또는 Advanced Forum은 현재 redis를 지원합니까? 내가 아는 한, Views는 관계형 쿼리 언어 (SQL)를 사용하여 디스플레이를 구성합니다. Redis (키-값 저장소)와 얼마나 잘 어울릴 지 잘 모르겠습니다. 이것은 실제로 답이 아니지만, 그 답이 있는지 개인적으로 알 수 없습니다. 또한이 질문에 대한 drupal IRC 채널에 문의하는 것이 좋습니다. 행운을 빕니다.
아마추어 바리 스타

흥미로운 설정이 있습니다.
아마추어 바리 스타

Redis를 Drupal의 캐시 백엔드에 대한 드롭 인 대체로 만 사용하므로 Views에 투명 해야 합니다. 운없이 Do에 게시했습니다. drupal.org/node/1110688
저스틴

@Amateurbarista 판테온 Drupal입니다.
저스틴

1
다른 캐시 백엔드를 시도 할 위치에 있습니까? 뷰에 문제가 있는지 Redis에 문제가 있는지를 잠재적으로 식별 할 수 있습니다.
mpdonadio

답변:


1

IRC에서 정답을 찾은 것 같습니다. 내 경험에서 "일관 적으로 간헐적"은 캐시를 채우는 두 개의 소스가있는 경우입니다. 다른 코드 기반이지만 동일한 데이터베이스에 개발 사이트와 준비 / 생산 사이트가있는 경우가 가장 일반적입니다. 데이터베이스에 연결하기 위해 코드를 읽은 drupal 제공 캐시는 캐시 된 라우팅 / 기능 정보가 교차 오염됩니다. 관리자 / 모듈 페이지를 누르면 모듈 캐시 및 위치가 새로 고쳐지고 관리자 /보기 목록 페이지를 누르면 충돌하는 내용이 아니라 사이트의 관점에서 사이트에 대한 이해를 새로 고치므로 오류가 사라집니다.

서버 관리자 권한이있는 경우 비밀번호를 사이트의 데이터베이스로 변경하고 settings.php의 비밀번호를 변경하고 깨진 부분을 확인하십시오. 귀하의 사이트가 손상을 입지 않아야하고 사이트에 직접 연결되어 있거나 settings.php 파일을 사용하지 않는 한 그 내용을 무단으로 변경해야합니다.

또한 docroot에 views 모듈이 여러 개 설치되어 있지 않은지 확인하십시오.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.