-
Notifications
You must be signed in to change notification settings - Fork 167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Parallel build support #233
Comments
@mikezerosix - I believe you just want to perform fire and forget style deployments and not wait for the deployments to complete. The default option is that so that you can include triggering the automated testing after knowing that deployment is complete. If you do not want that - you can change the deploy options. Just use That will just run the import and deploy command and not poll for the deployment to complete. The same is documented as well |
@ssvaidyanathan Thanks. I am aware of the async option. But I do want to wait for confirmation, I just do not run deployments sequentially. I have maven multimodule project with 20 sub modules, each is apigee flow or proxy. if I run the maven normally
So it looks like this plugin does not support multithreading and it would be amazing if it did. Or I would love have ability to run async deploy and then run separate process to poll projects deployment
Problem here would be that this would need to persist information between these two runs (like mvn release plugin) so it knows which revisions to poll for. So it does not get confused from 3rd party deploys. |
@mikezerosix - Thank you for the detailed summary. Great pointers and suggestions. I will need a favor - if I end up implementing, I will need you to help test it for me and see if it works as expected. We can fine tune as you provide more inputs. |
I created sample project for the issue. I have not tested it that it actually runs, but it at least demonstrates the structure Failure is random, but on thread value 4 or higher it should be almost 100%. |
Brilliant.. I will use this to test it out |
I updated the sample little bit. I also added the Maven warning about threads [WARNING] ***************************************************************** |
@mikezerosix - I cloned your repo
I ran the test with However, when I ran the same test with The entire build ran in 10 seconds
I think you can ignore the threadsafe warning. Thats not really impacting the plugin. With the default "override" option, the plugin is polling the deployments API and if the response from the Apigee API is 503, then the plugin just exits and marks the build as Failed.. But the proxy is eventually getting deployed. What I tried is pipe the mvn response to a log file
Then looked at the log in detail |
@ssvaidyanathan I forgot to mention that parallel deploy run might not fail on empty apigee. Because errors were about revisions. When the deploy actually overrides the existing revisions, it should fail. I have once successfull ran maven parallel with -T1C on 2 core cpu for 16 proxies and flows. But that could just been because the other core was buzy and never ran the second thread. As re-running it failed. Also most times error seems to come from flows, but proxies do fail also. If you can not reproduce the problem with this sample, I can add flows to it. I know that warning is not critical, I added it just for information. I would be interested to know how long does that take to run in default override option, in single thread. It should be something like 40 minutes, even though the proxies have no policies. I have no Apigee that I can run this sample myself as I do not want to mess around in customer's enviroment. We tried asýnc option and it run the project without problems. But that async does not meet our requirements. We need to assert the proxies are successfully deployed. Using async the solution would be just horrible; unreliable and a lot of work to create and maintain
We could do the work, but the fact that it would be unreliable is a deal breaker. |
Got it.. The issue with "override" is that the Apigee APIs are rate limiting.. So you really cannot do anything in the plugin. But I was always having issues with "override" since the Apigee APIs were rate limiting and that was causing failures. Dont think adding flows or policies would matter here. Let me think about your |
@ssvaidyanathan About ratelimit, what about adding plugin option for poll rate ? |
There is a throttling trick I have used in polling, instead of running immediately and sleeping for pollRate. I start the poll on In Java language: But doing: Guarantees that with 20 divided to prime pollRates the parallel polls to only ever run 4 polls per 3 seconds and 20 polls a minute. |
@mikezerosix - did u close this issue by mistake? |
yes, I closed by mistake |
@mikezerosix - when I run your setup, I only see 503s and no 404s |
@mikezerosix - Just released v2.5.1 |
@ssvaidyanathan I was consistently getting 404 error when they plugin tried to retrieve the revisions for sharedflow or proxy. I updated the Gitlab sample to 2.5.1 and I updated the real project to 2.5.1. I tried to run the real project with plugin 2.5.1 and mvn run parameter -T5C, which for the 2 core runner machine would have tried to run 2*5=10 threads. Running with -T1C that should run 21=2 threads succeeded and reduced total runtime by half as expected. I only ran -T1C (=2 threads) once, so it might not be stable. I have once succeeded running that o version 2.5.0, which succeeds something like 1 out of 10 times. |
On both 2.5.0 and 2.5.1 errors are always something like
Either on sharedflow or proxy. |
@mikezerosix - I never got a 404 |
@ssvaidyanathan Sorry, like I said earlier, I can not run the sample on Apigee. As Apigee instances require (very expensive) license I do not have playground Apigee instance. I only have real customer Apigee instance and I can not clutter that with the sample. |
@mikezerosix - then its difficult for me to fix this issue. From my tests, its working as expected as it pushed all the proxies multiple times. |
@ssvaidyanathan I got permission to run my sample in customer's Apigee. I let you know the result when I can run it. |
@ssvaidyanathan Amazing work. It works like charm. Can you do same fix for sharedflows too now ? Result: 1. Baseline - Running 20 dummy proxies with maven plugin with polling of deployment to complete (apigee.options=override) took:
2. Asyncronious deploy where result is unkown making this option unusable. When running with Maven without polling for completion (apigee.options=async) took:
3. Real test - Running 20 dummy proxies with maven plugin with polling of deployment to complete (apigee.options=override) and maven parallel threads (-T5C) took:
Note the total on wall clock as those deploys are are paraller. |
@ssvaidyanathan And because why not ? Running -T10C also succeed and in 2 minutes wall clock. Again, amazing work, thank you. I hope you can add this fix to work with sharedflows too. As in real project is mix of shared flows and proxies. |
@mikezerosix - Thats great news. Thanks for testing them out. Appreciate it. Just to be sure,
The code change should include the change for sharedflows as well. As its the same function for both. Just that you need to pass |
I added 10 sharedflows to the Sample project. They seem to working. I might add another 10 later when I have more time. But I think 10 + 20 is pretty good sample. |
Thats awesome!! Keep me posted. We can close this issue after your tests. |
@ssvaidyanathan Unfortunately the real project still fails. Still with 404 and There should not be any other difference between the real project and sample than that real project had more content on the proxies and shared flows than the sample. Real project always fails on sharedflows, never on proxies. Were both proxies and sharedflows supposed to be fixed for parallel run in plugin version 2.5.1 or was it just proxies ? And were you going to do yet another release where you add the same fix to sharedflows deploy too ? |
No - no other change needed for sharedflows. |
It is and project deploys fine sequentially, without -T mvn run parameter. |
Any chance you can share the log file? |
I am working on it. It will take me a while to check and anonymize it. |
Lets run it without "-X" for now. What you could do is - since the sharedflows are the ones that are failing. You can comment out the proxy modules and just run the sharedflow modules. Once you have that, please share it here. Make sure you go through it and not share anything sensitive |
|
That was running the real project with One thing came to mind that is different in this real project. This Apigee project/org has 5 Apigee environments. All those have this project deployed to them. Which means up 5 different revisions may be deployed (and not deletable) |
ok.. for the ones that are failing the logs, I notice that all the revisions for those APIs and sharedflows are pointing to Can you confirm from your logs that though the APIs and sharedflows are different, you are seeing the same revision number across all those that are failing in the logs? |
but is the Maven plugin stuck to one revision number for all the poxies and sharedflows? If you see the error logs you shared earlier, they all have the same revision number So am wondering if that revision is somehow being used across the threads |
yes, it seems so that is mixes up the revision numbers. That log is direct cut&paste, I only masked the org & proxy names. They should not have same number. The proxy is older and it's counter is around 300 and sharedflow is new counter at 90-ish. P.S. Problem is exceeding max number of revisions, we have clenaup script to delete all undeployed. This scpirt was not running on this failed test. |
it could be that sample work because in that project all proxies and flows same revision number. |
I guess you could reproduce same state by. Or if you know a better way to manipulate proxies and flows revision numbers, so that none of them have matching numbers. |
Yes - Let me try that and get back to you |
Now I got same error on Sample project. All flows were rev 2 and all proxies were rev 8. This run was now deploying proxies as rev 9. Somehow this value leaked into flows this time. [ERROR] Failed to execute goal io.apigee.build-tools.enterprise4g:apigee-edge-maven-plugin:2.5.1:deploy (deploy-bundle) on project flow07: MojoExecutionException: com.google.api.client.http.HttpResponseException: 404 Not Found Seems the variable holding the rev number is not thread safe. |
Got it.. Will work on it and have a fix shortly.. I guess this issue will be there for "async" runs too |
@ssvaidyanathan Please let me know when you have the fix so I can try it. |
@mikezerosix - I just made some changes and published a release candidate. Update your pom to point to Apigee Maven |
@ssvaidyanathan 2.5.2-rc1 still failing the same way as before when running -T10C on real project. 5 out of 18 submodules, both proxies and shared flows, failed on HTTP 404 on revision number not found. |
@mikezerosix - can you try with |
@ssvaidyanathan Great success. I ran it successfully twice. It is huge help as it shortens 30 min build to 2 min. Let us test it for a day and I will close this issue. Thank you very much ! |
Thats awesome news @mikezerosix Thanks for working with me on this. Keep testing and let me know once you find its working as expected. I will then release the 2.5.2 version |
@ssvaidyanathan Bad news, for some reason the build consistently succeeds in one Apigee org/project, but when deploying to another Apigee org/project, it consistenly fails on the same shared flow trying to get revision 44 when latest rev on that shared flow is 42.
|
@mikezerosix - Can you try just deploying that sharedflow using the plugin (comment out other modules) Also - can the sharedflows be executed in 'async' mode? |
@ssvaidyanathan I tried running sharedflows only and that did not cause errors. There is only 7, so that is not definiteve proof the flows work alone. As there seem to be a lot of randomness on the run. |
@mikezerosix - sorry for the delay. I was out on a personal emergency.. Are we still seeing issues? And is this only with sharedflows? |
Hi, @mikezerosix is no longer working on the project so I will continue the conversation (Micheal if you are still there you are very welcome to answer as well :D). So yes we are still seeing the same issues with sharedflows |
@JanneHoltta - sorry for the delayed response. I have been out of office. Can you please confirm if this is happening just for sharedflows and NOT for proxies?
The code for proxies and sharedflow is the same. Not sure why its only failing for sharedflows. Appreciate if you can response the questions above so that I can take a look |
@JanneHoltta - looks like its a known issue For now, I dont think its plugin issue. The best way is to probably reduce the number of submodules you have in your pom and split it into multiple runs. |
We have a lot of proxies and running deploy takes looooong time.
We structured our solution as Maven multi module project. So simply running from root all we can easily deploy them all and
we also can easily choose to deploy them individually from each submodule.
But would be great if we would deploy all of them at once using Maven parallel build:
mvn -T 10 install
(install phase runs the apigee plugin)
We have tried parallel build, but it fail with strange errors like :
That shared flow has no dependencies and it deploys without any issues in non-parallel build.
Cutting down the half hour deploy time to just 3 minutes being able to run it in parallel would be amazing.
So if possible, please suppport Maven parallel builds.
The text was updated successfully, but these errors were encountered: