We are using karaf 4.3.7 in which we are installing the bundles as features. While analyzing the framework logs we found that initial boot up take time which is causing the initial start up failure of our karaf
karaf: Ignoring predefined value for KARAF_HOME
Feb 07, 2023 7:07:43 AM org.apache.karaf.main.Main launch
INFO: Installing and starting initial bundles
Feb 07, 2023 7:07:44 AM org.apache.karaf.main.Main launch
INFO: All initial bundles installed and set to start
Feb 07, 2023 7:07:44 AM org.apache.karaf.main.lock.SimpleFileLock lock
INFO: Trying to lock /var/tmp/opt/apache-karaf/lock
Feb 07, 2023 7:07:44 AM org.apache.karaf.main.lock.SimpleFileLock lock
INFO: Lock acquired
Feb 07, 2023 7:07:44 AM org.apache.karaf.main.Main$KarafLockCallback lockAcquired
INFO: Lock acquired. Setting startlevel to 100
After this logs we couldn't find the logs for ~4 minutes approximately and then the downloading logs are appearing.
{"version": "0.2.0", "timestamp": "2023-02-07T07:11:27.782Z", "severity": "TRACE", "service_id": "testapp", "metadata" : {"category": "EDM-tests"}, "message": "Downloading [wrap:file:/opt/apache-karaf/system/io/micrometer/micrometer-registry-prometheus/1.8.1/micrometer-registry-prometheus-1.8.1.jar]"}
Not sure why its taking time to download the logs. Any help would be appreciated.
Related
I'm using the tomcat7-maven-plugin to launch a web application from Maven during the pre-integration-test lifecycle phase so that I can run tests against it locally during the integration-test phase.
I haven't worked much on the web application itself, but for the record it uses JSP and Java controllers which are tied together using Spring MVC 3.0.
When I run Maven (mvn clean verify) on my own machine I see the following output for the plugin:
[INFO] --- tomcat7-maven-plugin:2.2:run-war-only (start-tomcat) # MyProject ---
[INFO] Running war on http://localhost:8080/contentmain
[INFO] Using existing Tomcat server configuration at /Users/alexjohnson/MyWorkspace/MyProject/src/test/resources/com/MyCompany/MyProject/ui/automation/tomcat7
Jan 27, 2015 2:18:54 PM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /Users/alexjohnson/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:.
Jan 27, 2015 2:18:54 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["http-bio-8080"]
Jan 27, 2015 2:18:54 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["ajp-bio-8009"]
Jan 27, 2015 2:18:54 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["http-bio-8443"]
Jan 27, 2015 2:18:54 PM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 425 ms
Jan 27, 2015 2:18:54 PM org.apache.catalina.core.StandardService startInternal
INFO: Starting service Catalina
Jan 27, 2015 2:18:54 PM org.apache.catalina.core.StandardEngine startInternal
INFO: Starting Servlet Engine: Apache Tomcat/7.0.53
Jan 27, 2015 2:18:55 PM org.apache.catalina.loader.WebappClassLoader validateJarFile
// More startup stuff
This is working as expected. Note that WebappClassLoader.validateJarFile is called. Also note that the APR info message is expected since we aren't using these libraries in the test environment.
When I run Maven on our build server (mvn clean verify) I see the following output for the plugin:
[INFO] --- tomcat7-maven-plugin:2.2:run-war-only (start-tomcat) # MyProject ---
[INFO] Running war on http://localhost:8080/contentmain
[INFO] Using existing Tomcat server configuration at /opt/jenkins/workspace/BuildServerWorkspace/src/test/resources/com/MyCompany/MyProject/ui/automation/tomcat7
Jan 27, 2015 2:30:09 PM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
Jan 27, 2015 2:30:09 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["http-bio-8080"]
Jan 27, 2015 2:30:09 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["ajp-bio-8009"]
Jan 27, 2015 2:30:09 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["http-bio-8443"]
Jan 27, 2015 2:30:09 PM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 823 ms
Jan 27, 2015 2:30:09 PM org.apache.catalina.core.StandardService startInternal
INFO: Starting service Catalina
Jan 27, 2015 2:30:09 PM org.apache.catalina.core.StandardEngine startInternal
INFO: Starting Servlet Engine: Apache Tomcat/7.0.53
Jan 27, 2015 2:30:10 PM org.apache.tomcat.util.scan.StandardJarScanner scan
WARNING: Failed to scan JAR [file:/opt/jenkins/BuildServerWorkspace/src/test/resources/com/MyCompany/MyProject/ui/automation/tomcat7/webapps/../../../../../../../../../../../target/MyProject/WEB-INF/lib/openws-1.5.1.jar] from WEB-INF/lib
java.io.FileNotFoundException: /opt/jenkins/BuildServerWorkspace/src/test/resources/com/MyCompany/MyProject/ui/automation/tomcat7/webapps/../../../../../../../../../../../target/MyProject/WEB-INF/lib/openws-1.5.1.jar (No such file or directory)
// Hundreds more FileNotFoundExceptions for JAR files.
This is not working. Note that this time StandardJarScanner.scan is called. Also note that the missing JAR files appear to have been created during the build on my local machine at the same relative path (11 directories out from webapps and 5 more into the target directory). I believe all of these JAR files are for third-party Maven dependencies.
I've read the official JavaDocs, but I can't find a helpful description of the WebappClassLoader or the StandardJarScanner. All I can really gather is that they're both used for loading classes from JAR files when Tomcat starts up.
What I'd like to know:
What are WebappClassLoader and StandardJarScanner specifically being used for in this context?
What are the key differences between WebappClassLoader and StandardJarScanner?
What sort of configuration could be different on the build server that causes it to use the StandardJarScanner instead of the WebappClassLoader when running Maven there (All of the environment variables and Maven parameters which I know of are already the same)?
have a look at this issue https://issues.apache.org/jira/browse/MTOMCAT-239
Sounds like some weird paths from jenkins, I can't figure out why..
WebAppClassLoader and StandardJarScanner are apples and oranges. StandardJarScanner always runs before WebAppClassLoader but only produces log statements if something goes wrong. This means that the StandardJarScanner log statements were appearing at the same point in the failing build as the WebAppClassLoader log statements in the passing build.
Since I was mis-reading these log statements I ended up asking the wrong question. My original problem still stands. I've opened a new question for it at Why is Tomcat throwing FileNotFoundExceptions for existing JAR files?.
I have an installation of couchdb which has been working well for a few weeks now. Today it started to throw an os_process_error exit status 1 when attempting to look at any view. The documents in the DB are very small and the views a quite simple. Total DB size is 20mb, largest document is 2mb, i have noticed that the ERL process pegs the CPU at 99%.
I've looked at:
CouchDB delay building index (CouchDB 1.5.0 on Windows Server 2008 R2)
Specific couchdb views suddenly start timing out
I've increased my time out to 50000 seconds, then lowered it to 500 to see if i could find the document which was killing everything but nothing shows up. Stale views still work as well.
Below is the debug error:
[Mon, 10 Nov 2014 19:22:19 GMT] [debug] [<0.118.0>] Successful cookie auth as: "sking"
[Mon, 10 Nov 2014 19:22:19 GMT] [info] [<0.118.0>] 192.168.247.158 - - GET /_config/native_query_servers/ 200
[Mon, 10 Nov 2014 19:22:19 GMT] [error] [<0.231.0>] OS Process Error <0.233.0> :: {os_process_error,
{exit_status,1}}
[Mon, 10 Nov 2014 19:22:19 GMT] [error] [emulator] Error in process <0.231.0> with exit value: {{nocatch,{os_process_error,{exit_status,1}}},[{couch_os_process,prompt,2,[{file,"c:/cygwin/relax/APACHE~2.1/src/couchdb/couch_os_process.erl"},{line,57}]},{couch_query_servers,map_doc_raw,2,[{file,"c:/cygwin/relax...
[Mon, 10 Nov 2014 19:22:19 GMT] [debug] [<0.117.0>] Minor error in HTTP request: {os_process_error,
{exit_status,1}}
[Mon, 10 Nov 2014 19:22:19 GMT] [debug] [<0.117.0>] Stacktrace: [{couch_mrview_util,get_view,4,
[{file,
"c:/cygwin/relax/APACHE~2.1/src/COUCH_~3/src/couch_mrview_util.erl"},
{line,49}]},
{couch_mrview,query_view,6,
[{file,
"c:/cygwin/relax/APACHE~2.1/src/COUCH_~3/src/couch_mrview.erl"},
{line,75}]},
{couch_httpd,etag_maybe,2,
[{file,
"c:/cygwin/relax/APACHE~2.1/src/couchdb/couch_httpd.erl"},
{line,610}]},
{couch_mrview_http,design_doc_view,5,
[{file,
"c:/cygwin/relax/APACHE~2.1/src/COUCH_~3/src/couch_mrview_http.erl"},
{line,188}]},
{couch_httpd_db,do_db_req,2,
[{file,
"c:/cygwin/relax/APACHE~2.1/src/couchdb/couch_httpd_db.erl"},
{line,234}]},
{couch_httpd,handle_request_int,5,
[{file,
"c:/cygwin/relax/APACHE~2.1/src/couchdb/couch_httpd.erl"},
{line,318}]},
{mochiweb_http,headers,5,
[{file,
"c:/cygwin/relax/APACHE~2.1/src/mochiweb/mochiweb_http.erl"},
{line,94}]},
{proc_lib,init_p_do_apply,3,
[{file,"proc_lib.erl"},{line,239}]}]
[Mon, 10 Nov 2014 19:22:19 GMT] [info] [<0.117.0>] 192.168.247.158 - - GET /tcs/_design/company/_view/Company_Id?limit=101 500
[Mon, 10 Nov 2014 19:22:19 GMT] [error] [<0.117.0>] httpd 500 error response:
{"error":"os_process_error","reason":"{exit_status,1}"}
I figured this out but I am not sure why it happened. There was a HUGE document 57mb which had been uploaded to the DB but it was not visible in Futon or anywhere else.
I only found it after digging into the debug log further. I could not access the document via a CURL Get. I ended up having to use CURL -X DELETE with the specific revision then a purge to get rid of the document. Soon as the document was deleted everything worked as expected.
I'm new to Liferay developing and I’m facing troubles with the startup of my Liferay Tomcat server. It takes almost 3 minutes (169048 ms) which is unacceptable for development. I’d like to get it down to about one minute.
Here are the specs of my machine:
Intel Core Duo T2300 # 1.66GHz
4GB RAM (3.24GB in use)
Windows 7 Enterprise 32 bit with Service Pack 1
I’m using:
Liferay 6.1.1-ce-ga2 bundled with Tomcat 7
Eclipse IDE Juno Release
In order to speed things up, I’ve:
removed all unnecessary portlets from the tomcat\webapps folder.
put the Tomcat native library 1.1.24 in the tomcat\bin folder
tweaked my portal-ext.properties as shown below
#disable some filters
com.liferay.portal.servlet.filters.sso.cas.CASFilter = false
com.liferay.portal.servlet.filters.sso.ntlm.NtlmFilter = false
com.liferay.portal.servlet.filters.sso.ntlm.NtlmPostFilter = false
com.liferay.portal.servlet.filters.sso.opensso.OpenSSOFilter= false
com.liferay.portal.sharepoint.SharepointFilter = false
com.liferay.portal.servlet.filters.gzip.GZipFilter = false
#disable indexing
index.on.startup=false
Here’s my startup log:
Jan 30, 2013 8:39:49 AM org.apache.catalina.core.AprLifecycleListener init
INFO: Loaded APR based Apache Tomcat Native library 1.1.24.
Jan 30, 2013 8:39:49 AM org.apache.catalina.core.AprLifecycleListener init
INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true].
Jan 30, 2013 8:39:51 AM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["http-apr-8080"]
Jan 30, 2013 8:39:51 AM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["ajp-apr-8009"]
Jan 30, 2013 8:39:51 AM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 2620 ms
Jan 30, 2013 8:39:51 AM org.apache.catalina.core.StandardService startInternal
INFO: Starting service Catalina
Jan 30, 2013 8:39:51 AM org.apache.catalina.core.StandardEngine startInternal
INFO: Starting Servlet Engine: Apache Tomcat/7.0.27
Jan 30, 2013 8:39:51 AM org.apache.catalina.startup.HostConfig deployDescriptor
INFO: Deploying configuration descriptor C:\Liferay\portal-6.1.1-ce-ga2\tomcat-7.0.27\conf\Catalina\localhost\Hi-portlet.xml
Jan 30, 2013 8:39:51 AM org.apache.catalina.startup.HostConfig deployDescriptor
WARNING: A docBase C:\Liferay\portal-6.1.1-ce-ga2\tomcat-7.0.27\webapps\Hi-portlet inside the host appBase has been specified, and will be ignored
Jan 30, 2013 8:39:51 AM org.apache.catalina.startup.SetContextPropertiesRule begin
WARNING: [SetContextPropertiesRule]{Context} Setting property 'source' to 'org.eclipse.jst.jee.server:Hi-portlet' did not find a matching property.
Jan 30, 2013 8:39:52 AM org.apache.catalina.startup.HostConfig deployDescriptor
INFO: Deploying configuration descriptor C:\Liferay\portal-6.1.1-ce-ga2\tomcat-7.0.27\conf\Catalina\localhost\ROOT.xml
Loading jar:file:/C:/Liferay/portal-6.1.1-ce-ga2/tomcat-7.0.27/webapps/ROOT/WEB-INF/lib/portal-impl.jar!/system.properties
Loading jar:file:/C:/Liferay/portal-6.1.1-ce-ga2/tomcat-7.0.27/webapps/ROOT/WEB-INF/lib/portal-impl.jar!/portal.properties
Loading file:/C:/Liferay/portal-6.1.1-ce-ga2/portal-ide.properties
Loading file:/C:/Liferay/portal-6.1.1-ce-ga2/tomcat-7.0.27/webapps/ROOT/WEB-INF/classes/portal-developer.properties
Loading file:/C:/Liferay/portal-6.1.1-ce-ga2/portal-ext.properties
Jan 30, 2013 8:39:59 AM org.apache.catalina.core.ApplicationContext log
INFO: Initializing Spring root WebApplicationContext
08:40:16,321 INFO [pool-2-thread-1][DialectDetector:71] Determine dialect for HSQL Database Engine 2
08:40:16,330 WARN [pool-2-thread-1][DialectDetector:86] Liferay is configured to use Hypersonic as its database. Do NOT use Hypersonic in production. Hypersonic is an embedded database useful for development and demo'ing purposes. The database settings can be changed in portal-ext.properties.
08:40:16,484 INFO [pool-2-thread-1][DialectDetector:136] Found dialect org.hibernate.dialect.HSQLDialect
Starting Liferay Portal Community Edition 6.1.1 CE GA2 (Paton / Build 6101 / July 31, 2012)
08:41:36,974 INFO [pool-2-thread-1][BaseDB:452] Database supports case sensitive queries
08:41:37,828 INFO [pool-2-thread-1][ServerDetector:154] Server supports hot deploy
08:41:37,850 INFO [pool-2-thread-1][PluginPackageUtil:1030] Reading plugin package for the root context
08:42:19,657 INFO [pool-2-thread-1][AutoDeployDir:106] Auto deploy scanner started for C:\Liferay\portal-6.1.1-ce-ga2\deploy
08:42:24,410 INFO [pool-2-thread-1][HotDeployImpl:178] Deploying Hi-portlet from queue
08:42:24,415 INFO [pool-2-thread-1][PluginPackageUtil:1033] Reading plugin package for Hi-portlet
Jan 30, 2013 8:42:24 AM org.apache.catalina.core.ApplicationContext log
INFO: Initializing Spring root WebApplicationContext
Jan 30, 2013 8:42:30 AM org.apache.catalina.core.ApplicationContext log
INFO: Initializing Spring FrameworkServlet 'Remoting Servlet'
Jan 30, 2013 8:42:34 AM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory C:\Liferay\portal-6.1.1-ce-ga2\tomcat-7.0.27\webapps\resources-importer-web
08:42:35,522 INFO [pool-2-thread-1][HotDeployImpl:178] Deploying resources-importer-web from queue
08:42:35,523 INFO [pool-2-thread-1][PluginPackageUtil:1033] Reading plugin package for resources-importer-web
Jan 30, 2013 8:42:36 AM org.apache.catalina.core.ApplicationContext log
INFO: Initializing Spring root WebApplicationContext
Jan 30, 2013 8:42:36 AM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory C:\Liferay\portal-6.1.1-ce-ga2\tomcat-7.0.27\webapps\welcome-theme
08:42:36,609 INFO [pool-2-thread-1][HotDeployEvent:109] Plugin welcome-theme requires resources-importer-web
08:42:37,305 INFO [pool-2-thread-1][HotDeployImpl:178] Deploying welcome-theme from queue
08:42:37,306 INFO [pool-2-thread-1][PluginPackageUtil:1033] Reading plugin package for welcome-theme
Jan 30, 2013 8:42:37 AM org.apache.catalina.core.ApplicationContext log
INFO: Initializing Spring root WebApplicationContext
08:42:37,787 INFO [pool-2-thread-1][ThemeHotDeployListener:87] Registering themes for welcome-theme
08:42:39,764 INFO [pool-2-thread-1][ThemeHotDeployListener:100] 1 theme for welcome-theme is available for use
Jan 30, 2013 8:42:40 AM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["http-apr-8080"]
08:42:40,167 INFO [liferay/hot_deploy-1][HotDeployMessageListener:142] Group or layout set prototype already exists for company liferay.com
Jan 30, 2013 8:42:40 AM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["ajp-apr-8009"]
Jan 30, 2013 8:42:40 AM org.apache.catalina.startup.Catalina start
INFO: Server startup in 169048 ms
Any suggestions?
The comments already gave some hints. I'd say, the most important issue is to check if virtual memory (paging) is used - as soon as the OS has to page memory to disk, you have lost: There's a potentially huge performance hit.
When you upgrade your memory (e.g. if you hit the virtual memory) you might want to consider upgrading the OS to a 64bit OS - 32bit can only address 4G and you might hit limits with appserver memory as each process can only get a limited amount of memory.
You could also test if Liferay starts up faster before you run so many other applications - this is another hint that you're running into a memory issue.
The SSD option will further accelerate your system, but for a much higher price than RAM. Also, virtual memory on SSD is not really recommended - it will wear out the drive quicker. And instead of using virtual memory on SSD, rather don't use virtual memory - this will be quicker AND cheaper.
This problem is solved by upgrading to Liferay 7.
While Liferay 7 does not start faster, developers really never need to restart it, as everything can be overridden by deploying new OSGi components. That is actually the biggest difference between Liferay 6 and Liferay 7.
I have been developing for Liferay 7 for 3 months, including very deep customization (for instance intercepting all file reads for audit), and have never needed to restart the Liferay server.
The server speed depends so much on a well configured JVM (memory, garbage collector type, etc) and Tomcat connector thread pool. depending of available server resources. Liferay provide a recommended configuration:
`-server -XX:NewSize=1024m -XX:MaxNewSize=1024m -Xms4096m
-Xmx4096m -XX:MetaspaceSize=300m -XX:MaxMetaspaceSize=300m
-XX:SurvivorRatio=12 –XX:TargetSurvivorRatio=90 –
XX:MaxTenuringThreshold=15 -XX:+UseLargePages
-XX:LargePageSizeInBytes=256m -XX:+UseParNewGC
-XX:ParallelGCThreads=16 -XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled -XX:+CMSCompactWhenClearAllSoftRefs
-XX:CMSInitiatingOccupancyFraction=85 -XX:+CMSScavengeBeforeRemark
-XX:+UseLargePages -XX:LargePageSizeInBytes=256m
-XX:+UseCompressedOops -XX:+DisableExplicitGC -XX:-UseBiasedLocking
-XX:+BindGCTaskThreadsToCPUs -XX:+UseFastAccessorMethods
-XX:InitialCodeCacheSize=32m -XX:ReservedCodeCacheSize=96m`
The above JVM settings should formulate a starting point for your
performance tuning. Each system’s final parameters will vary due to a variety of
factors including number of current users and transaction speed.
In tomcat servers you define this configuration like CATALINA_OPTS environment variable in /[tomcat_server]/bin/setenv.[sh or bat] file.
I'm installing TeamCity in EC2, starting with the Server then moving on the agents. I'm starting with the Amazon Linux AMI, running on a micro instance. Then I did:
sudo yum update
wget http://download.jetbrains.com/teamcity/TeamCity-7.1.1.tar.gz
tar -xvzf TeamCity-7.1.1.tar.gz
cd TeamCity
bin/teamcity-server.sh start
When I start it using bin/teamcity-server.sh start, things happen. I can connect using a web browser which shows the 'TeamCity is starting' page. The teamcity-server.log shows a bunch of activity, unzipping plugins etc.
But then suddently, the server process just disappears. The port's no longer listened to, ps shows no java process running, and the browser can't connect.
There's no error messages in the catalina or teamcity logs. After much trial and error though, I ran bin/teamcity-server.sh run (instead of start) to get console output, and got the following:
Using CATALINA_BASE: /home/ec2-user/TeamCity
Using CATALINA_HOME: /home/ec2-user/TeamCity
Using CATALINA_TMPDIR: /home/ec2-user/TeamCity/temp
Using JRE_HOME: /usr/lib/jvm/jre
Using CLASSPATH: /home/ec2-user/TeamCity/bin/bootstrap.jar:/home/ec2-user/TeamCity/bin/tomcat-juli.jar
Nov 1, 2012 7:22:25 PM org.apache.catalina.core.AprLifecycleListener init
INFO: The APR based Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/server:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64:/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/../lib/amd64:/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib
Nov 1, 2012 7:22:26 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["http-bio-8111"]
Nov 1, 2012 7:22:26 PM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 2742 ms
Nov 1, 2012 7:22:26 PM org.apache.catalina.core.StandardService startInternal
INFO: Starting service Catalina
Nov 1, 2012 7:22:26 PM org.apache.catalina.core.StandardEngine startInternal
INFO: Starting Servlet Engine: Apache Tomcat/7.0.23
Nov 1, 2012 7:22:26 PM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory /home/ec2-user/TeamCity/webapps/ROOT
Log4J configuration file /home/ec2-user/TeamCity/bin/../conf/teamcity-server-log4j.xml will be monitored with interval 10 seconds.
Nov 1, 2012 7:22:30 PM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["http-bio-8111"]
Nov 1, 2012 7:22:30 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 3786 ms
=======================================================================
TeamCity 7.1.1 (build 24074) initialized, OS: Linux, JRE: 1.6.0_24-b24
TeamCity is running in professional mode
bin/teamcity-server.sh: line 18: 4231 Killed ./catalina.sh $1
I promise that I did not kill the process! I can find my way around in Linux well enough, but I'm not at all sure where to go next to find out why or what killed the process. Can anyone help?
After some further scanning of .sh files to see how TeamCity was starting itself up, I noticed that it was grabbing a fair amount of memory for it's java process (either 512m or 750m depending on which line you use).
The EC2 micro instance only has 613m of RAM total. When I realized this, I tried the whole process again with a larger instance, and things worked fine.
I'm still curious if there's a better way I could've known what was causing catalina to die, so if anyone wants to answer with that information...
I'm trying to learn about Spring using SpringSource Tool Suite. I haven't had much successful experience with either at this stage.
So far I've been able to install STS and create a new project, but haven't gotten much further. The problem seems to occur when running the application on the tc Server. I'll run through the steps I've taken and perhaps someone can point out where I'm going wrong. For the record, I'm using Ubuntu 11.10.
I installed STS using the this link, which I found on the
SpringSource Tool Suite Download page.
During installation of STS, I chose to install in my home folder
/home/luke/springsource. I left all of the packs selected:
SpringSource Tool Suite 2.8.0.RELEASE; vFabric tc Server
2.6.1.RELEASE; Spring Roo 1.1.5.RELEASE; Apache Maven 3.0.3
When selecting the JDK path, I chose /usr/lib/jvm/default-java, which
links to /usr/lib/jvm/java-6-openjdk.
The installation completes successfully and I launch STS manually by
going to the installation directory
/home/luke/springsource/sts-2.8.0.RELEASE and executing the file STS.
I had to do this to get STS to run despite having checked the box to
run STS now at the end of installation (not sure if that's a real
problem but thought it'd be worth mentioning).
I choose my workspace
/home/luke/Documents/workspace-sts-2.8.0.RELEASE and clicked OK. So
far so good?
In the dashboard I click Create > Spring Template Project.
In the following dialog I click Spring MVC Project and click Next,
then agree to download.
In the Project Settings dialog, I give the project a name, springmvc,
and a valid top-level package, then click Finish.
I can now see my newly created project in the Package Explorer, as
well as a Servers folder, plus the VMware vFabric tc Server Developer
Edition v2.6 in the Server window.
I drag the project to the server in the Server window and the project
appears there with a [Synchronized] status. I then right-click the
project in the Package Explorer and click Run As > Run on Server.
The aforementioned server is there and selected, so I click Next. The
project I created is in the Configured section of the next screen, so
I click Finish. I'm asked if I want to use Spring Insight, so I click
Yes and the server starts up.
Here's where the big trouble begins.
I get the following output to the console and a 404 message in the
browser window, which is pointed at http://localhost:8080/springmvc/
Console output:
Nov 3, 2011 4:21:29 PM com.springsource.tcserver.security.PropertyDecoder <init>
INFO: tc Runtime property decoder using memory-based key
Nov 3, 2011 4:21:30 PM com.springsource.tcserver.security.PropertyDecoder <init>
INFO: tcServer Runtime property decoder has been initialized in 924 ms
Nov 3, 2011 4:21:32 PM org.apache.coyote.AbstractProtocol init
INFO: Initializing ProtocolHandler ["http-bio-8080"]
Nov 3, 2011 4:21:32 PM com.springsource.tcserver.serviceability.rmi.JmxSocketListener init
INFO: Started up JMX registry on 127.0.0.1:6969 in 368 ms
Nov 3, 2011 4:21:32 PM org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 3809 ms
Nov 3, 2011 4:21:32 PM org.apache.catalina.core.StandardService startInternal
INFO: Starting service Catalina
Nov 3, 2011 4:21:32 PM org.apache.catalina.core.StandardEngine startInternal
INFO: Starting Servlet Engine: VMware vFabric tc Runtime 2.6.1.RELEASE/7.0.20.B.RELEASE
Nov 3, 2011 4:21:32 PM org.apache.catalina.startup.HostConfig deployDescriptor
INFO: Deploying configuration descriptor springmvc.xml from /home/luke/springsource/vfabric-tc-server-developer-2.6.1.RELEASE/spring-insight-instance/conf/Catalina/localhost
Nov 3, 2011 4:21:33 PM org.apache.catalina.startup.SetContextPropertiesRule begin
WARNING: [SetContextPropertiesRule]{Context} Setting property 'source' to 'org.eclipse.jst.jee.server:springmvc' did not find a matching property.
Nov 3, 2011 4:21:33 PM com.springsource.insight.collection.tcserver.ltw.TomcatWeavingInsightClassLoader start
INFO: Context [localhost|springmvc] will not be woven
Nov 3, 2011 4:21:34 PM org.apache.catalina.core.StandardContext listenerStart
SEVERE: Error configuring application listener of class org.springframework.web.context.ContextLoaderListener
java.lang.NoClassDefFoundError: org/springframework/context/ApplicationContextException
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2406)
at java.lang.Class.getConstructor0(Class.java:2716)
at java.lang.Class.newInstance0(Class.java:343)
at java.lang.Class.newInstance(Class.java:325)
at org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:119)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4660)
at org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5226)
at org.apache.catalina.core.StandardContext$1.call(StandardContext.java:5221)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
Caused by: java.lang.ClassNotFoundException: org.springframework.context.ApplicationContextException
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1678)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1523)
... 14 more
Nov 3, 2011 4:21:34 PM org.apache.catalina.core.StandardContext listenerStart
SEVERE: Skipped installing application listeners due to previous error(s)
Nov 3, 2011 4:21:34 PM org.apache.catalina.core.StandardContext startInternal
SEVERE: Error listenerStart
Nov 3, 2011 4:21:34 PM org.apache.catalina.util.SessionIdGenerator createSecureRandom
INFO: Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [227] milliseconds.
Nov 3, 2011 4:21:34 PM org.apache.catalina.core.StandardContext startInternal
SEVERE: Context [/springmvc] startup failed due to previous errors
Nov 3, 2011 4:21:34 PM org.apache.catalina.startup.HostConfig deployDescriptor
INFO: Deploying configuration descriptor insight.xml from /home/luke/springsource/vfabric-tc-server-developer-2.6.1.RELEASE/spring-insight-instance/conf/Catalina/localhost
Nov 3, 2011 4:21:41 PM com.springsource.insight.collection.tcserver.ltw.TomcatWeavingInsightClassLoader start
INFO: Context [localhost|insight] will not be woven
Nov 3, 2011 4:21:42 PM org.apache.catalina.core.ApplicationContext log
INFO: Initializing Spring root WebApplicationContext
Nov 3, 2011 4:22:00 PM org.apache.jasper.compiler.TldLocationsCache tldScanJar
INFO: At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
Nov 3, 2011 4:22:11 PM org.apache.catalina.core.ApplicationContext log
INFO: Initializing Spring FrameworkServlet 'Spring MVC Dispatcher Servlet'
Nov 3, 2011 4:22:18 PM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory manager
Nov 3, 2011 4:22:18 PM com.springsource.insight.collection.tcserver.ltw.TomcatWeavingInsightClassLoader start
INFO: Context [localhost|manager] will not be woven
Nov 3, 2011 4:22:18 PM org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory ROOT
Nov 3, 2011 4:22:18 PM com.springsource.insight.collection.tcserver.ltw.TomcatWeavingInsightClassLoader start
INFO: Context [localhost|ROOT] will not be woven
Nov 3, 2011 4:22:18 PM org.apache.coyote.AbstractProtocol start
INFO: Starting ProtocolHandler ["http-bio-8080"]
Nov 3, 2011 4:22:19 PM org.apache.catalina.startup.Catalina start
INFO: Server startup in 46286 ms
Any help in deciphering this, figuring out a solution and pointing out what I'm doing wrong here in what seems like a very simple use case of STS, would be greatly appreciated.
ditto Ralph.
selected the top level project, went to
Run As > Maven Clean
Run As > Maven Install
Run As > Run on Server
and it went through correctly. I'm not sure why it was failing on the first place though, or why installing it twice fixes it.
Looks like the Project is not correct deployed to the server.
The context menu, for the server contains a option to clean it. After you have clean it use the same context menu and publish the application.
Then try it again.
(An other cause for this problem can be that there is a compiler failure.)