웹 사이트 방문시 500 분 내부 서버 오류

Question

my other question here on stack에 대한 후속 질문입니다.

재생에 문제가 있는지 또는 웹 서버의 정상적인 결과인지 확실하지 않습니다. 나는 놀이를 사용하고 있습니다. 2.1.2

정상적으로 작동하면 http 코드 200을 즉시 반환하는 웹 사이트가 있습니다. 사이트에 문제가 있으면 어떤 이유로 든 즉시 500 내부 서버 오류가 반환되지 않습니다. 마침내 500 오류를 반환하는 데 5 분이 걸리는 것 같습니다.

재생 프레임 워크를 사용하여 사이트를 실행하는 데 문제가 있습니까? 그렇지 않은 이유를 확인해야하는 항목이 있습니까? 또한 파이썬에서 웹 사이트를 확인하기 위해 httplib을 사용하고 있습니다.

디버깅을 돕기 위해 추가 할 세부 정보는 모르겠지만 간단한 대답은 사이트에 무언가를하고 있으며 제한 시간 (5 분)까지 500 개의 코드로 답장을 보내지 않는다는 것입니다. 통과했다.

업데이트 : 첨부 파일로 서버에서 보낸 메시지가 첨부됩니다. 이것은 테스트 서버에 있으므로 실패 할 것으로 예상됩니다. ulimit -n 275을 실행하여 서버에 파일 부족 오류가 발생했습니다. 내가 5+ 분을 기다린 후 내 스크립트를 실행하는 경우,

got some exception 
Traceback (most recent call last): 
    File "monitorAlive.py", line 27, in <module> 
    main() 
    File "monitorAlive.py", line 24, in main 
    get_status_code(host) 
    File "monitorAlive.py", line 16, in get_status_code 
    if resp == 200: 
UnboundLocalError: local variable 'resp' referenced before assignment 

그러나 :

이

내가 문제를 일으키는의 5 분 이내에 실행하면 내 스크립트에서 얻을 오류입니다

didn't get a 200 http response. something wrong 
this is the code we got: 500 

이 내가 캘리포니아 당시의 로그 MSG를은 다음 사이트에서 확인이 내가 무엇을 얻을 파일 부족 오류를 사용했습니다. 내 스크립트는 웹 서버에 추가 메시지를 기록하지 않지만 의도적으로 사이트/서버에 문제가 발생하여 스크립트를 실행하기 때문에 이러한 메시지는 파일 오류가 발생하여 발생합니다.

! @70jo4chan - Internal server error, for (GET) [/] -> 

play.api.PlayException: Not initialized[?] 
     at play.core.ReloadableApplication.<init>(ApplicationProvider.scala:92) ~[play_2.10.jar:2.1.2] 
     at play.core.server.NettyServer$$anonfun$mainDev$1.apply(NettyServer.scala:273) ~[play_2.10.jar:2.1.2] 
     at play.core.server.NettyServer$$anonfun$mainDev$1.apply(NettyServer.scala:272) ~[play_2.10.jar:2.1.2] 
     at play.utils.Threads$.withContextClassLoader(Threads.scala:18) ~[play_2.10.jar:2.1.2] 
     at play.core.server.NettyServer$.mainDev(NettyServer.scala:271) ~[play_2.10.jar:2.1.2] 
     at play.core.server.NettyServer.mainDev(NettyServer.scala) ~[play_2.10.jar:2.1.2] 
     at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_71] 
     at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_71] 
     at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_71] 
     at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_71] 
     at sbt.PlayCommands$$anonfun$53$$anonfun$55.apply(PlayCommands.scala:575) ~[na:na] 
     at sbt.PlayCommands$$anonfun$53$$anonfun$55.apply(PlayCommands.scala:507) ~[na:na] 
     at scala.Either$RightProjection.map(Either.scala:533) ~[na:na] 
     at sbt.PlayCommands$$anonfun$53.apply(PlayCommands.scala:507) ~[na:na] 
     at sbt.PlayCommands$$anonfun$53.apply(PlayCommands.scala:487) ~[na:na] 
     at sbt.Command$$anonfun$sbt$Command$$apply1$1$$anonfun$apply$6.apply(Command.scala:72) ~[na:na] 
     at sbt.Command$.process(Command.scala:90) ~[na:na] 
     at sbt.MainLoop$$anonfun$next$1$$anonfun$apply$1.apply(MainLoop.scala:71) ~[na:na] 
     at sbt.MainLoop$$anonfun$next$1$$anonfun$apply$1.apply(MainLoop.scala:71) ~[na:na] 
     at sbt.State$$anon$2.process(State.scala:170) ~[na:na] 
     at sbt.MainLoop$$anonfun$next$1.apply(MainLoop.scala:71) ~[na:na] 
     at sbt.MainLoop$$anonfun$next$1.apply(MainLoop.scala:71) ~[na:na] 
     at sbt.ErrorHandling$.wideConvert(ErrorHandling.scala:18) ~[na:na] 
     at sbt.MainLoop$.next(MainLoop.scala:71) ~[na:na] 
     at sbt.MainLoop$.run(MainLoop.scala:64) ~[na:na] 
     at sbt.MainLoop$$anonfun$runWithNewLog$1.apply(MainLoop.scala:53) ~[na:na] 
     at sbt.MainLoop$$anonfun$runWithNewLog$1.apply(MainLoop.scala:50) ~[na:na] 
     at sbt.Using.apply(Using.scala:25) ~[na:na] 
     at sbt.MainLoop$.runWithNewLog(MainLoop.scala:50) ~[na:na] 
     at sbt.MainLoop$.runAndClearLast(MainLoop.scala:33) ~[na:na] 
     at sbt.MainLoop$.runLoggedLoop(MainLoop.scala:17) ~[na:na] 
     at sbt.MainLoop$.runLogged(MainLoop.scala:13) ~[na:na] 
     at sbt.xMain.run(Main.scala:26) ~[na:na] 
     at xsbt.boot.Launch$.run(Launch.scala:55) ~[na:na] 
     at xsbt.boot.Launch$$anonfun$explicit$1.apply(Launch.scala:45) ~[na:na] 
     at xsbt.boot.Launch$.launch(Launch.scala:69) ~[na:na] 
     at xsbt.boot.Launch$.apply(Launch.scala:16) ~[na:na] 
     at xsbt.boot.Boot$.runImpl(Boot.scala:31) ~[na:na] 
     at xsbt.boot.Boot$.main(Boot.scala:20) ~[na:na] 
     at xsbt.boot.Boot.main(Boot.scala) ~[na:na] 

업데이트 # 2 : 당신이 play run을 사용하면 내가

Answer 1

플레이 2.1.2를 사용하고 얘기를 깜빡 했네요, 앱 개발자 모드에서 시작됩니다. 이 모드에서는 앱 자체가 첫 번째 요청을 받으면 실제로 시작됩니다. 때로는 서버가 시작된 후에도 요청을 받아 들일 준비가되어 있어도 Play는 무언가가 변경되고 다시 컴파일되어 브라우저가 "대기"상태가되는 경우가 발생합니다 (모든 Play 2.x 버전에서이 동작이 나타났습니다. 하지만 내 설정이나 버그와 관련이 있는지는 잘 모르겠습니다.) 이것이 지연되는 이유 일 수 있습니다.

이 문제를 피하는 가장 좋은 방법은 play copile 및 play start을 사용하거나 play dist을 사용하여 제작 준비가 완료된 응용 프로그램 파일을 제공하는 것입니다. 자세한 내용은 here을 참조하십시오.