You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Boes (JIRA)" <ji...@apache.org> on 2010/04/01 09:41:27 UTC
[jira] Created: (GERONIMODEVTOOLS-608) Publish with GEP takes
minutes, while deploy takes seconds
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
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.
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-608) Publish with GEP takes
minutes, while deploy takes seconds
Posted by "Boes (JIRA)" <ji...@apache.org>.
[ 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 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.
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.
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.
> 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 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.
[jira] Updated: (GERONIMODEVTOOLS-608) Publish with GEP takes
minutes, while deploy takes seconds
Posted by "Boes (JIRA)" <ji...@apache.org>.
[ 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.
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.
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GERONIMODEVTOOLS-608) Publish with
GEP takes minutes, while deploy takes seconds
Posted by "Boes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852275#action_12852275 ]
Boes edited comment on GERONIMODEVTOOLS-608 at 4/1/10 8:25 AM:
---------------------------------------------------------------
I attached two EAR's, HiThere.ear and HiThereSlow.ear. The only difference between the two EAR's is in the geronimo-application.xml. The HiThereSlow has dependencies to existing libraries in the Geronimo repository. HiThere does not have a depencies tag in it's geronimo-application.xml. Publishing of these EAR's shows that adding dependencies has great impact on the publishing speed. Turn on tracing and you see that the depencies tag is parsed more then a thousand times.
was (Author: boes):
I attached two EAR's, HiThere.ear and HiThereSlow.ear. The only difference between the two EAR's is in the geronimo-application.xml. The HiThereSlow has dependencies to existing libraries in the Geronimo repository. HiThere does not have a depencies tag in it's geronimo-application.xml. Publishing of these EAR's shows that adding dependencies has great impact on the publishing speed.
> 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.
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-608) Publish with GEP takes
minutes, while deploy takes seconds
Posted by "Boes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Boes updated GERONIMODEVTOOLS-608:
----------------------------------
Attachment: (was: reorderModules.txt)
> 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.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.
[jira] Updated: (GERONIMODEVTOOLS-608) Publish with GEP takes
minutes, while deploy takes seconds
Posted by "Boes (JIRA)" <ji...@apache.org>.
[ 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. 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.
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.
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.
> 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. 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.
[jira] Commented: (GERONIMODEVTOOLS-608) Publish with GEP takes
minutes, while deploy takes seconds
Posted by "Delos Dai (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12920861#action_12920861 ]
Delos Dai commented on GERONIMODEVTOOLS-608:
--------------------------------------------
commit the patch in revision 1022386 for trunk. Thanks Boes and Chris for the patch!
> 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: 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.
[jira] Commented: (GERONIMODEVTOOLS-608) Publish with GEP takes
minutes, while deploy takes seconds
Posted by "Delos Dai (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12905787#action_12905787 ]
Delos Dai commented on GERONIMODEVTOOLS-608:
--------------------------------------------
Hi Kory,
I didn't see your attachment, could you attach your patch? Thanks in advance!
> 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.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.
[jira] Issue Comment Edited: (GERONIMODEVTOOLS-608) Publish with
GEP takes minutes, while deploy takes seconds
Posted by "Boes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852281#action_12852281 ]
Boes edited comment on GERONIMODEVTOOLS-608 at 4/1/10 9:00 AM:
---------------------------------------------------------------
I attached the two changed methods of the class org.apache.geronimo.st.core.internal.DependencyHelper that speed up publishing (reorderModules.txt and getEnvironment.txt). There are two getEnvironment methods in DependencyHelper. I only made a fix for the getEnvironment(IModule) method. The getEnvironment(JAXBElement) can be changed like the IModule version to make it more efficient.
was (Author: boes):
The two methods of the class org.apache.geronimo.st.core.internal.DependencyHelper I changed to speed up publishing are attached (reorderModules.txt and getEnvironment.txt). There are two getEnvironment methods in DependencyHelper. I only made a fix for the getEnvironment(IModule) method. The getEnvironment(JAXBElement) can be changed like the IModule version to make it more efficient.
> 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. 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.
[jira] Updated: (GERONIMODEVTOOLS-608) Publish with GEP takes
minutes, while deploy takes seconds
Posted by "Boes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Boes updated GERONIMODEVTOOLS-608:
----------------------------------
Attachment: HiThereSlow.ear
HiThere.ear
The only difference between the two EAR's is in the geronimo-application.xml. The HiThereSlow has dependencies to existing libraries in the Geronimo repository. HiThere does not have a depencies tag in it's geronimo-application.xml.
> 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: 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 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.
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (GERONIMODEVTOOLS-608) Publish with
GEP takes minutes, while deploy takes seconds
Posted by "Boes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852275#action_12852275 ]
Boes edited comment on GERONIMODEVTOOLS-608 at 4/1/10 7:51 AM:
---------------------------------------------------------------
I attached two EAR's, HiThere.ear and HiThereSlow.ear. The only difference between the two EAR's is in the geronimo-application.xml. The HiThereSlow has dependencies to existing libraries in the Geronimo repository. HiThere does not have a depencies tag in it's geronimo-application.xml.
was (Author: boes):
The only difference between the two EAR's is in the geronimo-application.xml. The HiThereSlow has dependencies to existing libraries in the Geronimo repository. HiThere does not have a depencies tag in it's geronimo-application.xml.
> 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: 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 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.
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-608) Publish with GEP takes
minutes, while deploy takes seconds
Posted by "Boes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Boes updated GERONIMODEVTOOLS-608:
----------------------------------
Attachment: reorderModules.txt
> 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.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.
[jira] Issue Comment Edited: (GERONIMODEVTOOLS-608) Publish with
GEP takes minutes, while deploy takes seconds
Posted by "Boes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852275#action_12852275 ]
Boes edited comment on GERONIMODEVTOOLS-608 at 4/1/10 7:53 AM:
---------------------------------------------------------------
I attached two EAR's, HiThere.ear and HiThereSlow.ear. The only difference between the two EAR's is in the geronimo-application.xml. The HiThereSlow has dependencies to existing libraries in the Geronimo repository. HiThere does not have a depencies tag in it's geronimo-application.xml. Publishing of these EAR's shows that adding dependencies has great impact on the publishing speed.
was (Author: boes):
I attached two EAR's, HiThere.ear and HiThereSlow.ear. The only difference between the two EAR's is in the geronimo-application.xml. The HiThereSlow has dependencies to existing libraries in the Geronimo repository. HiThere does not have a depencies tag in it's geronimo-application.xml.
> 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: 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 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.
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-608) Publish with GEP takes
minutes, while deploy takes seconds
Posted by "Boes (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (GERONIMODEVTOOLS-608) Publish with GEP takes
minutes, while deploy takes seconds
Posted by "Kory Markevich (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12905614#action_12905614 ]
Kory Markevich commented on GERONIMODEVTOOLS-608:
-------------------------------------------------
Since upgrading from 2.1 or so to the 2.2.0 version of the Eclipse plugin, we've started to see these same issues. Our application complexity is a bit more than the examples given here though, so our times are a little more extreme: after the upgrade we started seeing >20minutes to do a re-deploy. I did some debugging and found that almost all the time was spent dealing with dependencies. After applying the changes as described in the attachments, our re-deploy time went down to under a minute again. As is, the 2.2.0 plugin is unusable.
> 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.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.
[jira] Commented: (GERONIMODEVTOOLS-608) Publish with GEP takes
minutes, while deploy takes seconds
Posted by "Chris Zhang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907515#action_12907515 ]
Chris Zhang commented on GERONIMODEVTOOLS-608:
----------------------------------------------
I have investigated this problem and found that the reason is the duplicate invokations of isInstalledModule() and getEnvironment() method many times in reorderModules() method. This causes the deployment slow.
As Boes said, providing a cache is a good solution of this problem. But considering the thread safety, it's better to use ConcurrentHashMap.
I created a patch and attached it. Thanks.
> 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: 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.
[jira] Issue Comment Edited: (GERONIMODEVTOOLS-608) Publish with
GEP takes minutes, while deploy takes seconds
Posted by "Boes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12852281#action_12852281 ]
Boes edited comment on GERONIMODEVTOOLS-608 at 4/1/10 8:24 AM:
---------------------------------------------------------------
The two methods of the class org.apache.geronimo.st.core.internal.DependencyHelper I changed to speed up publishing are attached (reorderModules.txt and getEnvironment.txt). There are two getEnvironment methods in DependencyHelper. I only made a fix for the getEnvironment(IModule) method. The getEnvironment(JAXBElement) can be changed like the IModule version to make it more efficient.
was (Author: boes):
The two methods of the class org.apache.geronimo.st.core.internal.DependencyHelper I changed to speed up publishing are attached (reorderModules.txt and getEnvironment.txt).
> 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.
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMODEVTOOLS-608) Publish with GEP takes
minutes, while deploy takes seconds
Posted by "Boes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Boes updated GERONIMODEVTOOLS-608:
----------------------------------
Attachment: getEnvironment.txt
reorderModules.txt
The two methods of the class org.apache.geronimo.st.core.internal.DependencyHelper I changed to speed up publishing are attached (reorderModules.txt and getEnvironment.txt).
> 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.
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (GERONIMODEVTOOLS-608) Publish with GEP takes
minutes, while deploy takes seconds
Posted by "Delos Dai (JIRA)" <ji...@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.
[jira] Updated: (GERONIMODEVTOOLS-608) Publish with GEP takes
minutes, while deploy takes seconds
Posted by "Boes (JIRA)" <ji...@apache.org>.
[ 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.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.
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 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.
> 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.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.
[jira] Updated: (GERONIMODEVTOOLS-608) Publish with GEP takes
minutes, while deploy takes seconds
Posted by "Chris Zhang (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris Zhang updated GERONIMODEVTOOLS-608:
-----------------------------------------
Attachment: 608_20100909.patch
> 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: 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.