Re: is there any way to auto recover the wasce server?
I'd say it's not a good idea to restart the server to clean up things. If it's the performance becomes unacceptable because there are too many users and the server is overloaded, then you should add more servers to the cluster to distribute the workload, or upgrade the hardware configuration of the current server (more memory, more CPU, etc.). If there are memory leaks (as you say the memory consumption gets larger and larger), you should check whether it's a problem in your application (e.g., not releasing objects in time). It might also be a problem in the server, for which people here are happy to work with you to solve. -Jack 2009/4/9 WenDong Zhang zwd2...@gmail.com Hi all. I'm using httpd2.2 mod_jk as the load balancer server, and to wasce server as the cluster nodes. The requests per second for each wasce node maybe more than 200 times. Now after running for a long time, the wasce server's performance is getting lower (the system resource usage is higher, cpu usage almost 100% memory usage is higher than 1G). When the response time of wasce server is too long (more than 3s), I need to restart the wasce server to release the system resource. My question is: Could to wasce server auto clear the using resource after running for a period? such as terminate the running threads, release system resource. Even this maybe lost some requests, but it can server the subsequent requests timely. Now my way is restart the wasce server per several minutes... Thanks. -- Best Regards! Wen Dong
Re: G trunk and maven dependencies question
David Jencks wrote: Where exactly do you see the file with the dated version? I've looked around in my build and don't see anything obvious. BTW this problem sounds familiar but I don't remember yet when I ran into it... Searching for geronimo-jaspi_1.0_spec in trunk i see the dated version tag in loots (if not all) of the built /target ... dependecies.xml files. I am rebuilding trunk now to give some exact locations. I don't think this is a local problem on my comp as I get the same problem on a newly setup vmware server (i.e no long time forgotten tweaking on that one). thanks peter thanks david jencks On Apr 9, 2009, at 4:36 PM, Peter Petersson wrote: I am building some geronimo plugins against G v2.2 (trunk) and I am getting a strange unresolved maven dependency issue against a dated version of the geronimo-jaspi_1.0_spec (see below) when I build from a clean .m2 repository. AFAICT the geronimo-jaspi_1.0_spec version should be 1.0-SNAPSHOT (as declared in geronimo server root pom). I have Geronimo Server Private Repository and Apache Snapshots Repository as repository settings in my project (should be enough to build gplugins?) but only when I first build Geronimo server trunk will my derby plugin build without error. Looking at the generated dependency versions for geronimo-jaspi_1.0_spec in my built geronimo server trunk I also see a dated version (1.0-20080804.213256-1) of the spec in dependecies.xml and not as I would expect the 1.0-SNAPSHOT version. Do I have some misconfiguration or is this a (by me) unforeseen maven snapshot behavior? regards peter petersson [INFO] [car:verify-no-dependency-change] Downloading: http://svn.apache.org/repos/asf/geronimo/server/trunk/repository/org/tranql/tranql-connector-derby-embed-local/1.4/tranql-connector-derby-embed-local-1.4.rar Downloading: http://repo1.maven.org/maven2/org/tranql/tranql-connector-derby-embed-local/1.4/tranql-connector-derby-embed-local-1.4.rar 86K downloaded [INFO] [car:package] [INFO] Packaging module configuration: /usr/local/proj/geronimo-liferay/plugins/connectors/liferay-database-derby/target/resources/META-INF/plan.xml [INFO] GBean references are not using proxies [INFO] ClassLoading behaviour has changed. The Original Classloading mode is in effect. If you are experiencing a problem you can change the behaviour by specifying -DXorg.apache.geronimo.kernel.config.MPCLSearchOption= property. Specify =safe to revert to the original behaviour. This is a temporary change until we decide whether or not to make it permanent for the 2.0 release [ERROR] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.framework/jee-specs/2.2-SNAPSHOT/car?configurationName=org.apache.geronimo.framework/jee-specs/2.2-SNAPSHOT/car org.apache.geronimo.kernel.repository.MissingDependencyException: Missing dependency: org.apache.geronimo.specs/geronimo-jaspi_1.0_spec/1.0-20080804.213256-1/jar org.apache.geronimo.kernel.config.ConfigurationResolver.resolve(ConfigurationResolver.java:113) org.apache.geronimo.kernel.config.Configuration.buildClassPath(Configuration.java:410) org.apache.geronimo.kernel.config.Configuration.createConfigurationClasssLoader(Configuration.java:334) org.apache.geronimo.kernel.config.Configuration.init(Configuration.java:276) : :
Re: G trunk and maven dependencies question
Oh sry my mistake I pointed to the wrong file(s) the dependencies.xml files don't have the version tag. I rebuilt from a empty local repository and did a mvn clean install on gernimo/server/trunk (svn rev 763909) and here is a couple of places where the dated version of geronimo-jaspi_1.0_spec shows up geronimo-server/bin/framework/configs/jee-specs/target/resources/META-INF/geronimo-plugin.xml (and plan.xml) have dependency groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-jaspi_1.0_spec/artifactId version1.0-20080804.213256-1/version typejar/type /dependency Also for example monitoring/mconsole-jetty-server .../target/assembly/repository/... geronimo-plugin.xml and plan.xml and more. hmm the cmp generates thous files, question is why (and where) dose it got hold of the 1.0-20080804.213256-1 version? mvn --version gives Maven version: 2.0.9 Java version: 1.5.0_16 OS name: linux version: 2.6.27-11-generic arch: amd64 Family: unix Its not a big thing as everything builds fine after building gernonimo/server/trunk but It would be nice to find out whats going on and maybe fix the problem as it would be good to be able to do plugin/assembly development/builds without also having to check out and build the server. regards peter petersson David Jencks skrev: Where exactly do you see the file with the dated version? I've looked around in my build and don't see anything obvious. BTW this problem sounds familiar but I don't remember yet when I ran into it... thanks david jencks On Apr 9, 2009, at 4:36 PM, Peter Petersson wrote: I am building some geronimo plugins against G v2.2 (trunk) and I am getting a strange unresolved maven dependency issue against a dated version of the geronimo-jaspi_1.0_spec (see below) when I build from a clean .m2 repository. AFAICT the geronimo-jaspi_1.0_spec version should be 1.0-SNAPSHOT (as declared in geronimo server root pom). I have Geronimo Server Private Repository and Apache Snapshots Repository as repository settings in my project (should be enough to build gplugins?) but only when I first build Geronimo server trunk will my derby plugin build without error. Looking at the generated dependency versions for geronimo-jaspi_1.0_spec in my built geronimo server trunk I also see a dated version (1.0-20080804.213256-1) of the spec in dependecies.xml and not as I would expect the 1.0-SNAPSHOT version. Do I have some misconfiguration or is this a (by me) unforeseen maven snapshot behavior? regards peter petersson [INFO] [car:verify-no-dependency-change] Downloading: http://svn.apache.org/repos/asf/geronimo/server/trunk/repository/org/tranql/tranql-connector-derby-embed-local/1.4/tranql-connector-derby-embed-local-1.4.rar Downloading: http://repo1.maven.org/maven2/org/tranql/tranql-connector-derby-embed-local/1.4/tranql-connector-derby-embed-local-1.4.rar 86K downloaded [INFO] [car:package] [INFO] Packaging module configuration: /usr/local/proj/geronimo-liferay/plugins/connectors/liferay-database-derby/target/resources/META-INF/plan.xml [INFO] GBean references are not using proxies [INFO] ClassLoading behaviour has changed. The Original Classloading mode is in effect. If you are experiencing a problem you can change the behaviour by specifying -DXorg.apache.geronimo.kernel.config.MPCLSearchOption= property. Specify =safe to revert to the original behaviour. This is a temporary change until we decide whether or not to make it permanent for the 2.0 release [ERROR] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.framework/jee-specs/2.2-SNAPSHOT/car?configurationName=org.apache.geronimo.framework/jee-specs/2.2-SNAPSHOT/car org.apache.geronimo.kernel.repository.MissingDependencyException: Missing dependency: org.apache.geronimo.specs/geronimo-jaspi_1.0_spec/1.0-20080804.213256-1/jar org.apache.geronimo.kernel.config.ConfigurationResolver.resolve(ConfigurationResolver.java:113) org.apache.geronimo.kernel.config.Configuration.buildClassPath(Configuration.java:410) org.apache.geronimo.kernel.config.Configuration.createConfigurationClasssLoader(Configuration.java:334) org.apache.geronimo.kernel.config.Configuration.init(Configuration.java:276) : :
Re: G trunk and maven dependencies question
For some reason I'm not seeing this locally, perhaps due to the local changes in my build. I took a heavy-handed approach of just deleting the timestamped artifacts from the snapshot repo. Please let us know if this does not fix the problem. thanks david jencks On Apr 10, 2009, at 4:11 AM, Peter Petersson wrote: Oh sry my mistake I pointed to the wrong file(s) the dependencies.xml files don't have the version tag. I rebuilt from a empty local repository and did a mvn clean install on gernimo/server/trunk (svn rev 763909) and here is a couple of places where the dated version of geronimo-jaspi_1.0_spec shows up geronimo-server/bin/framework/configs/jee-specs/target/resources/ META-INF/geronimo-plugin.xml (and plan.xml) have dependency groupIdorg.apache.geronimo.specs/groupId artifactIdgeronimo-jaspi_1.0_spec/artifactId version1.0-20080804.213256-1/version typejar/type /dependency Also for example monitoring/mconsole-jetty-server .../target/ assembly/repository/... geronimo-plugin.xml and plan.xml and more. hmm the cmp generates thous files, question is why (and where) dose it got hold of the 1.0-20080804.213256-1 version? mvn --version gives Maven version: 2.0.9 Java version: 1.5.0_16 OS name: linux version: 2.6.27-11-generic arch: amd64 Family: unix Its not a big thing as everything builds fine after building gernonimo/server/trunk but It would be nice to find out whats going on and maybe fix the problem as it would be good to be able to do plugin/assembly development/builds without also having to check out and build the server. regards peter petersson David Jencks skrev: Where exactly do you see the file with the dated version? I've looked around in my build and don't see anything obvious. BTW this problem sounds familiar but I don't remember yet when I ran into it... thanks david jencks On Apr 9, 2009, at 4:36 PM, Peter Petersson wrote: I am building some geronimo plugins against G v2.2 (trunk) and I am getting a strange unresolved maven dependency issue against a dated version of the geronimo-jaspi_1.0_spec (see below) when I build from a clean .m2 repository. AFAICT the geronimo-jaspi_1.0_spec version should be 1.0-SNAPSHOT (as declared in geronimo server root pom). I have Geronimo Server Private Repository and Apache Snapshots Repository as repository settings in my project (should be enough to build gplugins?) but only when I first build Geronimo server trunk will my derby plugin build without error. Looking at the generated dependency versions for geronimo- jaspi_1.0_spec in my built geronimo server trunk I also see a dated version (1.0-20080804.213256-1) of the spec in dependecies.xml and not as I would expect the 1.0-SNAPSHOT version. Do I have some misconfiguration or is this a (by me) unforeseen maven snapshot behavior? regards peter petersson [INFO] [car:verify-no-dependency-change] Downloading: http://svn.apache.org/repos/asf/geronimo/server/trunk/repository/org/tranql/tranql-connector-derby-embed-local/1.4/tranql-connector-derby-embed-local-1.4.rar Downloading: http://repo1.maven.org/maven2/org/tranql/tranql-connector-derby-embed-local/1.4/tranql-connector-derby-embed-local-1.4.rar 86K downloaded [INFO] [car:package] [INFO] Packaging module configuration: /usr/local/proj/geronimo- liferay/plugins/connectors/liferay-database-derby/target/resources/ META-INF/plan.xml [INFO] GBean references are not using proxies [INFO] ClassLoading behaviour has changed. The Original Classloading mode is in effect. If you are experiencing a problem you can change the behaviour by specifying - DXorg.apache.geronimo.kernel.config.MPCLSearchOption= property. Specify =safe to revert to the original behaviour. This is a temporary change until we decide whether or not to make it permanent for the 2.0 release [ERROR] Error while starting; GBean is now in the FAILED state: abstractName=org.apache.geronimo.framework/jee-specs/2.2-SNAPSHOT/ car?configurationName=org.apache.geronimo.framework/jee-specs/2.2- SNAPSHOT/car org.apache.geronimo.kernel.repository.MissingDependencyException: Missing dependency: org.apache.geronimo.specs/geronimo- jaspi_1.0_spec/1.0-20080804.213256-1/jar org .apache .geronimo .kernel .config.ConfigurationResolver.resolve(ConfigurationResolver.java: 113) org .apache .geronimo .kernel.config.Configuration.buildClassPath(Configuration.java:410) org .apache .geronimo .kernel .config .Configuration.createConfigurationClasssLoader(Configuration.java: 334) org .apache .geronimo.kernel.config.Configuration.init(Configuration.java:276) : :
RE: Deployment Question
Thank you for your help with this information. From: Kevan Miller [mailto:kevan.mil...@gmail.com] Sent: Thursday, April 09, 2009 4:42 PM To: user@geronimo.apache.org Subject: Re: Deployment Question On Apr 9, 2009, at 2:09 PM, Russell Collins wrote: Couple of questions that I have with the install-library command: * It shows the option for GroupId. Is there options for Artifact ID and Version? Pretty sure the answer is no... * The way that it installs the jar file, it seems as if the jar file is in the format of name-version.jar it will install it in the Group/Artifact/Version format in the directory. Is this assumption correct? Is this type of format the standard way of naming .jar assemblies? Correct. It's the maven convention for naming artifacts... * With the deploy command, is there a way to specify how a .jar file is to be deployed using an xml descriptor? If so, what is the format of the xml? Again, pretty sure the answer is no... Can see that it could be helpful... You can create a Jira and see if somebody's interested in implementing this. Better yet, you could submit a patch... ;-) --kevan
