Re: [Resin-interest] Memory leak - in Resin?
Just tried a new idea: I subclassed EnvironmentClassLoader within the Resin sources and compiled into resin.jar. There is still a leak (in contrast to when I subclassed EnvironmentClassLoader within my own application). Conclusion: The classloader that loads the (Environment)ClassLoader class is somehow of importance. /Mattias Mattias Jiderhamn wrote (2009-03-30 08:40): Daniel, your findings confirms EnvironmentClassLoader as the prime suspect (my own tests are a bit more detailed in an earlier post, http://maillist.caucho.com/pipermail/resin-interest/2008-November/003158.html) Regarding your GC root paths for this class: 1. I haven't noticed any uses of java.util.prefs - could this be part of any of your added JARs (like groovy)? 2. This is the error I have found within Resin that is still to be fixed. As mentioned earlier, there is a quick and dirty patch for Resin 3.1 available at http://jiderhamn.se/resin-leak.patch to avoid this leak. However even with the patch applied I'm still having leaks. 3. This obviously seems like a groovy problem, probably a static initialization triggered at class load. So would you mind giving this another try with groovy removed and with a patched version of Resin? (I can provide a patched resin.jar if that helps) Cheers, Mattias Jiderhamn Daniel Lopez wrote (2009-03-29 14:52): Hi, Using that .war as a sample application, I did some more tests and found some things that might be interesting: I added groovy-1.5.7.jar, hibernate-3.2.6.ga.jar and scala-compiler-2.7.2.jar to WEB-INF/lib. Nothing is done with them, they simply live there. Important data: total size for WEB-INF/lib: 10.3 MB. I then deployed the application, start it and here's some data I gathered after accessing the application a couple of times and hitting Force Garbage Collector until the memory is stable: Heap Memory used: 31MB Instances of com.caucho.loader.EnvironmentClassLoader: 1 I then re-save web.xml so the context is reloaded, access and force GC until memory is stable again: Heap Memory used: 41MB Instances of com.caucho.loader.EnvironmentClassLoader: 2 Once again: Heap Memory used: 51MB Instances of com.caucho.loader.EnvironmentClassLoader: 3 Focusing on the last memory snapshot the 3 EnvironmentClassLoader come from (shortest GC roots): 1.- contextClassLoader of java.util.prefs.AbstractPreferences$EventDispatchThread [Stack Local, Thread] 2.- _classLoader of com.caucho.server.dispatch.Invocation - _invocation of com.caucho.server.http.HttpRequest [Stack Local] - 3.- loader of org.codehaus.groovy.tools.shell.util.Preferences$1 - class of org.codehaus.groovy.tools.shell.util.Preferences$1 - [1] of java.util.prefs.PreferenceChangeListener[3] - prefListeners of java.util.prefs.WindowsPreferences - STORE of org.codehaus.groovy.tools.shell.util.Preferences - [771] of java.lang.Object[2560] - elementData of java.util.Vector - classes of com.caucho.loader.EnvironmentClassLoader - contextClassLoader of java.util.prefs.AbstractPreferences$EventDispatchThread [Stack Local, Thread] They are ordered using order of appearance (in the first memory SS, one like 1 is present, after the first restart one like the 2 is present). And looking at one of the suspected classes to be replicated, org.codehaus.groovy.tools.shell.util.Preferences, you can see that indeed there are 3 instances of that class, each one loaded by a different EnvironmentClassLoader. So, I would say there is indeed a leak and the jackpot would be to find out why the EnvironmentClassLoader instances are not being cleaned. Without knowing how Resin is internally supposed to work and which loaders are supposed not to be there, it's difficult to know. As the classes inside the lib directory are not even used at all, one would suspect is a Resin internal issue, but seeing Preferences classes and ThreadLocal in the mix makes the whole thing quite suspicious :). Any idea or test to find out more? D. Seems to me nothing has changed in this regard in the 4.0 snapshot. I did my leak test as previously described, see below, and no classes were unloaded. - Dowload http://jiderhamn.se/leak.war - Add some JARs to the WEB-INF/lib directory; preferrably a couple of large ones like spring.jar and hibernate.jar (don't use Resin JARs though). - Drop the WAR in a clean installation of Resin - Hit http://...:nn/leak (once is enough) - Force a redeploy by either deleting the webapps/leak dir or touch:ing leak.war - Hit http://...:nn/leak again - Repeat the last two steps for as long as you'd like /Mattias ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Memory leak - in Resin?
After drawing the conclusion below, it isn't very far away to realize it probably has to do with some static (i.e. class loader specific) member of EnvironmentClassLoader. And just as I thought, the heart of the problem is private static EnvironmentLocalArrayListAddLoaderListener _addLoaderListeners More specifically, if line 234 of com.caucho.server.resin.Resin is commented out, the leak is removed (assuming my HttpRequest._invocation patch is also applied) // Environment.addChildLoaderListener(new WebBeansAddLoaderListener()) Scott, you said the WebBeans caches were not to blame because they are classloader local. Well, it seems something about this classloader locality isn't working the way it should, doesn't it...? Do you have enough info to try to fix this in a future (hopefully soon to be released) 3.1 release? Maybe we are now seeing the end to all these memory leaks!!! /Mattias Mattias Jiderhamn wrote (2009-03-30 11:40): Just tried a new idea: I subclassed EnvironmentClassLoader within the Resin sources and compiled into resin.jar. There is still a leak (in contrast to when I subclassed EnvironmentClassLoader within my own application). Conclusion: The classloader that loads the (Environment)ClassLoader class is somehow of importance. /Mattias Mattias Jiderhamn wrote (2009-03-30 08:40): Daniel, your findings confirms EnvironmentClassLoader as the prime suspect (my own tests are a bit more detailed in an earlier post, http://maillist.caucho.com/pipermail/resin-interest/2008-November/003158.html) Regarding your GC root paths for this class: 1. I haven't noticed any uses of java.util.prefs - could this be part of any of your added JARs (like groovy)? 2. This is the error I have found within Resin that is still to be fixed. As mentioned earlier, there is a quick and dirty patch for Resin 3.1 available at http://jiderhamn.se/resin-leak.patch to avoid this leak. However even with the patch applied I'm still having leaks. 3. This obviously seems like a groovy problem, probably a static initialization triggered at class load. So would you mind giving this another try with groovy removed and with a patched version of Resin? (I can provide a patched resin.jar if that helps) Cheers, Mattias Jiderhamn Daniel Lopez wrote (2009-03-29 14:52): Hi, Using that .war as a sample application, I did some more tests and found some things that might be interesting: I added groovy-1.5.7.jar, hibernate-3.2.6.ga.jar and scala-compiler-2.7.2.jar to WEB-INF/lib. Nothing is done with them, they simply live there. Important data: total size for WEB-INF/lib: 10.3 MB. I then deployed the application, start it and here's some data I gathered after accessing the application a couple of times and hitting Force Garbage Collector until the memory is stable: Heap Memory used: 31MB Instances of com.caucho.loader.EnvironmentClassLoader: 1 I then re-save web.xml so the context is reloaded, access and force GC until memory is stable again: Heap Memory used: 41MB Instances of com.caucho.loader.EnvironmentClassLoader: 2 Once again: Heap Memory used: 51MB Instances of com.caucho.loader.EnvironmentClassLoader: 3 Focusing on the last memory snapshot the 3 EnvironmentClassLoader come from (shortest GC roots): 1.- contextClassLoader of java.util.prefs.AbstractPreferences$EventDispatchThread [Stack Local, Thread] 2.- _classLoader of com.caucho.server.dispatch.Invocation - _invocation of com.caucho.server.http.HttpRequest [Stack Local] - 3.- loader of org.codehaus.groovy.tools.shell.util.Preferences$1 - class of org.codehaus.groovy.tools.shell.util.Preferences$1 - [1] of java.util.prefs.PreferenceChangeListener[3] - prefListeners of java.util.prefs.WindowsPreferences - STORE of org.codehaus.groovy.tools.shell.util.Preferences - [771] of java.lang.Object[2560] - elementData of java.util.Vector - classes of com.caucho.loader.EnvironmentClassLoader - contextClassLoader of java.util.prefs.AbstractPreferences$EventDispatchThread [Stack Local, Thread] They are ordered using order of appearance (in the first memory SS, one like 1 is present, after the first restart one like the 2 is present). And looking at one of the suspected classes to be replicated, org.codehaus.groovy.tools.shell.util.Preferences, you can see that indeed there are 3 instances of that class, each one loaded by a different EnvironmentClassLoader. So, I would say there is indeed a leak and the jackpot would be to find out why the EnvironmentClassLoader instances are not being cleaned. Without knowing how Resin is internally supposed to work and which loaders are supposed not to be there, it's difficult to know. As the classes inside the lib directory are not even used at all, one would suspect is a Resin internal issue, but seeing Preferences classes and ThreadLocal in the mix makes the
Re: [Resin-interest] Recompilation of jsp on every request for the same page
On Mar 30, 2009, at 1:18 AM, Prasad Chaudhari wrote:
Hi Scott,
Thanks for the reply.
Level was fine now I have changed it to finer.
After this change, no additional information was logged except for
some tags entire source code was printed out in the log file.
Any guess why resin cannot load already compiled tag class?
Can you double check all the permissions, including all the parent
directory permissions?
The -1 implies that Resin can't load the class at all.
-- Scott
Best Regards
Prasad
--- Scott Ferguson f...@caucho.com schrieb am Fr, 27.3.2009:
Von: Scott Ferguson f...@caucho.com
Betreff: Re: [Resin-interest] Recompilation of jsp on every request
for the same page
An: General Discussion for the Resin application server resin-interest@caucho.com
Datum: Freitag, 27. März 2009, 18:46
On Mar 27, 2009, at 4:29 AM, Prasad Chaudhari wrote:
Hi All,
Resin compiles the jsp page and its included tags every time that
jsp page is clicked. Shouldn't Resin compile the JSP page only
after first click?
After the changing the log level of resin to fine it shows
following stack trace.
[11:43:09.445] {hmux-127.0.0.1:6800-16}
_jsp._web_22dinf._tags._template.b_mainnavigation__tag/b digest
is modified (bold=-5390068824210296648,new=-1/b)
[11:43:09.445] {hmux-127.0.0.1:6800-16}
java.lang.ClassNotFoundException:
Can you turn on fine or finer logging?
That digest is modified indicates that Resin can't load the tag
class for some reason (so the calculated digest is -1).
-- Scott
_jsp._web_22dinf._tags._shop._searchbox__tag in
EnvironmentClassLoader[web-app:http://
localhost:8080/web]
[11:43:09.445] {hmux-127.0.0.1:6800-16} at
com
.caucho.loader.DynamicClassLoader.loadClass(DynamicClassLoader.java:
1291)
[11:43:09.445] {hmux-127.0.0.1:6800-16} at
com
.caucho.loader.DynamicClassLoader.loadClass(DynamicClassLoader.java:
1269)
[11:43:09.445] {hmux-127.0.0.1:6800-16} at
java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
[11:43:09.445] {hmux-127.0.0.1:6800-16} at
java.lang.Class.forName0(Native Method)
[11:43:09.445] {hmux-127.0.0.1:6800-16} at
java.lang.Class.forName(Class.java:247)
[11:43:09.445] {hmux-127.0.0.1:6800-16} at
com.caucho.make.ClassDependency.init(ClassDependency.java:83)
[11:43:09.445] {hmux-127.0.0.1:6800-16} at
_jsp
._web_22dinf
._jsp._shop._homepage._homepage__jsp.init(b_homepage__jsp.java:
693/b)
[11:43:09.445] {hmux-127.0.0.1:6800-16} at
com.caucho.jsp.JspManager.preload(JspManager.java:320)
[11:43:09.445] {hmux-127.0.0.1:6800-16} at
com.caucho.jsp.JspManager.compile(JspManager.java:218)
[11:43:09.445] {hmux-127.0.0.1:6800-16} at
com.caucho.jsp.JspManager.createPage(JspManager.java:171)
[11:43:09.445] {hmux-127.0.0.1:6800-16} at
com.caucho.jsp.JspManager.createPage(JspManager.java:150)
[11:43:09.445] {hmux-127.0.0.1:6800-16} at
com.caucho.jsp.PageManager.getPage(PageManager.java:307)
[11:43:09.445] {hmux-127.0.0.1:6800-16} at
com.caucho.jsp.PageManager.getPage(PageManager.java:237)
[11:43:09.445] {hmux-127.0.0.1:6800-16} at
com.caucho.jsp.PageManager.getPage(PageManager.java:220)
[11:43:09.445] {hmux-127.0.0.1:6800-16} at
com.caucho.jsp.QServlet.getSubPage(QServlet.java:295)
[11:43:09.445] {hmux-127.0.0.1:6800-16} at
com.caucho.jsp.QServlet.getPage(QServlet.java:210)
[11:43:09.445] {hmux-127.0.0.1:6800-16} at
com
.caucho
.server.dispatch.PageFilterChain.compilePage(PageFilterChain.java:
238)
[11:43:09.445] {hmux-127.0.0.1:6800-16} at
com
.caucho
.server.dispatch.PageFilterChain.doFilter(PageFilterChain.java:145)
Same error as below can be observed for all included tags.
Can experts here tell why this is happening and how can it be fixed.
Best Regards
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] resin-admin in 3.2.1. Pro feature only?
On Mar 29, 2009, at 2:38 PM, Rick Mann wrote:
Hi. When I first installed resin on my new machine, I could swear I
had access to resin-admin. Now, it just gives me 404 errors. Near as I
can tell it's configured.
resin-admin is in both open source and pro. It has a specific web-
app in the default resin.xml. The location of the web-app is
relative to ${resin.root}, so moving directories or changing the
config file might cause problems.
-- Scott
Should I be able to access it (resin open-source).
TIA,
--
Rick
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] all my requested are limited with 3.2.1
On Mar 28, 2009, at 5:21 PM, Riccardo Cohen wrote: Hello I have a problem with all my ejb requests in resin pro 3.2.1 When I execute this : Query hqr=m_manager.createQuery(select h from Adluser h order by h.id); hqr.setFirstResult(numstart); hqr.setMaxResults(numcnt); I have the good result (starts at numstart, and get numcnt items) But when I do not set the limits : Query hqr=m_manager.createQuery(select h from Adluser h order by h.id); I have only 32 results whatever you have in the database. I've filed this as http://bugs.caucho.com/view.php?id=3424 The 32 comes from an internal cache, but that cache should be invisible to any users. -- Scott This appeared only from 3,2,1 because I do not have this problem with 3.2.0. Am I doing something wrong ? Thanks for any help. PS: I went to 3.2.1 because I had problems with scheduled-task in 3,2.0 -- Riccardo Cohen Architecte du Logiciel http://www.architectedulogiciel.fr +33 (0)6.09.83.64.49 ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] 3.2.1 on Mac OS X/Darwin?
On Mar 29, 2009, at 16:34:27, Riccardo Cohen wrote: I compiled the pro and open source version of resin321 on macos 10.5.6 last week and it worked with no problem on java 1.5 Any reason to use java 1.6 ? I tried switching back to Java 1.5, and continue to get the same errors. I wonder what's going on. I wish ld was a little more informative about the architecture issues. ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Why must we define beans in xml?
Thanks... you're absolutely right. Works great. Jeff On Thu, Mar 26, 2009 at 9:40 AM, Scott Ferguson f...@caucho.com wrote: On Mar 25, 2009, at 7:27 PM, Jeff Schnitzer wrote: Is there a compelling reason why we must define our beans and services in resin-web.xml? Will this continue to be the case going forward in Resin 4.0? You don't need to define the beans in resin-web.xml. You do need a marker file like META-INF/beans.xml or META-INF/ejb-jar.xml. It's a minor nuisance, yes, but... it's nice to add a class to the project, annotate it with @Service or @Stateless or whatever, and have it automatically detected as a bean. JBoss works this way :-) If you have a META-INF/ejb-jar.xml, Resin should already pick this up. -- Scott This actually has some impact on the SubEtha code that Scott and I are working on. SubEtha plugins automatically register themselves with the container when you drop a jar file containing them into the server. This makes it easy for minimally java-savvy people to write some code, drop it in the container, and have it immediately available. Adding xml files complicates the matter. Thanks, Jeff ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] 3.2.1 on Mac OS X/Darwin?
On Mon, Mar 30, 2009 at 02:12:24PM -0700, Rick Mann wrote: On Mar 29, 2009, at 16:34:27, Riccardo Cohen wrote: I compiled the pro and open source version of resin321 on macos 10.5.6 last week and it worked with no problem on java 1.5 Any reason to use java 1.6 ? I tried switching back to Java 1.5, and continue to get the same errors. I wonder what's going on. I wish ld was a little more informative about the architecture issues. Hi Rick, Check your JAVA_HOME environment variable and make sure it matches up with the version of java in your path. If it doesn't, try setting your PATH to JAVA_HOME/bin:$PATH to ensure that the configure script and make are getting the same version. I'm not sure if this is the recommended Mac OS X way of specifying your JAVA_HOME, but I've got mine set to /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home Emil Emil Ong Chief Evangelist Caucho Technology, Inc. Tel. (858) 456-0300 mailto:e...@caucho.com http://blog.caucho.com/ Caucho: Reliable Open Source -- Resin: application server -- Quercus: PHP in Java -- Java CanDI: contexts and dependency injection ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] MBean Registration
Is there an annotation based way to register Management Beans? I know I can do this in XML, but is there an annotation, or interface that will work the same way? resource mbean-name=subetha:name=Cleanup type=org.subethamail.core.admin.CleanupBean mbean-interface=org.subethamail.core.admin.CleanupManagement/ Thanks in advance, Scott ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Amber (JPA) Table Indexes
Is there a way to hint to Amber that a column should be indexed? For example we will be doing a lot of queries like this: Select u from User where u.isActive == true ... And it would be nice if the isActive column is indexed. Thanks in advance, Scott ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Using Hibernate as EntityManager in Resin 4
Well, I have configured a test app to use hibernate and I have a few
problems (and a bit of success):
I was able to get the same code working from a servlet, but when
trying to get data I get an exception when running from a @Service (in
the @PostConstruct method):
[21:26:06.430] {main} java.lang.IllegalStateException:
EntityManagerTransactionProxy[test,null]: @PersistenceContext
EntityManager may not be used outside of a transaction
[21:26:06.430] {main} at
com.caucho.amber.manager.EntityManagerTransactionProxy.getCurrent(EntityManagerTransactionProxy.java:408)
[21:26:06.430] {main} at
com.caucho.amber.manager.EntityManagerTransactionProxy.createQuery(EntityManagerTransactionProxy.java:193)
[21:26:06.430] {main} at
test2.services.InitDBService.checkDBandInit(InitDBService.java:47)
[21:26:06.430] {main} at
test2.services.InitDBService.postConstruct(InitDBService.java:36)
[21:26:06.430] {main} at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[21:26:06.430] {main} at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[21:26:06.430] {main} at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[21:26:06.430] {main} at java.lang.reflect.Method.invoke(Method.java:597)
[21:26:06.430] {main} at
com.caucho.config.j2ee.PostConstructProgram.inject(PostConstructProgram.java:121)
[21:26:06.430] {main} at
com.caucho.config.inject.ComponentImpl.init(ComponentImpl.java:344)
[21:26:06.430] {main} at
com.caucho.config.inject.SimpleBean.create(SimpleBean.java:421)
[21:26:06.430] {main} at
com.caucho.config.scope.ScopeContext.get(ScopeContext.java:90)
[21:26:06.430] {main} at
com.caucho.config.inject.InjectManager.getInstanceRec(InjectManager.java:1331)
[21:26:06.430] {main} at
com.caucho.config.inject.InjectManager.getInstance(InjectManager.java:1288)
[21:26:06.430] {main} at
com.caucho.config.inject.InjectManager.getInstance(InjectManager.java:1345)
[21:26:06.430] {main} at
com.caucho.server.webbeans.ResinWebBeansProducer.serviceStartup(ResinWebBeansProducer.java:167)
[21:26:06.430] {main} at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[21:26:06.430] {main} at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[21:26:06.430] {main} at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[21:26:06.430] {main} at java.lang.reflect.Method.invoke(Method.java:597)
[21:26:06.430] {main} at
com.caucho.config.event.ObserverImpl.notify(ObserverImpl.java:191)
[21:26:06.430] {main} at
com.caucho.config.inject.ObserverMap.fireEvent(ObserverMap.java:82)
[21:26:06.430] {main} at
com.caucho.config.inject.InjectManager.fireEventImpl(InjectManager.java:1559)
[21:26:06.430] {main} at
com.caucho.config.inject.InjectManager.fireEventImpl(InjectManager.java:1540)
[21:26:06.430] {main} at
com.caucho.config.inject.InjectManager.fireEventImpl(InjectManager.java:1540)
[21:26:06.430] {main} at
com.caucho.config.inject.InjectManager.fireEventImpl(InjectManager.java:1540)
[21:26:06.430] {main} at
com.caucho.config.inject.InjectManager.fireEventImpl(InjectManager.java:1540)
[21:26:06.430] {main} at
com.caucho.config.inject.InjectManager.fireEvent(InjectManager.java:1534)
[21:26:06.430] {main} at
com.caucho.config.inject.InjectManager.registerBean(InjectManager.java:2066)
[21:26:06.430] {main} at
com.caucho.config.inject.InjectManager.registerBean(InjectManager.java:2044)
[21:26:06.430] {main} at
com.caucho.config.inject.InjectManager.registerBean(InjectManager.java:2047)
[21:26:06.430] {main} at
com.caucho.config.inject.InjectManager.startServices(InjectManager.java:2013)
[21:26:06.430] {main} at
com.caucho.config.inject.InjectManager.environmentStart(InjectManager.java:1993)
[21:26:06.430] {main} at
com.caucho.loader.EnvironmentClassLoader.start(EnvironmentClassLoader.java:703)
[21:26:06.430] {main} at
com.caucho.server.webapp.WebApp.start(WebApp.java:2021)
[21:26:06.430] {main} at
com.caucho.server.deploy.DeployController.startImpl(DeployController.java:678)
[21:26:06.430] {main} at
com.caucho.server.deploy.StartAutoRedeployAutoStrategy.startOnInit(StartAutoRedeployAutoStrategy.java:72)
[21:26:06.430] {main} at
com.caucho.server.deploy.DeployController.startOnInit(DeployController.java:549)
[21:26:06.430] {main} at
com.caucho.server.deploy.DeployContainer.start(DeployContainer.java:160)
[21:26:06.430] {main} at
com.caucho.server.webapp.WebAppContainer.startImpl(WebAppContainer.java:681)
[21:26:06.430] {main} at com.caucho.server.host.Host.startImpl(Host.java:496)
[21:26:06.430] {main} at
com.caucho.server.webapp.WebAppContainer.start(WebAppContainer.java:661)
[21:26:06.430] {main} at
com.caucho.server.deploy.DeployController.startImpl(DeployController.java:678)
[21:26:06.430] {main} at
com.caucho.server.deploy.StartAutoRedeployAutoStrategy.startOnInit(StartAutoRedeployAutoStrategy.java:72)
[21:26:06.430] {main}
