[
https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Boes updated GERONIMODEVTOOLS-608:
----------------------------------
Description:
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.mxl 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 return 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.
For me this works, but I don't know what the impact is for other users. In the
code changes I attached I left it the way it was.
was:
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.mxl 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 return the
result stored in the hashmap.
After these two modifications GEP is up to speed again.
> 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
> Attachments: 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.mxl 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 return
> 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. For me this works, but I don't know what the impact is for other
> users. In the code changes I attached 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.
