影響Catalyst應用重啓機制的因素有哪些？

我有一個使用-r參數正常啓動的Perl Catalyst應用程序。我注意到2種類型的行爲：對碼的每一個的「虛擬化」（由「虛擬化」影響Catalyst應用重啓機制的因素有哪些？

1）應用程序重新啓動正常我的意思是增加的空間或刪除一個，平穩這樣）

2）應用程序不重新啓動（相同的「虛設改變」），則顯示「試圖重新啓動服務器」的文本和該應用保持阻塞在該狀態下（我要手動殺它）

行爲取決於實際的代碼。似乎有一些與影響哪個行爲在某一時刻起作用的代碼有關。該行爲是恆定的，即相同的代碼有一個恆定的行爲2.
應用程序本身似乎工作正常，沒有任何錯誤或警告。

代碼如何影響此行爲？（我的意思是一般）什麼因素與重啓機制有關？

來源

2011-08-16 ArtM

當通過PSGI（即plackup -r）使用獨立服務器時，我看到了類似的行爲，即服務器重新啓動一次，並且隨後的代碼更改產生消息但不重新啓動。

但是，我從來沒有見過內置服務器myapp_server.pl -r表現得如此。任何對perl模塊，YAML文件等的更改都會成功觸發重新啓動。

在我做的簡短研究中，當時我確實打開了this discussion of Plack and restart。

來源

2011-08-16 21:50:11 RET

這可能是與數據庫連接有關的東西。進一步的實驗表明，如果應用程序被訪問（例如，從瀏覽器），該應用程序不會重新啓動。我想可能會有某種開放的連接到數據庫，它會讓應用程序繼續運行，並且不會讓它重新啓動。我正在使用Catalyst :: Model :: DBI。有任何想法嗎？ – ArtM

這是一種可能性，雖然我沒有看到它與我用MySQL，Informix或SQLite編寫的Cat應用程序發生。如果你 - >在請求週期結束時斷開與數據庫的連接（這通常需要將RenderView從最終處理程序中分離出來，如果你的模板訪問數據庫），這是否會改變行爲？ – RET

我在* end *處理程序中添加了一個顯式的* disconnect *（RenderView移動到另一個子節點並且使用* forward *）。現在DB處理程序在每次請求後都會斷開連接（在DBI模型中添加一條調試消息來查看此消息）。行爲不變。如果這可以幫助，我使用Oracle。 – ArtM

這是因爲在較新版本的Oracle客戶端中信號處理髮生了變化。使用「ora_connect_with_default_signals」選項來恢復默認信號處理程序。

這裏是你如何能在DBIx ::類模型（MyApp的::型號:: DB）做到這一點：

connect_info => [ 
    'dbi:Oracle:mydb', 
    'username', 
    'password', 
    { 
     ora_connect_with_default_signals => [ 'INT' ], 
    }, 
],

或配置文件：

<Model DBIC> 
    connect_info dbi:Oracle:mydb 
    connect_info username 
    connect_info password 
    <connect_info> 
     ora_connect_with_default_signals [ INT ] 
    </connect_info> 
</Model>

來源

2012-07-06 17:44:22

影響Catalyst應用重啓機制的因素有哪些？

回答

相關問題