0

我創建了兩個獨立的Play!框架2.1.0應用程序:一個front-end和一個cms,它應該在不同的端口上運行。這些項目共享很多代碼,並連接到相同的數據庫(使用相同的憑據)。Play Framework 2多個生產實例

我用play dist打包了這兩個項目。我可以開始任何一個罰款(front-end/start -Dhttp.port=1234 &),它創建一個PID文件並按預期運行。

但是,一旦我啓動了另一個項目(back-end/start -Dhttp.port=5678 &),我就會看到該項目開始,但第一個項目會被殺死!

當兩個項目互相獨立時,兩個項目都能正常工作,而且我開始它們的順序似乎沒有什麼區別。

我改變了application secret,使它們不同。

請注意,第一個進程在瀏覽器中嘗試訪問它時(在驗證第二個進程正在運行後)時會被終止,但它的PID文件永遠不會被刪除。

編輯: 如下的建議,我在兩個終端跑了這兩個應用,這是發生了什麼事:

./start -Dhttp.port=9000 -Dlogger.root=DEBUG -Dlogger.play=DEBUG -Dlogger.application=DEBUG 
Play server process ID is 12870 
[debug] c.j.b.BoneCPDataSource - JDBC URL = jdbc:mysql://localhost/hp?useUnicode=yes&characterEncoding=UTF-8&connectionCollation=utf8_general_ci, Username = hp, partitions = 1, max (per partition) = 30, min (per partition) = 5, helper threads = 0, idle max age = 10 min, idle test period = 1 min 
[info] play - database [default] connected at jdbc:mysql://localhost/hp?useUnicode=yes&characterEncoding=UTF-8&connectionCollation=utf8_general_ci 
[debug] o.r.Reflections - going to scan these urls: 
jar:file:/var/play-apps/hp-frontend-1.0/lib/hp-frontend_2.10-1.0.jar!/ 
jar:file:/var/play-apps/hp-frontend-1.0/lib/play.play_2.10-2.1.0.jar!/ 

[info] o.r.Reflections - Reflections took 213 ms to scan 2 urls, producing 12 keys and 24 values 
[info] c.a.e.s.c.DefaultServerFactory - DatabasePlatform name:default platform:mysql 
[debug] c.a.e.c.AbstractNamingConvention - Using maxConstraintNameLength of 64 
[debug] c.a.e.s.l.t.ThreadPool - ThreadPool grow created [Ebean-default.0] size[0] 
[debug] c.a.e.a.ClassLoadContext - Context and Caller ClassLoader's same instance of sun.misc.Launcher$AppClassLoader 
[info] c.a.e.s.s.SubClassManager - SubClassFactory parent ClassLoader  [sun.misc.Launcher$AppClassLoader] 
[debug] c.a.e.a.ClassLoadContext - Context and Caller ClassLoader's same instance of sun.misc.Launcher$AppClassLoader 
[debug] c.a.e.s.t.DefaultTypeManager - Registering Joda data types 
[debug] c.a.e.s.d.BeanDescriptorManager - BeanPersistControllers[0] BeanFinders[0] BeanPersistListeners[0] BeanQueryAdapters[0] 
[debug] c.a.e.s.d.p.DeployCreateProperties - Skipping transient field _ebean_identity in play.db.ebean.Model 
[debug] c.a.e.s.d.p.DeployCreateProperties - Skipping transient field _ebean_identity in play.db.ebean.Model 
[debug] c.a.e.s.d.p.DeployCreateProperties - Skipping transient field _ebean_identity in play.db.ebean.Model 
[info] c.a.e.s.d.BeanDescriptorManager - Explicit sequence on models.CmsPage but not supported by DB Platform - ignored 
[info] c.a.e.s.d.BeanDescriptorManager - Explicit sequence on models.Image but not supported by DB Platform - ignored 
[debug] c.a.e.s.d.BeanDescriptor - BeanDescriptor initialise models.CmsPage 
[debug] c.a.e.s.d.BeanDescriptor - BeanDescriptor initialise models.Image 
[debug] c.a.e.s.d.BeanDescriptor - BeanDescriptor initialise models.PagesImages 
[info] c.a.e.s.d.BeanDescriptorManager - Entities enhanced[3] subclassed[0] 
[debug] j.m.mbeanserver - ObjectName = JMImplementation:type=MBeanServerDelegate 
[debug] j.m.mbeanserver - name = JMImplementation:type=MBeanServerDelegate 
[debug] j.m.mbeanserver - Send create notification of object JMImplementation:type=MBeanServerDelegate 
[debug] j.m.mbeanserver - JMX.mbean.registered JMImplementation:type=MBeanServerDelegate 
[debug] j.m.mbeanserver - ObjectName = Ebean:server=default2,function=Logging 
[debug] j.m.mbeanserver - name = Ebean:server=default2,function=Logging 
[debug] j.m.mbeanserver - Send create notification of object Ebean:function=Logging,server=default2 
[debug] j.m.mbeanserver - JMX.mbean.registered Ebean:server=default2,function=Logging 
[debug] j.m.mbeanserver - ObjectName = Ebean:server=default2,key=AutoFetch 
[debug] j.m.mbeanserver - name = Ebean:server=default2,key=AutoFetch 
[debug] j.m.mbeanserver - Send create notification of object Ebean:key=AutoFetch,server=default2 
[debug] j.m.mbeanserver - JMX.mbean.registered Ebean:server=default2,key=AutoFetch 
[debug] c.a.ebean.Ebean - GlobalProperties.isSkipPrimaryServer() 
[debug] n.s.e.c.ConfigurationFactory - Configuring ehcache from ehcache.xml found in the classpath: jar:file:/var/play-apps/hp-frontend-1.0/lib/play.play_2.10-2.1.0.jar!/ehcache.xml 
[debug] n.s.e.c.ConfigurationFactory - Configuring ehcache from URL: jar:file:/var/play-apps/hp-frontend-1.0/lib/play.play_2.10-2.1.0.jar!/ehcache.xml 
[debug] n.s.e.c.ConfigurationFactory - Configuring ehcache from InputStream 
[debug] n.s.e.c.BeanHandler - Ignoring ehcache attribute xmlns:xsi 
[debug] n.s.e.c.BeanHandler - Ignoring ehcache attribute xsi:noNamespaceSchemaLocation 
[debug] n.s.e.CacheManager - Creating new CacheManager with default config 
[debug] n.s.e.u.PropertyUtil - propertiesString is null. 
[debug] n.s.e.c.ConfigurationHelper - No CacheManagerEventListenerFactory class specified. Skipping... 
[debug] n.s.e.Cache - No BootstrapCacheLoaderFactory class specified. Skipping... 
[debug] n.s.e.Cache - CacheWriter factory not configured. Skipping... 
[debug] n.s.e.c.ConfigurationHelper - No CacheExceptionHandlerFactory class specified. Skipping... 
[debug] n.s.e.s.MemoryStore - Initialized net.sf.ehcache.store.NotifyingMemoryStore for play 
[debug] n.s.e.Cache - Initialised cache: play 
[debug] n.s.e.c.ConfigurationHelper - CacheDecoratorFactory not configured for defaultCache. Skipping for 'play'. 
[info] play - Application started (Prod) 
[info] play - Listening for HTTP on /0:0:0:0:0:0:0:0:9000 
---> Browsed to :9000 here. Waited a minute, then this appeared: 
Killed 

而第二個過程:

./start -Dhttp.port=9010 -Dlogger.play=DEBUG 
Play server process ID is 12758 
[info] play - database [default] connected at jdbc:mysql://localhost/hp? useUnicode=yes&characterEncoding=UTF-8&connectionCollation=utf8_general_ci 
[info] play - Application started (Prod) 
[info] play - Listening for HTTP on /0:0:0:0:0:0:0:0:9010 
->Here, I browsed to :9010 and after 30 secs it started working 
^C 

(調試輸出是完全相同,所以在這裏省略)

我嘗試了多次的過程,結果有一些小的變化:當等待第一個應用程序到達'聽fo r HTTP'在啓動第二個之前,第二個從未過去'數據庫[默認]連接'。

+0

我創建了兩個播放項目並在彼此之後啓動它們,但我無法再現您的錯誤。你的日誌裏有什麼? – Schleichardt 2013-02-24 07:06:35

回答

0

你的問題很奇怪,你應該能夠在一次啓動這兩個應用程序,應該沒有問題。在不同的端口上運行不同的應用程序(甚至在很多情況下運行相同的應用程序)是非常常見的情況,我甚至無法想象導致所描述行爲的原因。

事實上,RUNNING_PID文件保持未刪除狀態表示存在一些異常程序終止發生,所以可能有些元素不允許與其他虛擬機共享一些資源。

很可能它可以在日誌和或終端中找到。在沒有&字符的情況下啓動應用程序 - 因此它會將日誌直接保存在終端中 - 請檢查在第一個應用程序被終止後它說的是什麼。

+0

我按照你的建議,並添加了對我的問題的答覆 – 2013-02-25 21:03:29