geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Han Hong Fang (JIRA)" <>
Subject [jira] Closed: (GERONIMODEVTOOLS-608) Publish with GEP takes minutes, while deploy takes seconds
Date Mon, 17 Jan 2011 09:11:44 GMT


Han Hong Fang closed GERONIMODEVTOOLS-608.

Released with GEP 2.1.7 and 2.2.1, so I close this JIRA.

> Publish with GEP takes minutes, while deploy takes seconds
> ----------------------------------------------------------
>                 Key: GERONIMODEVTOOLS-608
>                 URL:
>             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,
> Publishing an Enterprise Application (EAR) with GEP to Geronimo takes much more time
then deploying the same EAR to Geronimo using the console. See
> 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 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.

View raw message