You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using remote development mode, I sometimes get in a situation where I make the change, call the endpoint, and get the old behavior. a few seconds later a call to the same endpoint will get me the new behavior.
I assume the first call happens before the remote dev client had time to inform the remote side that a patch was coming.
In other cases, calling the endpoint blocks for some time, then renders the new behavior, which is expected.
The only complaint is that getting the result from the endpoint takes in my situation 20 seconds. I checked that there was plenty of resources available on the worker node, and that the cpu limit was high enough. The application is taking less than 50 millicores. so in my situation cpu does not seem to be the limiting factor.
It might very well depend on the application and the environment, but this type of delay will certainly push away developers and limit the usefulness of this feature as a result.
Expected behavior
Ideally, after the change is made, calling the endpoint should block until we are ready to get the new behavior.
Restart should ideally be fast in dev mode.
Actual behavior
Calling the endpoint after the change sometimes gives me the old behavior. Then after some time I will get the new one.
It takes a long time for the application to restart.
How to Reproduce?
I am using a test application with the following extensions:
Describe the bug
When using remote development mode, I sometimes get in a situation where I make the change, call the endpoint, and get the old behavior. a few seconds later a call to the same endpoint will get me the new behavior.
I assume the first call happens before the remote dev client had time to inform the remote side that a patch was coming.
In other cases, calling the endpoint blocks for some time, then renders the new behavior, which is expected.
The only complaint is that getting the result from the endpoint takes in my situation 20 seconds. I checked that there was plenty of resources available on the worker node, and that the cpu limit was high enough. The application is taking less than 50 millicores. so in my situation cpu does not seem to be the limiting factor.
It might very well depend on the application and the environment, but this type of delay will certainly push away developers and limit the usefulness of this feature as a result.
Expected behavior
Ideally, after the change is made, calling the endpoint should block until we are ready to get the new behavior.
Restart should ideally be fast in dev mode.
Actual behavior
Calling the endpoint after the change sometimes gives me the old behavior. Then after some time I will get the new one.
It takes a long time for the application to restart.
How to Reproduce?
I am using a test application with the following extensions:
The application is not doing much, except sending a kafka message every 5 secs, and receiving the message it sent.
Output of
uname -a
orver
No response
Output of
java -version
No response
Quarkus version or git rev
89b732b (future 3.11)
Build tool (ie. output of
mvnw --version
orgradlew --version
)No response
Additional information
No response
The text was updated successfully, but these errors were encountered: