-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Shared DevServices Container for MongoDB Like Kafka in Quarkus #38678
Comments
/cc @alesj (kafka), @cescoffier (kafka), @geoand (devservices), @loicmathieu (mongodb), @ozangunalp (kafka), @stuartwdouglas (devservices) |
It should be possible without too much trouble. Fancy a PR if we guide you? |
@cescoffier what about if we try it with the new "dev resources" concept? |
I could address this request, similarly, as it was done for redis, kafka and others, eg: #18029 - if this is still acceptable. |
@patrox definitely! |
@patrox @cescoffier do I understand it correctly, that this issue is fixed? If so when will it be delivered? |
No it has not been fixed yet. |
@Inithron I'm close to completing it, hopefully, it shouldn't take too long - expect a PR within a week! |
Added a PR that should address this issue: #39787 @loicmathieu Can I please kindly ask you for a review? |
Is there any progress on this issue? |
Hi @patrox, hi @gsmet,
So my question now: Is the issue not solved properly, or is it still not part of version 3.12? |
Same behavior with version 3.12.1. Should i create a new issue that the shared-server is not working? |
@patrox can you have a look please? |
Hi,
As a short summary: Due to the case that many extensions are affected by this issue, it would be great to solve this issue in a central place, if possible. If not maybe the contributors of the different extensions could support each other to solve the issues for each extension individually. |
Hello, Although the desire to have the issue(s) addressed it totally understandable, it is pretty counterproductive to copy and paste the comment across various issues. Thanks |
Hi @geoand, |
No problem 😃 |
After the update to Quarkus 3.15.1 i tested it again but it is still not working. @patrox you tried to fix it 6 month ago. Can you maybe try it again? |
That's not true for every dev service. Do that with Kafka, and if you are not very careful (consumer groups different between test and dev), it won't do what you think. You mentioned that the shared broker does not work for Kafka. Do you have an issue with that? I just tried, and it worked perfectly. |
Hi @cescoffier, You are right. For Kafka it was a little bit tricky but now we can execute the unit tests of our components parallelly on a single Kafka instance. Did you test the shared broker in dev or in test mode? Because as mentioned in #41788 the shared broker works only in dev mode but not in test mode. When we use the dev services in test mode, each test instance tries to start its own broker. |
This is exactly why we do not share brokers in test mode and restart a fresh one every time. |
I do not understand your answer. What exactly do you mean? And why do you not want to provide the possibility to share the broker in test mode for the ones who want to use it? |
Because it requires advanced knowledge about Kafka to use that properly. In this case, I would recommend using a separate broker. |
In our team this knowledge is available. But we can't use a separate broker. We have a Gradle multi project build. And to decrease the build time, we have enabled the option org.gradle.parallel=true (which makes a huge difference). But that means that the compilation and the unit tests of the different projects are executed in parallel. Our projects uses different extensions, but most of them use the MongoDB and Kafka extension. With a single MongoDB and Kafka instance everything is working. But if each project would setup its own MongoDB and Kafka instance / broker the laptops of our develops would crash because they have not enough resources to support this approach. Currently every developer has to start the MongoDB and Kafka manually before he can execute the unit tests. Of course this is working, but it would be great if this could be avoided and we could use a shared MongoDB and Kafka instance also in test mode. In dev mode it is already working, at least for the Kafka extension. So why do you not want to provide this feature for the test mode, too? I can understand that sharing recourses in test mode should not be the default behavior. But why should it not be possible by enable it via a property? |
Hi @cescoffier, |
It should not be the default and should be carefully and explicitly enabled. The default should always be a clear separation between dev and test. @ozangunalp has been working on some docker compose support that may be usable in this case. Also, I'm not sure I understand the multi-module parts - are they all running at the same time? |
It depends. If the sub-projects has dependencies between each other, Gradle builds the projects sequentially. But if not then the compilation and test of the sub-projects are executed at the same time. |
Description
I am working on a Quarkus application that consists of several components. I've noticed that while using DevServices for Kafka a shared single container across all components is used, which is efficient and resource-saving. However, for MongoDB, each component spawns its own container, leading to increased resource consumption on local dev computer.
I would like to request a feature for Quarkus DevServices that allows MongoDB to behave similarly to Kafka in terms of container sharing. Specifically, the ability to configure MongoDB DevServices to use a single shared container across multiple application components, instead of creating a separate container for each component. This feature should be configurable, allowing developers to choose between shared and individual containers based on their specific needs.
Configuration idea:
quarkus.mongodb.devservices.shared=true
quarkus.mongodb.devservices.shared-container-name=myMongoDevContainer
Implementation ideas
No response
The text was updated successfully, but these errors were encountered: