Return-Path: Delivered-To: apmail-geronimo-dev-archive@www.apache.org Received: (qmail 95058 invoked from network); 14 Oct 2010 07:24:02 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 14 Oct 2010 07:24:02 -0000 Received: (qmail 34446 invoked by uid 500); 14 Oct 2010 07:24:02 -0000 Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org Received: (qmail 33961 invoked by uid 500); 14 Oct 2010 07:23:59 -0000 Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@geronimo.apache.org List-Id: Delivered-To: mailing list dev@geronimo.apache.org Received: (qmail 33952 invoked by uid 99); 14 Oct 2010 07:23:58 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Oct 2010 07:23:58 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.22] (HELO thor.apache.org) (140.211.11.22) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 14 Oct 2010 07:23:55 +0000 Received: from thor (localhost [127.0.0.1]) by thor.apache.org (8.13.8+Sun/8.13.8) with ESMTP id o9E7NWBt003123 for ; Thu, 14 Oct 2010 07:23:33 GMT Message-ID: <4719287.137771287041012676.JavaMail.jira@thor> Date: Thu, 14 Oct 2010 03:23:32 -0400 (EDT) From: "Delos Dai (JIRA)" To: dev@geronimo.apache.org Subject: [jira] Resolved: (GERONIMODEVTOOLS-608) Publish with GEP takes minutes, while deploy takes seconds In-Reply-To: <1498644643.626651270107687135.JavaMail.jira@brutus.apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Delos Dai resolved GERONIMODEVTOOLS-608. ---------------------------------------- Resolution: Fixed Fix Version/s: 3.0 2.1.7 2.2.1 commit the patch in revision 1022388 for 2.1.6 branch and 1022395 for 2.2.1 branch > Publish with GEP takes minutes, while deploy takes seconds > ---------------------------------------------------------- > > Key: GERONIMODEVTOOLS-608 > URL: https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608 > Project: Geronimo-Devtools > Issue Type: Bug > Components: eclipse-plugin > Affects Versions: 2.2.0 > Environment: GEP 2.2 installed in Eclipse (galileo-SR1). > Reporter: Boes > Assignee: Delos Dai > Fix For: 2.2.1, 2.1.7, 3.0 > > Attachments: 608_20100909.patch, getEnvironment.txt, HiThere.ear, HiThereSlow.ear, reorderModules.txt > > > Publishing an Enterprise Application (EAR) with GEP to Geronimo takes much more time then deploying the same EAR to Geronimo using the console. See http://n3.nabble.com/Publish-with-GEP-takes-minutes-while-deploy-takes-10-seconds-td684484.html > After doing some research I found that EAR's that have dependencies in geronimo-application.xml take a lot of time to publish. This is caused by the very inefficient implementation of the reorderModules method in the org.apache.geronimo.st.core.internal.DependencyHelper class. > I installed a GEP development environment and put on tracing. It tested an EAR with 3 WAR's in it. In the EAR's geronimo-application.xml I added dependency tags for 4 libraries. Tracing shows that this results in parsing the geronimo-application.xml 1092 (!) times. In code this means that a call to DependencyHelper.getEnvironment is made 1092 times. > Another inefficient part in the reorderModules method is that the call to DeploymentUtils.isInstalledModule is repeatedly made for the same module. In the test I found it was called at least 3 times for each dependent library. These calls result in a request to Geronimo and take almost a second each. > The best way to solve this bug is to redesign the reordering process and make it work in a way that both DependencyHelper.getEnvironment and DeploymentUtils.isInstalledModule are not called more often then needed. I wonder why DeploymentUtils.isInstalledModule is called at all. Dependencies are defined in the xml. I can't imagine why it would matter if a module is installed in Geronimo or not. > What I did to fix this problem and make GEP workable again for me is: > - made sure the DeploymentUtils.isInstalledModule is never called twice for the same module. Once the DeploymentUtils.isInstalledModule is called for a certain module, I add this module to a list. Before a next call to DeploymentUtils.isInstalledModule I verify if the call has been made before. If so, it doesn't need to be called again. > - reduced the number of times the xml is parsed. I put the results of the DependencyHelper.getEnvironment for a certain module in a hashmap. Next time the DependencyHelper.getEnvironment is called for the same module, I returns the result stored in the hashmap. > After these two modifications GEP is up to speed again. > Removal of the call to DeploymentUtils.isInstalledModule makes GEP even faster. Just as fast as deployment using the Geronimo console. For me this works, but I don't know what the impact is for other users. In the attached code I left it the way it was. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.